- Quando desenvolvedores dizem No, saber responder a isso ajuda, como gerente de produto, a afirmar sua autoridade e alcançar objetivos
- Quando dizem que não conseguem implementar uma funcionalidade dentro do prazo proposto por motivos técnicos, é possível destravar a situação com as perguntas certas
1. Há outra solução técnica para construir a funcionalidade?
- Existem várias maneiras de construir uma funcionalidade, e a primeira abordagem nem sempre é a melhor
- Desenvolvedores querem usar as tecnologias mais recentes para criar funcionalidades incríveis, mas isso pode levar a engenharia em excesso em vez de otimização pela simplicidade
- Desenvolvedores com um conjunto específico de tecnologias podem não perceber soluções mais simples que estejam fora do alcance do seu conhecimento
- Por isso, é bom incentivar o engenheiro a pensar de forma mais criativa sobre a solução técnica
- Alguns dos melhores gerentes de produto com quem trabalhei tinham conhecimento e visão técnica suficientes sobre o ambiente tecnológico para fazer perguntas perspicazes que ajudavam os engenheiros a pensar fora da caixa
2. Se você tivesse que propor uma solução com essas restrições, como faria?
- Se os desenvolvedores levantarem problemas na solução que você propôs, peça que apresentem a solução deles
- Desenvolvedores são uma fonte de criatividade e inovação, e ao perguntar se existe uma versão mais simples da funcionalidade, você dá a eles a chance de pensar criativamente
- Quando entendem o cerne do problema, os desenvolvedores pensam de forma criativa e encontram uma solução que funciona dentro das restrições do projeto
3. Podemos considerar uma abordagem em etapas para essa funcionalidade?
- Quando dizem que a funcionalidade não pode ser implementada por causa da complexidade técnica, pergunte se o projeto pode ser dividido em fases com datas de entrega diferentes
- Há a tentação de entregar uma grande visão de uma vez só, mas uma abordagem em etapas é mais iterativa e entrega resultados concretos mais rápido
- As prioridades podem mudar, e uma abordagem em etapas permite alinhar com os desenvolvedores quais funcionalidades devem ser adicionadas depois
4. Que obstáculos podemos remover ou resolver para tornar isso viável?
- Esta é uma pergunta voltada a objeções relacionadas a recursos: quando os desenvolvedores citam recursos limitados (por exemplo, tempo ou número de desenvolvedores disponíveis), elimine ativamente trabalho para liberar tempo deles
- Formas possíveis: remover tarefas por completo, assumir tarefas que não exigem desenvolvedores, ficar responsável pela comunicação com outros times e/ou terceiros, ou facilitar o trabalho assumindo o processo e descontinuando funcionalidades legadas
Conclusão
- Pode ser desconfortável "insistir" diante de um "não dá" dos desenvolvedores, mas isso pode fazer com que você ganhe mais respeito
- É preciso investigar um pouco mais a fundo por que o engenheiro está se opondo, entender esse motivo e ir eliminando as objeções uma a uma
- Todas essas são boas perguntas porque reconhecem as dificuldades e restrições específicas que o engenheiro pode enfrentar ao implementar uma funcionalidade
- Elas também deixam claro que você está disposto a fazer a sua parte para ajudar o time e o projeto, seja arregaçando as mangas para fazer o trabalho pesado, seja ajustando requisitos e cronograma
8 comentários
No fim das contas, tudo depende de como isso é alinhado
Obrigado pelo ótimo conteúdo
Se você perguntar com base nos pontos acima, parece que vai ficar bem fácil filtrar quando a pessoa está dizendo “não” só porque realmente não quer fazer
Como PM/PO, há duas metodologias que me ajudaram quando eu fazia o papel de coordenação entre a área de negócios e a área de TI em projetos.
Claro, a premissa é que tanto a área de negócios quanto a de TI "entendam o que se está dizendo".
A primeira é avançar em etapas.
A segunda é reduzir o escopo.
São essas duas.
A maior dificuldade na condução de projetos, tanto para a área de negócios quanto para a de TI, é o "prazo".
O prazo já está definido, e na maioria das vezes o volume parece impossível de concluir dentro dele.
Nesses casos, faz-se de forma "faseada". Com um cronograma sequencial como phase 1, 2, 3... Colocando as funções mais importantes na phase 1 e as menos importantes na phase 2, e assim por diante.
Mas, em projetos que não podem ser feitos dessa forma, ou seja, que precisam entrar no ar de uma vez só,
é preciso reduzir o escopo para caber no "prazo". Entre o que entraria nas phases 1, 2 e 3, é preciso cortar tudo o que não seja a "funcionalidade realmente necessária".
Com essas duas metodologias, se a área de negócios/TI for do tipo que "entende o recado", na maioria dos casos concorda.
Porque é melhor do que o projeto dar errado e cada um levar bronca do seu chefe...
Enfim.
Força para todo mundo^^
PS:
Tem um último tempero nisso tudo.
Mesmo usando os dois métodos acima, muitas vezes os desenvolvedores ainda demonstram resistência.
Nessas horas, se você disser
"Vamos checar uma vez lá pela metade do projeto. Se parecer que vamos precisar de mais prazo, eu me responsabilizo por conseguir a extensão do prazo"
muitas vezes o semblante dos desenvolvedores melhora.
E, quando fazíamos essa checagem no meio do caminho, em 95% dos casos não era necessário mais prazo.
Além disso, muitas vezes, quando os desenvolvedores começam a programar, acabam fazendo tudo bem rápido.
Como alguém em uma função que precisa se alinhar com desenvolvedores, eu gostaria de trabalhar com desenvolvedores com quem esse tipo de conversa é possível. Até agora, só conheci desenvolvedores que simplesmente dizem que não dá, então isso me entristece. Quando vou tentando convencer e perguntando de um jeito ou de outro, na maioria das vezes acaba sendo um caso em que a própria pessoa não conhecia um método que tornaria isso possível...
kkkkkkkkkk que dor no coração..
Perguntas que um engenheiro deve fazer a si mesmo antes de dizer "NÃO".
Essas também me parecem perguntas realmente ótimas para fazer a si mesmo.
Antes de serem engenheiros, são pessoas. Concordo que o hábito de dizer "não" automaticamente como engenheiro é um problema, mas acho que seria uma grande ajuda se o lado de PM/PO tivesse esse tipo de pergunta em mente.