Artigos

“Você é responsável pelo software que desenvolve”

A primeira vista você pode pensar que esta frase seja muito óbvia. É claro, afinal de quem mais será a culpa quem mais pode ser responsável pelo software que está sendo desenvolvido senão a própria equipe que o desenvolve?

Apesar de parecer óbvia, se visualizarmos as coisas no desenvolvimento de software (dito “tradicional”) por um dado ponto de vista, podemos ver que muitas vezes nem tudo acaba funcionando assim.  Ao contrário disso.

Se prestarmos atenção, no processo de desenvolvimento “tradicional” (esquema de fábrica de software de empresas 1.0) podemos ver que a cada momento os papeis responsáveis pelo software em cada momento buscam se cercar de todos os meios e se livrar da responsabilidade do software.

SFases do ciclo de desenvolvimento em cscatae não, ou vejamos. Tudo começa com um cliente que tem uma necessidade ou enxerga uma oportunidade.  Isto pode ser uma ideia, um projeto, um desejo.  O cliente tem dinheiro e quer fazer aquilo acontecer, o que ele faz?  Transfere a responsabilidade pela sua ideia, seu projeto, seu desejo –na  verdade, seu futuro software– para uma equipe de desenvolvimento.  Um contrato inicial, um prazo estipulado e… “Ufa, a bola agora já não está comigo. Estou pagando e ao final do prazo já tenho de quem cobrar resultados”.  Com isto, o cliente livra-se da responsabilidade sobre o software para a equipe.

Por outro lado, dentro da equipe, depois dos contatos iniciais, dos analistas de negócios fazendo de tudo para vender mais um software, a equipe de requisitos está na berlinda.  Após várias reuniões com o cliente, entrevistas, envolvendo todo o processo de elicitação, categorização, mapeamento, rastreabilidade, priorizaçao, chega o tão sonhado dia em que o cliente assina o termo de aceite, homologando os requisitos.  “Ufa, o cliente já disse que concorda com isso, finalmente.” E a equipe de requisitos passa sua responsabilidade sobre o software adiante.

Situação não muito diferente acontece noutros pontos do processo.  A equipe de arquitetura de análise e projeto se esmera em fazer um projeto tão bom e irretocável que não precise nunca mais  voltar para eles, e passam a bola para os implementadores.

Os implementadores, muitas vezes, os que mais sofrem, afinal é onde o trabalho do software em si é mais visível e exposto.  Tomados pela pressão do tempo e do cliente, a forma que os implementadores têm de tentar passar a responsabilidade adiante acaba sendo a POG.  Com isso, porém, a ânsia de transferir a responsabilidade para os testadores pois estes acabam encontrando mais bugs e transferindo a responsabilidade de volta.  Então é melhor usar o tempo que seria dedicado a testes para implementar, assim os testadores não terão como retornar tantos bugs.  “Se não der pra entregar no prazo, a gente põe o que está aí em produção e passa a bola para o cliente.  Se ele quiser, faz um contrato aditivo só para manutenções”.  E o ciclo recomeça.

Imagem de uma pessoa tentando segurar uma batata quenteApesar de simplificadamente ilustrativo, este cenário infelizmente não é nada muito longe da realidade de muitas empresas de desenvolvimento de software. O software em desenvolvimento é visto como uma batata-quente pelos seus diversos envolvidos (ou talvez até como uma bomba).

Claro que um cenário como este é muito pouco propício para se gerar algum produto de qualidade, ter-se retorno de investimento adequado e que gere vantagem competitiva para o cliente.  Infelizmente, há modelos de gestão que consideram como sendo de sucesso os projetos que tenham sido encerrados dentro das estimativas de prazo e custo, indepentendemente da satisfação do cliente.  Aí uma porta aberta para especificações de “gorduras” iniciais no prazo e custo, a que muitos gerentes de projeto acabam recorrendo.

Permita que o software lhe cative, e seja responsável por ele

O Pequeno Príncipe
“És eternamente responsável por aquilo que cativas”

Neste contexto, ser responsável pelo software é um conselho aplicável simplesmente a todos os envolvidos em sua confecção.  Seja você um cliente ou alguém da equipe de desenvolvimento (com os diversos papeis que seu processo lhe atribuir), você precisa amar o seu trabalho.  Tenha orgulho de seu software.  Veja-o crescer.  Trate-o como uma joia a ser lapidada.  Tenha ciúmes e orgulho dele.  Chame-o de seu.  Contribua sempre com todos os que tenham pelo seu software o mesmo sentimento e tente fazer com que o software cative também aqueles que não estiverem lá muito entusiasmados ou até indiferentes ao seu software.

Seja responsável pelo seu software. Nunca permita que ele seja empurrado para outros.  Ao contrário, faça com que as pessoas queiram seu software para si, em todos os seus aspectos.

Não se omita, colabore!  Isso tudo é ser ágil.

3 Comentários

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *