Os erros clássicos da indústria de software
Olá!
Um dos pontos que mais me frustam em se tratando de tecnologia é uma espécie de destino incontrolável dos times de tecnologia a repetirem algumas decisões e obterem sempre os mesmos resultados.
Nesse parágrafo, eu poderia colocar a clássica citação atribuída ao Albert Einstein sobre a definição de insanidade, mas, para evitar coisas repetitivas e ser coerente com a minha própria crítica ao clichê, irei citar algo um pouco menos mainstream: Sísifo.
Sísifo é considerado o mais astuto de todos os mortais e é um personagem que na mitologia grega enganou a morte algumas vezes. É quase um Loki, só que humano.
Porém, o que eu gostaria de abordar hoje não são suas peripécias, e sim, sua punição:
Por toda a eternidade, Sísifo foi condenado a rolar uma grande pedra de mármore com suas mãos até o cume de uma montanha, sendo que toda vez que ele estava quase alcançando o topo, a pedra rolava novamente montanha abaixo até o ponto de partida por meio de uma força irresistível, invalidando completamente o duro esforço despendido.
Se isso te parece a vida moderna, saiba que você não está sozinho. Se você trabalha com tecnologia e achou que parece o trabalho de uma pessoa desenvolvedora, saiba que você também não está sozinho. A expressão Trabalho de Sísifo representa exatamente isso: um trabalho repetitivo (e infrutífero).
Eu gostaria de propor uma análise de literatura que — na posição de profissionais da indústria de software — espero que nos ajude a fugir desse ciclo de agonia.
Steve McConnell, em seu livro Rapid Development, catalogou os erros clássicos que encontrou entrevistando profissionais da indústria de software. O livro é antigo (1996), porém, é impressionante como boa parte desses erros são assustadoramente atuais.
A definição para clássico nesse caso é:
Algumas práticas de desenvolvimento de software não efetivas que são escolhidas frequentemente por tantas pessoas com resultados ruins tão previsíveis que merecem ser chamadas de erros clássicos.
Cometer alguns desses erros é tornar o desenvolvimento de um novo produto lento e caro.
Vem comigo que vou comentar sobre os principais deles para que você não tenha a percepção que está fazendo Trabalho de Sísifo em 2022. Em outros termos: a vida é curta demais para você não aprender com os erros dos outros, não é mesmo?
O livro separa os erros em 4 categorias (Pessoas, Produto, Tecnologia e Processos). Por coincidência, são pilares contidos em quase todos os materiais de transformação digital:
Não se falava em Data e Analytics em 1996, acredito eu. Acredito que seja por isso que esse pilar não esteja no livro.
Na categoria de erros relacionados a pessoas, temos:
Undermined motivation: Impactar a moral do time em troca de ganhos minúsculos de processo ou reduções de custos pífias. Ex: obrigar o time a trabalhar de fim-de-semana para entregar um relatório inútil que o diretor nem se importa tanto assim.
Uncontrolled problem employees: Manter no time uma pessoa problema, seja uma pessoa desenvolvedora Rockstar ou alguém com ausência de soft skills. Pessoas tóxicas tem a capacidade de destruir um time por dentro.
Heroics: A fatídica cultura do herói. Já abordei esse problema aqui.
Adding people to a late project: Essa é Lei de Brooks, do Mythical Man-Month. Já abordei esse problema aqui.
Noisy, crowded offices: Além de causar problemas de audição ou ergonomia, lugares barulhentos (ou muito cheios) podem impedir que uma pessoa desenvolvedora entre na "focus zone", que é onde o grosso da produtividade acontece.
Unrealistic expectations: Essa daqui é para quem já trabalhou em algum lugar que alguém do comercial prometeu um sistema de controle de foguetes ou algo similar feito em duas semanas. O jeito mais simples de resolver esse problema é simplesmente: nunca deixe um profissional não técnico falar pela equipe técnica.
Friction between developers and customers: Se o time de desenvolvimento acha que todo cliente é burro e não sabe usar o sistema ou se o time de negócio muda os requisitos toda hora, a solução é simples: alguém precisa ser o adulto na sala e estabelecer contratos e negociar. Porém, acho que é um problema mais simples que isso: falta de alteridade de ambas as partes.
Lack of effective project sponsorship: Como todo mundo que trabalha em uma determinada área tende a achar que a sua própria área é a mais importante da empresa, sempre haverá a necessidade de priorizar um produto em detrimento de outro (o que irá desagradar alguns gestores de negócio). Devido a isso, é importante que algum executivo esteja bancando aquele produto, para ajudar a desempatar. Sem isso, o produto está fadado a perder força, o que torna o desenvolvimento lento (e caro, por consequência).
Lack of stakeholder buy-in: Se quem é o dono do produto não se importa com ele a ponto de acompanhar de perto e engajar as pessoas naquela missão, não é possível esperar que algo fique pronto da forma correta. Uma solução para isso é o argumento do livro Exponential Organizations: a empresa que tem um propósito forte faz todos os funcionários agirem como stakeholders.
Lack of user input: Nenhum sistema deve ser feito sem que o usuário final esteja próximo. A indústria já se deu conta disso com práticas como Voice of Costumer, a própria existência de um time de UX e termos como Customer-Centric. A mensagem aqui é simples: não podemos regredir (como indústria) nesse aspecto!
Politics placed over substance: Quando a política importa mais que resultados, é o erro que irrita profundamente qualquer pessoa que queira resolver um problema ao invés de ficar aparecendo. Apesar de todo mundo saber que isso não leva a nada (ouso dizer que até as pessoas que jogam esse jogo sabem disso), elas continuam propagando essas práticas porque "vai saber né". Resultado: não há progresso real, somente aquele progresso que não fere o status quo.
Wishful Thinking: É aquela mentalidade não-prática de se deparar com uma situação impossível ou desfavorável e achar que tudo vai ficar bem magicamente no final. Não vai. A solução para isso é pensar: se nada for feito agora, o resultado provavelmente será bem ruim. Isso é basicamente fazer o que tem que ser feito: desde boas decisões em projetos atrasados ou pivotar o modelo de negócios de uma startup. Fazer algo é melhor do que não fazer nada, basicamente.
O catálogo de erros de processos consistem nos seguintes:
Overly optimistic schedules: A forma de condução de um projeto de curto prazo para um projeto de longo prazo é diferente. Portanto, assumir que tudo vai dar certo e não adicionar nenhum tipo de gordura na previsão é receita para dar errado e gerar sobrecarga no time de desenvolvimento quando as coisas derem errado.
Insufficient risk management: Basta apenas uma coisa que deu errado para dar tudo errado. Não ter esses pontos de falha mapeados é um erro tão comum que chega a ser clichê. Porém, senão fosse clichê não estaria aqui, certo?
Contractor failure: O intuito de toda contratação de terceiros é ajudar a fazer algo que você não quer fazer ou não tem know-how de fazer. Porém, não acompanhar de perto é uma receita para o desastre. Além disso, não adianta reclamar da baixa qualidade do trabalho entregue se você não acompanhou de perto.
Insufficient planning: O excesso de planejamento é inútil. A ausência de planejamento nenhum é loucura. Qualquer resultado relevante em qualquer área de conhecimento requer o mínimo de planejamento. Deixar a vida te levar não pode ser vista como um estilo de vida (e nem como uma prática válida de desenvolvimento de software).
Abandonment of planning under pressure: Quem nunca deu aquele bypass maroto no processo no primeiro sinal de problemas ou atraso que atire a primeira pedra. Aqui a dica é: trabalhar com agilidade do jeito certo é um bom equilíbrio entre flexibilidade e entregas relevantes. Aderir ao processo Extreme Go Horse na primeira pressão nunca será uma boa idéia. Eu particularmente acho pressão um anti-pattern de qualquer forma.
Wasted time during the fuzzy front end: O autor chama de fuzzy front-end aquilo que é mais conhecido no Brasil como pré-projeto. O erro consiste em gastar bastante tempo nessa fase com aprovações e orçamentos e depois o projeto nasce com datas de entregas impossíveis devido ao tempo perdido. Aqui a dica é simples: uma mentalidade lean resolve bastante coisa, até isso (afinal, nenhum empresa realmente precisa de vários meses para aprovar algo se quiser ser realmente competitiva).
Shortchanged upstream activities: Toda vez que estamos correndo com algo, deixamos de lado desenhos de arquitetura, testes ou algo similar, pois parecem trabalho não essencial. O único resultado possível disso é: não temos tempo para fazer certo, mas temos tempo para fazer duas vezes.
Inadequate design: Negligenciar o mínimo de arquitetura não fará o projeto andar mais rápido. Portanto, pare e pense no que está fazendo se você quer entregar algo, mesmo que esteja sendo pressionado para tal. Um projeto que não tem esse tipo de análise feita, só chega em uma arquitetura não-ótima (porém, funcional) na base da força bruta e no derramamento de sangue de pessoas desenvolvedoras.
Shortchanged quality assurance: Segundo o autor, um dia de trabalho de qualidade (seja code reviews, testes ou algo similar) não feito custam de 3 a 10 dias a mais de problemas mais para frente no cronograma do produto. Ou em sabedoria popular: um bug em produção custa 100x mais para ser corrigido do que aquele bug que foi pego na fase de desenvolvimento. Qualidade tem que ser algo inegociável.
Insufficient management controls: Para dizer se um projeto está no prazo, ao menos um consenso da gestão sobre o que é "no prazo" precisa existir. Além disso, é algo que precisa refletir a realidade também. Apesar de sacais, há valor em status reports, porém, com uma ressalva: Ferramentas como Screenful acabam sendo um investimento em controle mais inteligente do que pedir para o Scrum Master extrair relatórios manualmente, por exemplo.
Premature or too frequent convergence: O autor chama de convergência aquele período pré-entrega de projeto para integrar trabalho de diferentes lugares. Essa prática hoje em dia não é mais tão comum. De qualquer forma, aqui a solução é simples: Continuous Integration.
Omitting necessary tasks from estimates: Tarefas necessárias que não são contabilizadas no planejamento consomem cerca entre 20 a 30% do tempo total do projeto. Portanto, deixe o trabalho visível, o tempo todo. Nesse ponto, a minha sugestão é o uso de técnicas já documentadas: como limitar o WIP e boards (como o Jira).
Planning to catch up later: Você não vai conseguir recuperar aquele tempo que gastou aprendendo coisas no meio da execução do produto, não se iluda. Use spikes para esse tipo de aprendizado e separe um tempo para aprendizado no planejamento se algumas definições estão nebulosas. Além disso, se o escopo muda, a data prevista de entrega tem que mudar junto, é irracional não fazer isso. Não sou eu que to dizendo, é a restrição tripla.
Code-like-hell programming: Senhoras e senhores, com a palavra o próprio Steve McConnell, daqui (a tradução é minha):
O modelo empresarial é uma fachada para o velho paradigma de codifique errado agora para consertar depois combinado com um prazo irrealista e essa combinação quase nunca funciona. É um exemplo de como dois erros não fazem um certo.
Aqui cabe uma crítica a startups também: nesse meio, existe uma crença que desenvolvedores motivados e engajados são capazes de "fazer acontecer", não importa o quanto desfavoráveis as condições sejam. Muitas vezes, isso é usado para culpar a pessoa desenvolvedora de falhas que muitas vezes são da própria empresa.
Em problemas relacionados a produto, temos:
Requirements gold-plating: O excesso de requisitos em um software sem uma validação da real necessidade por parte dos usuários leva a falha de um produto logo de cara (e encarece muito, dado a quantidade de features inúteis geradas). A solução aqui também já é amplamente documentada: MVPs.
Feature creep: Um projeto comum tem em média, 25% de alterações nos requisitos. Caso isso não seja contemplado ou erroneamente absorvido, também vai deixar a execução mais lenta e cara do que deveria.
Developer gold-plating: A escolha da tecnologia precisa ter um propósito para justificar seu custo de adoção. Um time de desenvolvimento não deve escolher uma tecnologia somente pelo hype.
Push me, pull me negotiation: Pessoas que sabem que o produto está atrasado e aprovam o andamento do mesmo. Porém, outra pessoa (geralmente, um manager), adiciona mais features logo após essa validação (intencionalmente ou não), gerando ainda mais problemas. A solução é simples: decisões coerentes, só isso.
Research-oriented development: Se o seu produto necessita de um novo algoritmo ou novas práticas de desenvolvimento, você não está fazendo software, você está fazendo pesquisa. E pesquisa não tem um cronograma previsível. Portanto, se você está tendo que lidar com escala de uma forma nunca vista antes, pode ter certeza que o desenvolvimento não sairá no horizonte de tempo de um produto comum. A minha sugestão é: tudo bem inovar, mas, sempre alinhe as expectativas.
Em enganos no uso de tecnologia, a lista se resume a:
Silver-bullet syndrome: Não existe uma única tecnologia que resolva todos os problemas. Novamente: senão fosse um erro clichê não estaria nesse texto.
Overestimated savings from new tools or methods: Geralmente, ocorrem grandes expectativas ao trocar de ferramentas (como duplicar a produtividade ou algo parecido). Porém, pelos dados fornecidos no livro, as estimativas mais razoáveis de ganhos ficam na casa dos 10%.
Switching tools in the middle of a project: Trocar a tecnologia no meio da execução do produto geralmente mais atrapalha do que ajuda, dado toda a curva de aprendizado e retrabalho envolvido. É justamente porque o problema geralmente não é a tecnologia… sempre está em algum outro lugar.
Lack of automated source control: Como o livro é um pouco antigo, naquela época não existia Git e controle de versão era algo complicado. Hoje em dia eu espero que não tenha mais ninguém usando arquivos zip ou Subversion como controle de versão.
Em 2008, o autor do livro adicionou mais alguns erros a lista:
Confusing estimates with targets: O time chuta uma data de entrega (geralmente, por pressão externa) qualquer e todo mundo começa a levar aquela data como algo escrito em pedra. A solução aqui é simples e vem da agilidade também: #NoEstimates.
Excessive multi-tasking: Pessoas trocando de contexto de tarefas de forma desordenada geram problemas ao invés de aumento de produtividade.
Assuming global development has a negligible impact on total effort: Distribuir demais o projeto em diferentes lugares ao redor do mundo geram um aumento de 40% no esforço geral de coordenação, comparado com a execução feita por um time só.
Unclear project vision: Não ter uma visão clara do futuro do produto deixa o desenvolvimento lento, caro e frustrante para o time de desenvolvimento, pois um time de desenvolvimento é altamente sensível a indefinições.
Trusting the map more than the terrain: Se o planejamento diz que vai dar bom e a realidade diz que tá dando ruim, quem ganha é a realidade, não o planejamento.
Outsourcing to reduce cost: Existem vários motivos válidos para se terceirizar algo, porém, reduzir o custo de desenvolvimento não é um deles. É bastante parecido com o Contractor Failure, já mencionado anteriormente.
Letting a team go dark: Quando um gestor deixa o time trabalhar sem enxergar o próprio progresso ou visão de futuro. É uma versão complementar do Insufficient management controls, também já mencionado anteriormente.
Para finalizar, segue uma tabela com os dados compilados dos surveys usados como base para a catalogação dos erros feita pelo Steve McConnell — lembrando que era um período pré-pandemia — portanto, peço que interprete com um certo ceticismo e faça as adaptações necessárias para a realidade atual:
A pergunta que eu gostaria de fazer para você que me lê é a seguinte: como podemos com esse conhecimento adquirido evitar o Trabalho de Sísifo nas nossas carreiras?
Até!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
