De expectativas exageradas a mudanças fundamentais de escopo, os projetos de desenvolvimento de software são prejudicados – ou são declarados falhos – graças a uma variedade de fatores técnicos e de gerenciamento de projetos. Ou seja, projetos de software falham.
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 os projetos de Software em nosso universo tropeçam em direção à linha de chegada e, às vezes, conseguem cruza-la.
Os analistas podem gostar de lançar números aleatórios para estimar qual porcentagem de projetos de software falham, mas estes são imprecisos por definição porque, bem, o fracasso não é uma coisa binária.
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. Às vezes você pode salvar algo útil dos destroços flamejantes e às vezes é melhor fugir antes que ele exploda.
Quando a bagunça fumegante esfria, as autópsias começam e as pessoas começam a procurar uma explicação do que deu errado.
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 código dentro deste tempo antes de se esgotarem.
Certa vez, trabalhei em uma equipe em que o gerente achava que a maneira correta de extrair mais trabalho de equipes ágeis se dá ao programar cada “sprint” de modo que ele comece imediatamente após o anterior.
Não relaxando. Nenhuma pausa para pensar e descobrir o que estava funcionando e o que estava falhando. A Sprint 42 terminou na quarta-feira às 13h59 e a Sprint 43 começou na quarta-feira às 14h.
Eles até marcaram reuniões de análise retrospectiva após o próximo sprint já ter começado. Algum cara esperto tentou sugerir que eles fossem renomeados “maratonas” e logo encontraram outro emprego.
Claro, fica 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.
Em contrapartida, talvez a culpa do gerente pelo trabalho dobrando de tamanho não seja dele.
Mas, se você não tiver pessoas suficientes no trabalho, seu projeto provavelmente está perdido.
2. Muitos membros da equipe
Se poucos programadores podem ser ruins, pode potencialmente ser 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.
Mais pessoas significa mais coordenação e isso significa mais reuniões, tirando tempo o tempo de desenvolvimento do 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 a API do Time A não faz interface com os micro serviços do Team B.
Muitos programadores podem sangrar o tempo um do outro, enviando o projeto para um pântano do qual nunca escapa. Seria legal se pudéssemos jogar dinheiro em um problema superestimando um projeto, mas você não pode.
3. Mudanças nos requisitos fundamentais
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.
Tudo depende se a mudança requer mudanças fundamentais na estrutura subjacente. É fácil ser ágil ao mover um botão ou alterar uma cor.
No entanto, quando se trata de reformular o esquema do banco de dados ou de fragmentar e replicar, não há uma maneira fácil de articular.
4. Escolhendo 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.
Se você tentar forçá-los a entregar algo que eles não foram projetados para fazer, você poderá leva-los a uma parada virtual quando eles aumentarem.
Ou você pode começar com um banco de dados NoSQL, porque eles soam tão legais apenas para descobrir mais tarde que você realmente precisa de transações de nível ACID para manter as coisas consistentes e o banco de dados não as 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 das implantações.
Nos piores casos, os recursos mais importantes também são os mais difíceis de criar.
O que os seus desenvolvedores devem fazer? Se eles se concentrarem no recurso mais importante, eles não farão nenhum progresso e poderão acabar não entregando nenhuma das funcionalidades.
Mas se eles começarem pelas fáceis, bem, eles podem acabar com algo que é inútil.
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. A janela do mercado fecha
À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 bolo quente 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 do livro, 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 fazer isso. Não foi culpa dos desenvolvedores.
O mercado simplesmente não precisava mais ou não queria mais os dados. Havia outras fontes e ninguém precisava de outro aplicativo que fizesse a mesma coisa que os sites de notícias fazem em todos os lugares.
Os projetos de software podem não falhar por causa da equipe de programação ou gerenciamento. Às vezes, uma ideia parece ótima, mas o mercado seguiu em frente.
7. Decisões de arquitetura ruins
Em um projeto, recebi a tarefa de alterar um número em uma linha no banco de dados. Quando o usuário terminou de se registrar, eu adicionei o número de ID do usuário ao último pedido.
Parece simples, certo?
Mas o sistema foi criado em uma arquitetura de micro serviços e não consegui resolver isso escrevendo uma linha de código que informaria o banco de dados para ATUALIZAR essa coluna.
Não. O plano arquitetônico era adicionar uma nova chamada de micro serviço à pilha existente e até isso era difícil porque minha primeira chamada de micro serviço precisava acionar outra chamada de micro serviço e assim por diante.
No final, o especialista em arquitetura que criou essa rede de micro serviços me disse que tudo era muito simples e, em seguida, delineou um caminho sinuoso através de cinco camadas diferentes da arquitetura de micro serviços. Então, meu trabalho foi adicionar cinco novas chamadas de API a cinco aplicativos diferentes.
Cada um deles era totalmente independente, o que significava adicionar cinco conjuntos de testes automatizados para cada camada.
Cada API de micro serviç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.
Mas quais os efeitos disso?
A equipe foi constantemente sendo retardada por simples solicitações como essa.
Quando saí, as cinco novas chamadas da API foram escritas e acabaram de ser testadas com sucesso juntas. Mas eu nunca consegui vê-las implantadas.
Decisões de arquitetura podem durar a vida toda – 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 ainda possam ser tomadas.
Se a liderança não pode perceber quando seus planos dão errado, os programadores nas trincheiras continuarão se esforçando para tentar avançar impossibilitado por um vento contrário causado por um modelo de arquitetura ruim.
8. Conflitos políticos
Culpar os fatores políticos por um fracasso técnico pode parecer um movimento fraco, um esquivo em vez de um “mea” culpa, mas é cada vez mais verdade.
À 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 do controle, dos recursos e, em última análise, do poder.
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. Veja o XML e JSON.
Agora que eu digitei isso, posso sentir os fãs correndo para explicar por que eles não são iguais 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 tornou ainda mais comum à medida que os arquitetos dividem aplicativos em vários serviços e APIs menores.
Grupos diferentes acabam controlando isso e nem sempre se dã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 doloridos para qualquer equipe que deve trabalhar tanto com o Grupo A quanto com o Grupo B.
9. Apostando em tecnologia que não está pronta para produção
Os programadores adoram as mais recentes e novas 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 o código deve 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 parecem perfeitos, mas muitas vezes há lacunas que não são imediatamente óbvias.
Às vezes, o código suporta apenas alguns tipos de arquivo ou faz interface com apenas 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 ou mais meses 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 e geralmente acontece. Mas em algum lugar ao longo da linha, geralmente no final do trecho inicial, os programadores descobrem que parte da nova tecnologia está faltando. Às vezes nem é documentado.
Os desenvolvedores desse código iriam chegar a ele, mas, bem, você sabe.
10. Apostando em tecnologia que logo ficará desatualizada
É tentador pensar como Cachinhos Dourados e culpar a tecnologia que é antiga demais, tanto quanto a tecnologia que é muito nova.
Na minha experiência, o material antigo geralmente torna-se mais confiável e testado em batalha, o que provoca mais validade do que um conjunto completo de recursos.
Mas isso não significa que a tecnologia antiga é perfeita. Recursos podem estar faltando, algo vital para o seu projeto de software quando ele se ativar.
Pior ainda, apostar na tecnologia antiga pode fazer com que você perca oportunidades futuras com base 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ê apoie algum novo protocolo, a velha tecnologia irá sentir.
11. Prazos irrealistas
Descubra quanto tempo levará e depois duplique-o, dizem os especialistas.
Como se os peritos proverbiais tivessem realmente terminado um projeto em suas vidas. Eles estão sempre oferecendo opiniões em vez de escrever código.
Prazos são complicados. Muitos projetos precisam chegar ao mercado em uma determinada estação ou evento.
No entanto, quando os prazos são escritos pela primeira vez, seus desenvolvedores não começam 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, cuidado!
Todo o projeto é visto como uma falha, mesmo que o código esteja prestes a rodar sem problemas.
Os prazos ajudam todos a se concentrarem e se unirem, 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. Apressando 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 do produto seja tão responsiva quanto o Snapchat ou o Uber.
O problema em descobrir o escopo do projeto, esboçar os fluxos de dados e imaginar a interface do usuário acaba sendo, muitas vezes, dez vezes mais trabalhoso do que escrever o código.
Mas os imaginadores querem passar da ideia para o código imediatamente. (Por quê? Você pode culpar os desenvolvedores que demonstram um novo framework, banco de dados ou coisa sem servidor com a promessa de que você pode escrever um aplicativo finalizado em algumas linhas de 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.
Mas a maioria das pessoas quer acreditar que um projeto de software está em apenas escrever código para implementar uma ideia.
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. Muitas pessoas imaginaram que as mídias sociais nos uniriam, mas de alguma forma elas mostraram apenas linhas de falhas que sempre foram óbvias.
Muitos projetos de software começam com um deck de slides de céu azul que promete alterar algo e revolucionar alguns cantos do 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.
PMG Academy RECOMENDA:
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, passar no controle de qualidade, enviar e até mesmo obter avaliações decentes, mas acabam não cumprindo as promessas feitas no slide do céu azul, porque, bem, essas promessas de mudança do mundo são impossíveis.
Fonte: CIO News
Artigos Relacionados