Recentemente ministrei um CSM e um CSPO em Brasília onde a maioria das pessoas trabalhava com o Governo. Nessas duas aulas, ouvi várias vezes o seguinte questionamento:
“Ao se iniciar um projeto com métodos Ágeis, como podemos determinar custo e prazo sem conhecermos o “todo”, ou seja, sem descrevermos, o mais detalhadamente possível, o que é esse produto a ser gerado?”
Apesar de uma longa história de fracassos, muitas organizações no mundo ainda insistem em definir “todo” o software a ser desenvolvido no principio do projeto, como se fosse um edifício a ser construído. O Governo Brasileiro é uma delas, embora venha recentemente sinalizando importantes mudanças.
A verdade é que esse “todo”, quando se trata de software, não existe até que ele seja de fato criado. Ele não está escondido em algum lugar na cabeça do cliente ou em sua empresa, e assim bastariam, no início do projeto, a técnica adequada e tempo de planejamento suficiente para ser descoberto. O software “todo” ainda não existe.
Ao pesquisarmos as razões de fracasso para projetos, uma das respostas mais comuns é que o cliente não sabe o que quer, já que ele fica solicitando mudanças. O cliente, claro, tem desejos ou necessidades a serem supridas a partir do produto, e esses justificam a própria contratação do projeto. Mas ele não sabe os detalhes de como chegar lá. Como diz meu amigo e sócio Rodrigo de Toledo, se o cliente nunca sabe o que quer, então isso é fato. FATO! Vamos então encarar isso como fato e lidar com a realidade da melhor forma que pudermos. E lidar com a realidade significa aceitar a inevitável mudança como parte do processo, e não como inimiga. Ao invés de buscar meios de evitá-la, abraçá-la é o que conduzirá o projeto ao sucesso. E entender que essa “mudança”, na realidade, é o próprio processo de definição do produto.
O “todo” é, assim, criado progressivamente, a partir do feedback do cliente, que vê, recebe e usa incrementos do produto que lhe entregamos com frequência. A definição desse “todo” é, portanto, um processo contínuo de descoberta e de aprendizado, onde cliente e desenvolvedores caminham juntos definido, gerando, avaliando e realimentando o produto, de forma que atenda às necessidades desse cliente da melhor forma possível.
E o contrato? Bem, como produzir um contrato de algo que NÃO PODE ser detalhadamente definido a priori? Será que funciona mesmo assim criar um contrato detalhado, fingindo que podemos definir esse “todo” no início do projeto? Será que mentir (e, muitas vezes, acreditar na mentira) é a solução? Tenho certeza que não. Lidar com a verdade não lhe parece mais razoável?
Pense então como você faria o contrato para a criação de um produto novo, a ser inventado – porque software é assim – e construa sua solução para o contrato a partir daí. Topa o desafio? E então poderemos continuar essa discussão em um post futuro.
Se quiser saber mais sobre Planejamento em Métodos Ágeis, dá uma olhada nesses artigos:
Perguntas frequentes
Por que não é possível detalhar todo o escopo de um software antes de começar o projeto?
O software completo não existe no início do projeto nem está escondido na mente do cliente. O desenvolvimento de software é a invenção de um produto novo. Tentar detalhar tudo antes da execução ignora que o planejamento inicial não consegue prever todos os detalhes de algo que ainda precisa ser criado.
Como interpretar as solicitações constantes de mudanças feitas pelos clientes em projetos?
Em vez de ver as mudanças como um problema ou falha do cliente em saber o que quer, é preciso encará-las como um fato natural. As alterações não são inimigas, mas sim o próprio processo de definição do produto, devendo ser abraçadas para conduzir o projeto ao sucesso.
Como ocorre a definição de um produto de software ao longo do desenvolvimento ágil?
A definição do produto acontece de forma contínua e progressiva. O cliente e os desenvolvedores trabalham juntos entregando incrementos frequentes. A partir do uso e do feedback sobre esses incrementos, o software é continuamente avaliado e ajustado, garantindo que o aprendizado atenda às reais necessidades do cliente.
Como estruturar contratos para projetos de software quando o escopo não é fixo?
Criar contratos altamente detalhados no início baseia-se na falsa premissa de que é possível definir o produto antes de criá-lo. O contrato deve ser pensado considerando o software como a invenção de um produto novo, aceitando a flexibilidade e a verdade sobre o processo contínuo de descoberta.
Pronto pra dar o próximo passo?
Conheça os cursos da K21 e leve essas ideias pra prática com quem vive agilidade todo dia.
Ver cursos K21