20 razões pelas quais os projetos de software falham
cada projeto de software começa com grandes sonhos e grandes visões. Em algum lugar em um universo alternativo, há um projeto que realiza todos os sonhos, mas muitas vezes projetos de software em nosso universo tropeçam na linha de chegada e às vezes o cruzam.
claro, por definição, a falha do projeto de software 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 mesmo compila. Às vezes você pode salvar algo útil dos destroços em chamas e às vezes é melhor fugir antes que ele exploda.
quando a bagunça fumegante esfria, as autópsias começam, pois as pessoas querem saber o que deu errado. Aqui estão os culpados mais comuns.
poucos membros da equipe
tentar fazer muito com poucos programadores é um problema comum. Os desenvolvedores só podem moer tanto código antes de queimar. Certa vez, trabalhei em uma equipe onde o gerente achava que a maneira certa de espremer mais trabalho das equipes ágeis era agendar cada “sprint”, então começou imediatamente após o anterior. A Sprint 42 terminou quarta-feira às 13h59 e a Sprint 43 começou na quarta-feira às 14h00. As reuniões de análise retrospectiva foram agendadas após o próximo sprint já iniciado. Algum cara inteligente sugeriu que eles fossem renomeados como “maratonas” e logo encontraram outro emprego.
claro, é difícil saber quantos programadores são suficientes. Às vezes, obstáculos e problemas atrapalham. Pode não ser culpa do gerente que o trabalho duplique em tamanho, mas se você não tiver pessoas suficientes no trabalho, seu projeto provavelmente está condenado.
muitos membros da equipe
se poucos programadores podem ser ruins, muitos podem ser piores, pois os efeitos de rede podem condenar um projeto de software. Mais pessoas significa mais coordenação e isso significa mais reuniões, tirando um tempo de escrever código. Mas se você não realizar reuniões suficientes, logo descobrirá que a API do Team a não faz interface com os microsserviços do Team B.
seria bom se pudéssemos simplesmente jogar dinheiro em um problema sobrecarregando um projeto, mas você não pode.
muita comunicação
escrever software é uma arte solitária. Os humanos podem trabalhar juntos, mas apenas em ataques limitados. Muitos desenvolvedores odeiam reuniões porque precisam mudar suas engrenagens mentais do profundo pensamento lógico imersivo para o modo social mais aberto. Isso leva tempo. Alguns líderes de equipe tentam combater o fracasso realizando mais reuniões para manter todos sincronizados. É um esforço nobre, mas você pode ouvir as engrenagens moendo. A equipe precisa compartilhar informações suficientes para se manter sincronizada, mas apenas desperdiça os ciclos cerebrais.
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 todos. 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. Mas quando envolve retrabalhar o esquema do banco de dados ou mexer com sharding e replicação, não há uma maneira fácil de girar graciosamente.
escolher a tecnologia errada para o trabalho
Mesmo se você planejar com cuidado e elaborar a lista correta de recursos, as coisas podem falhar se você usar a tecnologia errada. Os bancos de dados, por exemplo, são projetados para serem gerais e flexíveis, mas têm limitações arquitetônicas. Empurre-os para entregar algo que não foram projetados para fazer, e eles demorarão a uma parada virtual quando solicitados a escalar. Ou você pode começar com um banco de dados NoSQL porque eles soam legais apenas para descobrir mais tarde que você realmente precisa de transações de grau ácido para manter as coisas consistentes e o banco de dados não oferece a eles. Oops.
má priorização
bons planejadores elaboram uma lista de recursos e os priorizam. Mas às vezes as prioridades não se alinham com a realidade de implementá-las. Nos piores casos, os recursos mais importantes são os mais difíceis de criar.
o que seus desenvolvedores devem fazer? Se eles se concentrarem no recurso mais importante, eles não farão nenhum progresso e podem acabar entregando nenhuma das funcionalidades. Mas se eles começarem a derrubar os fáceis, 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 consideração as necessidades e o custo de entregá-las.
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 hotcakes nos anos anteriores à internet. O plano era aproveitar essa demanda e fazer uma versão interativa que permitisse que as pessoas classificassem e pesquisassem os dados. A equipe de programação entregou software que incluía tudo no livro, mas era mais rápido, mais bonito e muito mais leve do que o próprio livro. Mas ninguém queria mais. Havia outras fontes suficientes e ninguém precisava de outro aplicativo que fizesse a mesma coisa que os sites de notícias em todos os lugares.
às vezes, uma ideia parece ótima, mas o mercado mudou.
decisões arquitetônicas ruins
em um projeto, recebi o trabalho de alterar um número em uma linha no banco de dados. Quando o usuário terminou de se registrar, eu deveria adicionar o número de identificação do usuário ao pedido mais recente. 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 que diria ao banco de dados para atualizar essa coluna. Nao. O plano arquitetônico era adicionar uma nova chamada de microsserviço à pilha existente e até mesmo 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 gênio arquitetônico que criou essa rede de microsserviços me disse que era tudo muito simples e delineou um caminho serpentino através de cinco camadas da arquitetura. Meu trabalho era adicionar cinco novas chamadas de API a cinco microsserviços diferentes, o que também significava adicionar cinco conjuntos de testes automatizados para cada camada. E cada API foi desenvolvida por uma equipe diferente ao longo dos anos, exigindo que eu entendesse e emulasse cinco estilos diferentes de codificação. Tudo para mudar um número.As decisões arquitetônicas podem durar uma vida inteira-especialmente se seu ego está completamente investido nelas e você não pode mudá-las. Os gerentes de projeto precisam estar prontos para perceber quando o plano arquitetônico principal não está funcionando, então grandes decisões podem ser tomadas.
conflitos políticos
culpar fatores políticos por uma falha técnica pode parecer mal-humorado, mas é cada vez mais verdade. À medida que os projetos crescem e abrangem várias organizações, não deve ser uma surpresa que as facções apareçam e agrupem jockey para controle, recursos e, finalmente, poder.
facções políticas são diferentes das diferenças técnicas reais. Muitas vezes, existem padrões técnicos ou bases de código que fazem a mesma coisa de maneiras diferentes. Pegue XML e JSON. Agora que digitei isso, posso sentir os fãs correndo para explicar por que eles não são os mesmos e sua escolha favorita é a certa. Mas quando uma parte de uma equipe ama uma escolha e outra mantém a facção concorrente na mais alta consideração, bem, o atrito 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 gosta de JSON e o Grupo B se apega ao XML, bem, sua equipe precisará implementar ambos ou fazer com que um deles mude. Todos os três são uma dor para qualquer equipe que deve trabalhar com o Grupo A E o grupo B.
apostando em tecnologia que não está pronta para produção
os programadores adoram as ferramentas e estruturas mais recentes. Eles querem acreditar que a nova abordagem varrerá todo o cruft que atrapalha a geração anterior.
mas muitas vezes, a próxima geração não está pronta para uso em produção. Os novos recursos podem parecer perfeitos, mas muitas vezes há lacunas que não são imediatamente óbvias. Às vezes, o código suporta apenas alguns tipos de arquivos ou interfaces com apenas alguns bancos de dados. Os outros estão chegando em breve, eles garantem, mas seu projeto precisa ser enviado Este mês e “em breve” pode significar seis ou mais meses antes que os recursos de que você precisa estejam completos.
apostando em tecnologia que em breve estará desatualizada
na minha experiência, as coisas antigas geralmente são mais confiáveis e testadas em batalha, mas isso não significa que a tecnologia antiga seja perfeita. Podem faltar recursos que são vitais para o seu projeto de software assim que ele entrar em operação. Pior ainda, apostar em tecnologia antiga pode fazer com que você perca oportunidades futuras com base em mudanças futuras. Novas ideias, protocolos e formatos de arquivo aparecem, e eles podem ir sem aplicação. E se alguém de uma equipe concorrente insiste que você apoie algum novo protocolo, então a velha tecnologia vai doer.
prazos Irrealistas
Prazos são complicados. Muitos projetos precisam chegar ao mercado por uma determinada temporada ou evento. No entanto, quando os prazos são anotados pela primeira vez, seus desenvolvedores não começaram a descobrir os obstáculos e obstáculos 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 funcionar sem problemas. Os prazos ajudam todos a se concentrarem e se unirem, mas também criam expectativas que podem ser irrealistas.
competição imprevista
um bom gerente de produto examina a competição antes de mergulhar, mas ninguém pode prever qual competição pode aparecer do nada. Se novos concorrentes introduzirem novos recursos que você deve duplicar, bem, veja as seções sobre alterações de recursos e incompatibilidades prioritárias, acima.
apressando o processo
muitos projetos de software começam como a visão de uma pessoa ou equipe que quer consertar algo. Eles apresentam uma frase como” Snapchat for Y “ou” Uber for Y ” e esperam que a equipe de produtos seja tão responsiva quanto Snapchat ou Uber. O problema é que descobrir o escopo do projeto, esboçar os fluxos de dados e imaginar a IU costuma funcionar dez vezes mais do que escrever o código. Mas os imagineers querem passar da ideia para o código imediatamente.
os wireframes, o esquema do banco de dados e as histórias de usuários não são apenas acenando à mão, mas uma parte essencial do trabalho. Mas a maioria das pessoas quer acreditar que um projeto de software está apenas escrevendo código para implementar uma ideia.
falsa crença no poder do software
os sonhadores geralmente têm crenças irrealistas no poder do software para mudar o mundo. Muitos imaginaram que as mídias sociais nos uniriam, mas de alguma forma são apenas linhas de falha expostas que sempre foram óbvias. Os projetos de Software geralmente começam com plataformas de slides que prometem revolucionar algum canto do mundo. Ao empurrar bits em um banco de dados não transforma ninguém, bem, as pessoas ficam com raiva, entediado, confuso ou pior. Eles dizem que o software está quebrado porque não consegue entregar a transformação mágica que todos esperavam.
muitos projetos de software podem compilar, passar QA, enviar e até mesmo obter avaliações decentes, mas, em última análise, não conseguem alcançar qualquer uma das promessas no convés de slides porque, bem, essas promessas de mudança do mundo são impossíveis.
Mal subcontratados
amamos os fornecedores que produzem as bibliotecas e ferramentas que nos permitem criar magia com apenas algumas linhas de código. Ocasionalmente, eles ficam com o vento de seu poder e usá-lo para destruir um projeto. A folha de orçamento para a versão 1.0 foi tão boa que a gerência não hesitou em aprovar a versão 2.0. Então o vendedor decide nos apertar triplicando ou quintuplicando o preço.
esse efeito pode ser sentido mesmo quando os fornecedores não o fazem de propósito. Níveis gratuitos podem fazer um projeto parecer muito barato. Então, quando a demanda sobe e a segunda versão expande a demanda, os preços reais entram em ação.
mudança do mar
em um ano com pandemias e protestos, nada mudou mais rápido do que o zeitgeist. O projeto tornou as fortes proteções de privacidade um recurso central? Grito. A pandemia fez com que todos se interessassem pelo rastreamento de contatos. Alguém queria se concentrar em viagens de negócios? Grito. A indústria hoteleira entrou em colapso. Projetos de software maiores que podem levar um ano ou mais correm o risco de serem prejudicados por eventos cataclísmicos. O que parecia uma ideia maravilhosa no início pode parecer irremediavelmente perdido e desconectado quando é hora de ir ao vivo.
mudanças técnicas
não são apenas mudanças no mundo em geral. As mudanças de maré na comunidade de tecnologia podem ter o mesmo efeito. NoSQL já foi uma ideia genial que nos libertaria do esquema relacional. Então alguém percebeu que os arquivos inchavam porque cada registro carregava um esquema local. Uma boa equipe de desenvolvimento ágil pode mudar quando as mudanças tecnológicas do mar mudam as atitudes da liderança e dos clientes. Mas mesmo as equipes mais ágeis não conseguem lidar com grandes mudanças que sugam todo o ar de seus planos arquitetônicos. O sistema foi construído assumindo que X era uma ótima ideia e de repente X é Sujeira. Às vezes é melhor explodi-lo e estrelar novamente.
muitas adições
alguns projetos de software começam bem e até são enviados com sucesso. Em seguida, alguém adiciona um recurso extra ou três, enxertando novo código para a versão existente de uma forma que o código continua a mancar junto. Desenvolvedores heróicos podem fazer isso várias vezes, especialmente se o arquiteto inicial planejou bem. Mas em algum momento, a fundação desmorona. Talvez o banco de dados não consiga lidar com a carga. Talvez haja muitas junções necessárias para satisfazer as várias consultas. Um bom software pode engordar demais, às vezes graças a pequenas melhorias que o empurraram para o limite.
Moving goal posts
os planos iniciais exigiam um banco de dados para rastrear os gastos dos clientes para ajudar nos planos de marketing. Em seguida, algum gênio adicionou um recurso que usa inteligência artificial para correlacionar os gastos com a previsão do tempo. Ou alguém queria que o software oferecesse automaticamente anúncios de mecanismos de pesquisa. Alterar o destino pode alterar um projeto.
é raro que as mudanças arruinem as coisas por conta própria. Mas novos objetivos podem revelar fraquezas e desencadear modos de falha. Talvez a equipe agora seja pequena demais para concluir o projeto com sucesso. Talvez as bases técnicas sejam extremamente ineficientes para a nova abordagem. É difícil para todos antecipar a combinatória ofensiva quando a decisão é tomada para mudar os objetivos.