Recentemente trabalhei em uma empresa de pequeno porte tentando implantar (ensinar, vender, disseminar, ou outro termo que caiba aqui) Scrum na tentativa de organizar e agilizar o processo de desenvolvimento do software da empresa, que até o momento só conhecia (e conhece) Waterfall.
As desculpas da empresa para não adotar Scrum (ou outro processo ágil) são todas apoiadas em confiança (ou desconfiança): como confiar num projeto que não tem tudo detalhadamente especificado desde o início? Era comum ouvir: “só isso não vai dar certo”, “precisamos detalhar todas as funcionalidades primeiro”, “não quero chegar lá na frente e ter que mudar alguma coisa hein”, “o cliente não vai querer comprar uma coisa que ele nem sabe o que é”.
Na ocasião, encontrei este artigo falando sobre desenvolvimento iterativo e incremental, e utilizei estas imagens para (tentar) argumentar meu ponto de vista.
Iterativo:
Incremental:
É evidente que ninguém entendeu a mensagem. Para eles, a confiança ainda estava em jogo. Em termos de proteção, o Waterfall ainda garante uma “falsa segurança” à empresa: “estamos entregando apenas o que estava documentado nas especificações”, “a documentação nos protege”.
Bom, tá aí um resumo da minha experiência e tenho certeza que vocês já passaram por algo parecido. Continuamos nos comentários…
PS: O post ficou meio “vago”, mas estou escrevendo “incrementalmente”… hehehe
No Brasil existe a “mentalidade cartorial”, ou seja, só vale o que está escrito. Dizem que isso é herança ibérica. De qualquer forma essa mentalidade pode justificar essa sensação de segurança proporcionada pelos contratos e especificações. As responsabilidades não são intrínsecas, têm que estar detalhadas em algum papel.
O que mais me incomoda nesta visão de “documente TUDO antes de implementar” é que raramente o cliente tem uma noção completa do que ele quer ou precisa. E se ele não tem noção, fica difícil especificar tudo no início, e duas coisas irão acontecer:
1) a especificação inicial vai ser que nem a cara do analista, e em algum ponto do processo será necessário fazer tudo novamente
2) o cliente vai descobrir que certas coisas não são como ele imaginava, e e em algum ponto do processo será necessário fazer tudo novamente
O segundo caso é o que mais me incomoda. Porquê apesar de não conhecermos bem o negócio do cliente, em geral sabemos melhor do que ele o que pode funcionar ou não em software. E ainda assim, ele é quem manda e define design.
Mas como foi dito em outro post, eu ainda vou trabalhar em uma empresa ideal onde tudo funciona e o café não dá cancer….
Completando o que o Miguel disse, desde os tempos mais primórdios Fred Brooks já constatava que o software é tão vivo que, concluída a dita especificação, nesse exato momento ela já está obsoleta, pois as regras que lhe deram origem já estariam ligeiramente diferentes… e mesmo que a coisa não seja assim tão fluida, todos já se depararam com a seguinte situação: o software está “pronto” e o cliente, ao experimentá-lo, diz que na verdade precisa de outra coisa. Mecanicamente dizemos, “não está na especificação!”, e vence quem falar mais alto.
Não é que ele esteja errado em “reclamar” do software. O cliente apenas percebeu que pode ir um pouco mais longe agora. Ele não tinha como melhorar a especificação que deu origem ao sistema, mas agora que as coisas estão um pouco mais redondas e alguns problemas foram tirados do campo de visão, ele pode ir mais além com o sistema. Neste momento temos um contrato engessado para atrapalhar. Um contrato que, no máximo, prevê uma taxa de manutenção que a empresa fornecedora do sistema usa de forma mesquinha.
É um jeito de agir que está profundamente enraizado em nós e nos clientes. Fato é que dificilmente são encontradas pessoas esclarecidas tanto de um lado quanto do outro.