O software “todo” não existe!

Este post não tem tags.

Compartilhe:

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.

Sobre o autor(a)

Co-fundador e Trainer na K21

Rafael Sabbagh é co-fundador da K21 e foi membro do Board de Diretores da Scrum Alliance entre 2015 e 2017. Ele é Certified Scrum Trainer (CST) pela Scrum Alliance e também Accredited Kanban Trainer (AKT) pela Kanban University. Atuando em nível executivo, possui uma vasta experiência em Transformação Digital e Gestão de Produtos. Ao longo da sua carreira, já treinou milhares de Scrum Masters, Product Owners e membros de equipes em mais de 15 países na Europa, América e Ásia.

No headers found for the table of contents.

Artigos relacionados

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Um dos maiores desafios da gestão de fluxo é a identificação de gargalos e o que deve ser feito para removê-los. Geralmente, as pessoas analisam o quadro de tarefas e usam a lógica: se uma etapa do fluxo tem mais…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Ao longo da minha vida profissional, já passei por centenas de apresentações de produtos e serviços. Coloco aqui algumas dicas que creio que são muito importantes e espero que ajude a sua apresentação no que fazer e no que não…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

O Padrão 1, 2, N tem várias utilidades. A ideia é reduzir e implementar a melhoria contínua e reduzir o impacto de um possível erro. O conceito nasceu no eXtreme Programming. Mais especificamente introduzida por Kent Beck na automação de…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Este final de semana estive na casa de meus pais fazendo uma limpa e me deparei com um trabalho da minha primeira pós-graduação. O método ágil Crystal. Na corrida dos métodos ágeis é perceptível que o Scrum ganhou ampla dianteira…