Não acho que o restante dos negócios ajude, porque eles não têm noção do ciclo de vida do desenvolvimento e os requisitos são alterados o tempo todo em um único sprint.
Uma coisa que os negócios geralmente ouvem é qualquer coisa que tenha impacto no orçamento. Se os requisitos em constante mudança estão sendo feitos frivolamente, convém criar um argumento com exemplos detalhados para mostrar como essa mudança afeta a eficiência da equipe, cria trabalho sobreposto e custa o dinheiro da empresa. Se, por outro lado, as alterações forem necessárias e puderem resultar em uma perda para a empresa, se não for feito, você poderá simplesmente usá-lo e encontrar uma maneira de lidar com os requisitos em constante mudança.
Minha experiência, no entanto, é que, quando as coisas estão mudando a uma taxa tão alta como você sugeriu, pode ser pelos seguintes motivos:
- O conceito é experimental; nesse caso, você pode querer aplicar todas essas alterações em vez de implementá-las diretamente no código de produção.
- O conceito não foi completamente analisado, o que sugere que o produto não foi realmente pensado e o requisito é codificá-lo enquanto estiver sendo pensado.
- Mercado constante e pressões competitivas resultam em mudanças bruscas
- Um relacionamento ruim entre os motivadores do projeto, os gerentes e a equipe de implementação, em termos da capacidade de todas as partes interessadas se comunicarem livremente sobre a necessidade de mudança.
- Priorização deficiente de tarefas, e isso pode ser uma falha da equipe de gerenciamento e implementação.
Às vezes, os proprietários do projeto não sabem realmente como o produto deve funcionar, porque eles têm um conceito básico em mente, mas sentem que precisam ver como ele funciona primeiro antes de se decidirem. Isso pode ocorrer porque o domínio do problema não é muito bem compreendido ou porque eles realmente não pensaram sobre como uma função comercial se traduzirá em uma solução baseada em software. A prototipagem pode ser benéfica nesses casos. Você pode criar protótipos de GUIs facilmente com objetos simulados se as alterações forem cosméticas ou usar testes de unidade como um meio para testar e ajustar as alterações algorítmicas. A chave, porém, é garantir que as mudanças sejam aplicadas da forma mais sistemática possível, a fim de manter o processo relativamente enxuto e menos dispendioso.
Sugerimos a criação de processos para evitar essas mudanças de requisitos e educar os negócios sobre os ciclos de vida do desenvolvimento.
Este é um bom começo e permite que você se envolva com a gerência para tentar obter resultados positivos de uma maneira medida e estruturada. A educação é o método mais eficaz para lidar com problemas em que os desenvolvedores e o gerenciamento estão fora de sincronia ideológica. No entanto, para obter o maior benefício, a educação precisa ser de mão dupla, assim como a comunicação. Você precisa ensinar a si mesmo e à gerência a comunicar suas necessidades e ajudar-se mutuamente a entender as motivações que direcionam essas necessidades. Dizer que é "muito difícil" ou "muito trabalho" ou "uma perda de tempo" só parecerá reclamar e ser "preguiçoso". Seu raciocínio precisa ser claro, e em um idioma que mostrará que você está trabalhando para alcançar resultados positivos para a empresa e o produto em que está trabalhando, e que seus motivos estão com esses melhores interesses em mente. Da mesma forma, talvez você precise aprender a aceitar os motivos que os fatos lhe dão, por que eles sentem a necessidade de mudar as coisas tão rapidamente. Talvez entre vocês consiga encontrar um bom meio termo viável quando os dois lados conseguirem entender o ponto de vista um do outro.
E se a empresa não conseguir entender a idéia? O que você faria?
Se você não alcançar o resultado esperado, talvez o momento não esteja certo. Talvez seus argumentos precisem ser feitos de maneira diferente. Talvez você tenha entendido tudo errado e precise aprender mais sobre o que o outro lado está pensando. Por fim, se sua abordagem específica falhar, você decide como é importante lidar com isso. No entanto, em vez de se preocupar com o que pode ou não acontecer, pense positivamente e simplesmente decida o que você pode fazer hoje. Os problemas de amanhã não são necessariamente garantidos e não valem o estresse de se preocupar até que realmente ocorram.
Um último ponto a considerar. Seu CTO está possivelmente preocupado com muitos dos mesmos problemas que você. Certamente, ter um decreto para adotar o TDD me sugere que esse pode ser o caso, já que o TDD é altamente eficaz em situações em que o código geralmente está sujeito a alterações. Em um cenário de primeiro teste, os testes não se tornam inúteis no dia seguinte, porque fornecem uma rede de segurança para você trabalhar, permitindo aplicar alterações com rapidez e confiança. No entanto, você ainda precisará encontrar uma maneira de gerenciar as expectativas das pessoas que solicitam alterações, a fim de ajudar a gerenciar as alterações com eficiência.