Todo projeto de software começa com grandes sonhos e grandes visões. Em algum lugar, em um universo alternativo, há um projeto que preenche todos os sonhos. Mas, com frequência maior que a desejada, os projetos de software tropeçam antes de cruzar a linha de chegada.
Você pode acabar com um código que funciona bem, mas ninguém usa. Ou você pode acabar com um código que nem sequer compila.
Aqui está uma lista dos motivos mais comuns pelos quais os projetos de software falham.
1 – Poucos membros na equipe
Os efeitos de tentar fazer muito com poucos programadores são muito fáceis de entender. Há apenas 52 semanas em um ano e as pessoas só podem produzir uma quantidade X de código nesse tempo.
Certa vez, trabalhei em uma equipe em que o gerente achava que a maneira correta de extrair mais trabalho de equipes ágeis era programar cada “sprint” de modo que ele começasse imediatamente após o anterior, não relaxando. Sem nenhuma pausa para descobrir o que estava funcionando e o que estava falhando. As análises era feitas já com outro sprint em andamento, o que não é aconselhável.
É muito complicado adivinhar quantos programadores são suficientes. Às vezes o plano está completo e as estimativas são precisas. Às vezes, barreiras e problemas atrapalham. Pode não ser culpa do gerente que o trabalho dobre de repente, mas se você não tiver pessoas suficientes, seu projeto provavelmente está fadado ao fracasso.
2 – Muitos membros na equipe
Se ter poucos programadores pode ser um problema, muitos pode ser ainda pior. Os mesmos efeitos de rede que tornam algumas plataformas de mídia social tão essenciais também podem condenar um projeto de software. Ter mais pessoas significa ter mais coordenação e isso significa mais reuniões, tirando tempo de escrita de código.
Você pode tentar cancelar reuniões para dar aos programadores mais tempo para criar, mas se você não realizar reuniões suficientes, logo descobrirá que as APIs do Time A não interfaceiam com os microsserviços do Time B.
Muitos programadores podem minar o tempo um do outro, enviando o projeto para um pântano do qual nunca se escapa.
3 – Mudanças fundamentais de recursos
Em teoria, os desenvolvedores gostam de se considerar ágeis. É por isso que eles abraçam a palavra. Mas às vezes a agilidade pode desequilibrar todo mundo. É fácil ser ágil ao mover um botão ou alterar uma cor. Mas quando se trata de retrabalhar o esquema do banco de dados ou copiar e fragmentar a replicação, não há uma maneira fácil de dinamizar o trabalho.
4 – Escolher a tecnologia errada para o trabalho
Mesmo que você planeje cuidadosamente e elabore a lista correta de recursos para o projeto, as coisas podem falhar se você usar a tecnologia errada para criar o conjunto de recursos. Bancos de dados, por exemplo, são projetados para serem tão gerais e flexíveis quanto possível, mas possuem limitações arquitetônicas. Você pode começar com um banco de dados NoSQL e acabar descobrindo, mais tarde, que você realmente precisava de transações ACID para manter as coisas consistentes, que o banco de dados usado não oferece. Oops…
5 – Priorização pobre
Bons planejadores elaboram uma lista de recursos e os priorizam. Mas às vezes as prioridades não se alinham com a realidade de implementação. Nos piores casos, os recursos mais importantes também são os mais difíceis de criar.
Se os desenvolvedores não se concentrarem no recurso mais importante, eles não farão nenhum progresso e poderão acabar não entregando nenhuma das funcionalidades.
Um bom planejamento requer mais do que uma lista de verificação. A visão arquitetônica deve levar em conta as necessidades e o custo de entregá-las.
6 – Fechamento da janela do mercado
Às vezes não é culpa do programador. Um dos meus projetos foi transformar um livro de referência mais vendido em um aplicativo. O livro vendeu como água nos anos anteriores à Internet. O plano era explorar essa demanda e criar uma versão interativa que permitisse às pessoas classificar e pesquisar os dados.
A equipe de programação entregou um software que incluía tudo no livro, mas era mais rápido, mais bonito e muito mais leve que o livro em si. Mas ninguém queria isso. Nós mal podíamos crer. E não foi culpa dos desenvolvedores. O mercado simplesmente não precisava nem queria mais os dados. Havia outras fontes suficientes e ninguém precisava de outro aplicativo que fizesse a mesma coisa que os sites de notícias faziam bem.
Às vezes, uma ideia parece ótima, mas descasada das necessidades do mercado.
7 – Decisões de arquitetura ruins
Em um projeto, recebi a tarefa de alterar um banco de dados. Quando o usuário terminasse de inserir um registrar, deveria ser gerado um número de identificação do usuário. Parece simples, certo? Mas o sistema foi construído em uma arquitetura de microsserviços e não consegui resolver isso escrevendo uma linha de código para fazer o desejado.
O plano arquitetônico era adicionar uma nova chamada de microsserviço à pilha existente e até isso era difícil porque minha primeira chamada de microsserviço precisava acionar outra chamada de microsserviço e assim por diante.
No final, o especialista em arquitetura que criou essa rede de microsserviços me disse que era tudo muito simples e, em seguida, delineou um caminho sinuoso através de cinco camadas diferentes da arquitetura de microsserviços. Então, meu trabalho foi adicionar cinco novas chamadas de API a cinco aplicativos diferentes de microsserviços.
Cada um deles era totalmente independente, o que significava adicionar cinco conjuntos de testes automatizados para cada camada. Cada API de microsserviço foi desenvolvida por uma equipe diferente ao longo dos anos, exigindo que eu compreendesse e emulasse cinco estilos diferentes de codificação. Tudo para mudar um número.
Saí da empresa ante das cinco novas chamadas da API terem sido escritas e testadas com sucesso juntas. Nunca consegui vê-las implantadas.
Decisões de arquitetura podem durar a vida inteira – especialmente se o seu ego estiver completamente investido nelas e você não puder mudá-las. Os gerentes de projeto precisam estar prontos para perceber quando o plano principal de arquitetura não está funcionando, de modo que grandes decisões possam ser tomadas. Se a liderança não puder perceber quando seus planos dão errado, os programadores nas trincheiras continuarão se esforçando para tentar avançar contra um vento contrário impossível causado por um modelo arquitetural ruim.
8 – Conflitos políticos
Culpar os fatores políticos por um fracasso técnico pode parecer um movimento indecoroso, um desvio em vez de um mea culpa, mas é cada vez mais comum e, muitas vezes, verdadeiro. À medida que os projetos crescem e abrangem várias organizações e camadas, não deve ser uma surpresa que as facções apareçam e os grupos participem de controle, recursos e, por fim, de energia.
As facções políticas são diferentes das diferenças técnicas reais. Muitas vezes há padrões técnicos ou bases de código que fazem a mesma coisa de maneiras diferentes. Tome XML e JSON. Agora que eu digitei isso, posso sentir os fãs correndo para explicar por que eles não são os mesmos e a escolha preferida deles é a certa. Eles podem estar certos, mas quando uma parte de uma equipe adora uma escolha e outra parte mantém a facção rival na mais alta consideração, bem, a fricção vai separá-los.
Isso se torna ainda mais comum à medida que os arquitetos dividem aplicativos em vários serviços e APIs menores. Diferentes grupos acabarão controlando estes e nem sempre se darão bem. Se o Grupo A gostar de JSON e o Grupo B se apegar a XML, bem, sua equipe precisará implementar ambos ou fazer com que um deles seja alterado. Todos os três são uma dor para qualquer equipe que vá trabalhar tanto com o Grupo A quanto com o Grupo B.
9 – Apostar em tecnologia que não estão prontas para produção
Os programadores adoram as mais recentes ferramentas e frameworks. Eles querem acreditar que a nova abordagem vai varrer todo o lixo que aflige a geração anterior. Eles têm certeza de que as novas abstrações e rotinas irão unificar, estender e simplificar o que quer que seja que o código deva fazer.
Mas muitas vezes, a próxima geração não está pronta para uso em produção. Os novos recursos podem ser brilhantes e parecerem perfeitos, mas muitas vezes existem lacunas que não são imediatamente óbvias. Às vezes, o código suporta apenas alguns tipos de arquivo ou faz interface apenas com alguns bancos de dados. Os outros estão chegando em breve, eles garantem, mas seu projeto precisa ser lançado este mês e “em breve” pode significar seis meses ou mais antes que os recursos necessários sejam concluídos.
Questões como esta podem condenar projetos de software. A equipe aposta em uma nova tecnologia porque parece resolver muitos problemas importantes, mas em algum lugar ao longo do projeto, geralmente no último trecho, os programadores descobrem que parte da nova tecnologia está faltando. Às vezes sequer está documentada.
10 – Apostar em tecnologia que logo estará desatualizada
É tentador pensar como Goldilocks e culpar a tecnologia que é antiga demais tanto quanto a tecnologia que é muito nova. Na minha experiência, o material antigo é geralmente mais confiável e testado em batalha, o que é mais valioso do que um conjunto completo de recursos. Mas isso não significa que a tecnologia antiga seja perfeita.
Recursos vitais para o seu projeto de software podem faltar quando ele for ativado. Pior ainda, apostar na tecnologia antiga pode fazer com que você perca oportunidades futuras em mudanças posteriores. Novas ideias, protocolos e formatos de arquivo aparecem, e eles podem não ser implementados. E se alguém de uma equipe concorrente insistir em que você a apoie em algum novo protocolo, a velha tecnologia vai pesar.
11 – Prazos irrealistas
Descubra quanto tempo levará e depois duplique, dizem os especialistas. Bom…
Prazos são complicados. Muitos projetos precisam chegar ao mercado em uma determinada data ou evento. No entanto, quando os prazos são escritos pela primeira vez, seus desenvolvedores não começaram a descobrir os obstáculos e barreiras que estão em seu caminho. Então, se o projeto escorregar e o evento passar sem que o software seja iniciado, todo o projeto será visto como uma falha, mesmo que o código esteja prestes a rodar sem problemas. Os prazos ajudam todos a se concentrar e unir, mas também criam expectativas que podem ser irrealistas.
12 – Competição imprevista
Um bom gerente de produto examina a concorrência antes de mergulhar, mas ninguém pode prever que competição pode surgir do nada. Se novos concorrentes introduzirem novos recursos que você deve duplicar, veja as seções sobre alterações de recursos e discordâncias de prioridade, acima.
13 – Apressar o processo
Muitos projetos de software começam como a visão de uma pessoa ou equipe que deseja consertar alguma coisa. Eles criam uma frase como “Snapchat for Y” ou “Uber for Y” e esperam que a equipe de produto seja tão responsiva quanto o Snapchat ou o Uber. O problema é que descobrir o escopo do projeto, esboçar os fluxos de dados e imaginar a interface do usuário é, muitas vezes, mais trabalhoso do que escrever o código.
Os wireframes, o esquema do banco de dados e as histórias de usuários não são apenas um aceno de mão, mas uma parte essencial do trabalho.
14 – Falsa crença no poder do software
Às vezes os sonhadores têm crenças irreais no poder do software para mudar o mundo. Quando empurrar alguns bits em um banco de dados não salva nem transforma ninguém, as pessoas ficam com raiva, entediadas, confusas ou piores. Então eles dizem que o software está quebrado e seguem em frente. Não importa se o banco de dados está funcionando sem problemas e o aplicativo armazena os bits nos lugares certos. O software não consegue entregar a transformação mágica que todos esperavam.
Muitos projetos de software podem compilar, aprovar controle de qualidade, enviar e até mesmo obter avaliações decentes, mas acabam não cumprindo as promessas feitas porque.. bem, essas promessas de mudança do mundo são impossíveis.
Fonte: Computerworld
23 de junho de 2018
