Durante minha carreira profissional fui obrigado tive a oportunidade de atuar brevemente no campo gerencial do desenvolvimento de software. Foi uma experiência que agregou muito conhecimento e me fez enxergar minha atividade principal, programação, com outros olhos. Também pude entender melhor as estratégias comerciais da empresa, gerenciamento de recursos, retorno sobre investimento, etc. Além de aprender mais sobre desenvolvimento de software, também pude conhecer os vilões dessa história, na maioria dos casos: a diretoria.
Na maioria dos problemas que presenciei, a diretoria (quem toma decisões e libera a grana do projeto) contribuiu para que as coisas ficassem cada vez piores, seja tomando decisões visando curto prazo ou aplicando conceitos ilusórios como adoção de uma tecnologia ou metodologia da moda. Seguem algumas pérolas da “diretoria”:
“Programadores são descartáveis”. Não consigo acreditar que pessoas numa hierarquia superior ainda tenham esta visão dos programadores, comparando desenvolvimento de software com construção civíl e programadores com pedreiros (em alguns [poucos] casos é verdade). Certa vez presenciei um dos mais famosos defensores de práticas ágeis, autor de vários livros e que subiu na carreira devido a seu destaque como programador (Delphi), dizer: “programadores têm em todo lugar, basta sacudir uma árvere e cai um monte deles no chão”. Depois dessa, passei a ignorar tudo que ele escreve ou fala. Talvez se ele tivesse lido pelo menos o resumo do Manifesto ágil saberia que blasfemou feio!
“Meu maior gasto é gerado pelos programadores”. Fiquei sem reação quando ouvi esta pérola do dono da empresa. Ele ainda achava que os atrazos e erros do sistema vinham dos seus quatro programadores juniores que utilizavam uma tecnologia quem ninguém conhecia direito (mas está na moda), não utilizavam nenhum processo ou metodologia e ainda tinham que manter contato direto com os clientes.
“Precisamos de documentação”. Esta todos nós já ouvimos e conhecemos o final. Um certo dia alguem chega na empresa e decide que tudo deverá ser documentado. Então gastam-se alguns meses levantando os requisitos do sistema, definindo os casos de uso e diagramas UML, reuniões, definição do banco de dados, etc. Lá pelo 10º mês descobrem que nenhuma linha de código foi escrita e o sistema só existe no papel. Nem preciso contar o final da história né?
“Como assim não dá pra desenvolver este ERP em três meses?”. Nunca assisti um Tech-Ed nem outra palestra do tipo, por isso não sei exatamente o que vendem falam sobre pazos, mas com certeza é uma mentira das grandes! Não existe mágica nesse ramo, não existe ferramenta nem tecnologia milagrosa e nenhum processo vai acelerar o desenvolvimento do sistema. Ponto. Somente uma pessoa que não entende nada sobre desenvolvimento de software acreditaria nesse conto de vigário. Um general sabe comandar seus soldados pois certamente foi um soldado e esteve num campo de batalha. Será que todo chefe/diretor foi programador (de verdade) no início da carreira? Ter programado em Cobol há 20 anos atrás não conta!
“Não podemos perder tempo com refactoring e testes unitários”. Bom, se deixar o código do sistema mais “manutenível” e garantir que o que já foi feito funcione corretamente do jeito que deve ser for uma “perda de tempo”, então estou no ramo errado. Fazer com que o sistema “rode” é muito importante pois sistema rodando é dinheiro entrando no caixa. Mas abrir mão da qualidade é uma péssima estratégia a curto prazo, pois todos nós sabemos que sistemas mudam constantemente e ter mecanismos para responder rapidamente a essas mudanças é mais importante do que “parir” um sistema remendado de uma hora pra outra e depois perceber que a menor das mudanças custa 10 vezes mais do que o normal.
Por enquanto só consigo me lembrar dessas, mas outras pérolas virão e renderão novos posts.
Fiquem a vontade para comentar. Até o próximo post!