Quais são os sinais de alerta da destruição iminente a serem observados em um projeto? [fechadas]

Trabalhar em um projeto com falha é uma das poucas coisas que a maioria dos programadores tem em comum, independentemente do idioma usado, indústria ou experiência.

Esses projetos podem ser ótimas experiências de aprendizado, desastres esmagadores de alma (ou ambos!) E podem ocorrer por várias razões:

• mudança de gerência superior de coração
• equipe pouco qualificada / com poucos recursos
• surgimento de um concorrente superior durante o ciclo de desenvolvimento
• sob / sob gestão

Depois de trabalhar em alguns desses projetos, é possível reconhecer desde o início exatamente quando um projeto está fadado ao fracasso?

Para mim, um grande sinal é ter um prazo externo rígido e rápido combinado com a fluência dos recursos . Eu vi projetos que foram bem planejados e procediam dentro do cronograma ir horrivelmente fora dos trilhos quando os pedidos de recursos atrasados ​​começaram a aparecer e foram adicionados ao "produto final" final. Os proponentes desses pedidos ganharam o apelido de Columbo , por raramente saírem da sala sem pedir "apenas mais uma coisa".

Quais são os sinais de alerta que você alerta para acionar os alarmes da destruição iminente em sua cabeça?

Codificação Heroica

Codificar até altas horas da noite, trabalhar longas horas e muitas horas extras são um sinal claro de que algo deu errado. Além disso, minha experiência é que, se você vir alguém trabalhando até tarde em qualquer ponto do projeto, isso só piorará. Ele pode estar fazendo isso apenas para obter seu único recurso de volta ao cronograma e pode ter sucesso; no entanto, a codificação de cowboys como essa é quase sempre o resultado de uma falha no planejamento que inevitavelmente causará mais disso em breve. Portanto, quanto mais cedo você estiver no projeto, pior ele se tornará.

Quando os programadores começam a vencer o argumento "O código é horrível, precisamos começar do zero". em qualquer aplicação madura.

Você pode pensar que pode construí-lo melhor ou entender melhor o problema, mas realmente não. Ah, e todas aquelas manchas feias? Eles são correções para problemas do mundo real que você provavelmente irá reintroduzir na reescrita.

Além disso, um dia você precisará explicar ao gerente de projetos por que, após 6 meses de trabalho, você tem quase 85% da capacidade e 150% dos bugs que o aplicativo tinha quando começou.

Uma nova ferramenta como solucionador de problemas.

Quando as pessoas começam a planejar o uso de ferramentas desconhecidas, não me importo, mas fico de olho nisso. Quando eles começam a planejar todos os benefícios anunciados dessas ferramentas no cronograma, fico preocupado. Exemplos divertidos:

• Podemos raspar um mês do cronograma porque vamos tentar usar uma linguagem orientada a objetos (mesmo que tudo o que temos sejam c desenvolvedores).
• Vamos tentar essa nova coisa de scrum - que corrigirá todos os nossos problemas de processo!
• Sei que está no meio do projeto, mas e se mudássemos os ORMs para algo novo?

Novas tecnologias e práticas são ótimas, mas você quase nunca obtém todos os benefícios imediatamente.

Para mim, o maior problema, e que você pode identificar imediatamente, é quando as empresas consideram os requisitos escritos como uma perda de tempo.

Então, basicamente; Não há requisitos por escrito

É o beijo da morte.

Desconexão de gerenciamento

Quando os responsáveis ​​pelos prazos, recursos, pessoal etc. são desconectados das pessoas responsáveis ​​pela entrega do projeto. Isso pode levar a:

• Recurso lento quando o cliente está conversando com alguém que não entende o custo do recurso
• Síndrome do mês do homem, em que novos desenvolvedores são lançados em um projeto tarde o suficiente para ser mais um obstáculo do que uma ajuda
• Prazos irrealistas, criados por pessoas que precisam lidar com as conseqüências comerciais das decisões sobre prazos, mas não com as consequências da implementação.
• Produtos que não resolvem o problema, quando a comunicação entre o cliente e o desenvolvedor é prejudicada pela gerência intermediária.
• Má gestão de riscos, onde problemas potenciais não são comunicados com antecedência suficiente entre desenvolvedores e gerenciamento.

Portanto, quando parece que o gerenciamento não está interessado no projeto, está se comunicando mal, não está ouvindo os clientes ou não está ouvindo a equipe de desenvolvimento, corra para as montanhas.

1. Quando os principais desenvolvedores saem e o gerenciamento não se importa

2. Quando os principais desenvolvedores saem e nenhum dos outros desenvolvedores se importa

O número um é geralmente indicativo de gerentes que estão severamente fora de contato com a dinâmica da equipe (quem é a "super estrela 10x", quem são os programadores decentes e como eles interagem entre si, etc.).

O número dois geralmente indica falta de interesse grave por parte dos desenvolvedores restantes.

A primeira vez que alguém, normalmente a gerência, diz "não temos tempo para .."

Geralmente precedendo algo que não temos tempo, como documentação ou revisão de código (que encontra e corrige estatisticamente mais bugs do que qualquer outra coisa, incluindo todas as formas de teste)

Deixe o cliente, marketing ou gerenciamento escolher uma data e tente trabalhar de volta para uma programação imaginária

Quando a gerência é fraca demais para dizer "não" ao negócio.

Isso leva a prazos que nunca serão cumpridos, o que leva a uma falta de confiança no departamento de TI, o que leva os desenvolvedores a criar hacks (por exemplo, acessar o banco de dados em execução na máquina de alguém ... em algum lugar), o que leva a um pesadelo para a TI quando o ' sistema crítico "precisa ser migrado, o que leva a ...

O primeiro sinal ruim em que consigo pensar é quando a gerência não está disposta a passar más notícias na cadeia ou ao cliente na esperança de que elas desapareçam - isto é, a administração por meio de desejos. Não consigo pensar em quantas vezes, os desenvolvedores provaram que não podem cumprir o prazo semanas ou até meses antes dele e, no entanto, ninguém quer informar o cliente. Eu raramente vi um cliente que não cumprisse um prazo quando há uma razão genuína para quando a necessidade é explicada com bastante antecedência; Eu sempre vi um cliente irritado quando me disseram no dia do prazo que ele não seria cumprido e que não seria cumprido no dia seguinte, mas a dois meses de estrada. Nesse ponto, eles devem acrescentar que questionam seus processos - como é que você não sabia disso antes.

Outro sinal claro de que a falha está chegando é designar novos desenvolvedores para a parte mais difícil, complicada e crítica do processo, em vez das pessoas que já entendem o sistema atual. Então não os observe com cuidado para ver se realmente estão concluindo o trabalho corretamente ou se tiverem perguntas (BANDEIRA GRANDE VERMELHA GRANDE, se não houver perguntas). Novos funcionários precisam ser monitorados até que você saiba que realmente possui as habilidades que alegou ter. Ainda me lembro de ter passado um verão doloroso refazendo o trabalho (que já era o prazo final quando cheguei) de um novo funcionário que recebeu uma parte crítica de um projeto e disse a todos que tudo estava bem por meses e depois saiu sem aviso prévio uma semana após o prazo e nada do que ele fez foi utilizável.

Outro sinal claro de falha é quando os desenvolvedores estão trabalhando em peças que dependem de outras coisas sendo feitas primeiro e essas coisas não são feitas ou mesmo iniciadas. Se a gerência não conseguir atribuir o trabalho na ordem certa, você estará descendo os tubos.

É claro que os recursos fluem sem adiar o prazo toda vez que é um dos sinais mais comuns de que as coisas vão mal. Você adiciona 20 horas de trabalho ao meu prato, o prazo é adiado por 20 horas. Caso contrário, o projeto falhará, garantido.

Um sinal claro que eu vi na minha carreira é quando a gerência começa a falar em trazer mais órgãos para ganhar tempo no cronograma. Na verdade, nunca vi mais corpos em uma ajuda de projeto.

Quando os gerentes não técnicos começam a insistir em tomar decisões técnicas que eles não estão qualificados para tomar. Grande, grande bandeira vermelha!

O sinal mais óbvio é uma alta rotatividade de pessoal. Quando todo mundo está procurando um novo emprego, você provavelmente deveria também.

O outro sinal altamente óbvio é a falta de progresso. Se um ano se passou e não parece que você esteja mais perto do objetivo, está condenado. Isso acontece especialmente quando os requisitos mudam mais rapidamente do que você pode implementá-los.

Membros da equipe entediados.

Você está "90% pronto", a entrega será na próxima semana, mas tudo bem, porque tudo o que resta é "teste".

• Todo mundo está fisicamente e mentalmente exausto
• Os clientes / usuários estão claramente descontentes com as escalas de tempo ou com o que estão vendo
• O design originalmente bonito agora parece comprometido
• Você está resignado a enviar com alguns bugs relativamente significativos que você realmente gostaria de corrigir, mas não conseguirá
• Seu orgulho restante é o ato de enviar e não o que está enviando - mais próximo de uma mentalidade de sobrevivente do que do orgulho profissional
• A equipe está com medo de que certas coisas não funcionem e estão ignorando essas seções e esperando o melhor, porque têm medo do que pode estar lá.
• Todos estão convencidos de que foram além e além (e estão certos)
• As pessoas estão mostrando sinais de desgaste (pessimismo geral, desinteresse, raiva)

(Criado por Dynamics of Software Development, de Jim McCarthy ).

Codificadores de cowboy, grandes egos e sua aceitação pela gerência

Se o plano do projeto exigir uma iteração única de design, desenvolvimento, teste e implantação - a cascata clássica - para um projeto por mais de um mês, eu percorreria uma milha.

Você não precisa ser totalmente ágil, mas ter ciclos de desenvolvimento curtos permite demonstrar progresso a todos (cliente, gerenciamento e desenvolvedores) e lidar com os requisitos alterados quando o inevitável acontece.

Desenvolvedores que correm soltos em campo

Isso aconteceu quando você percebeu que outros desenvolvedores (ou, infelizmente, você) desenvolveram um componente que varia significativamente do design e que isso não é detectado até o teste do sistema / UAT. Eu não estou falando de insetos; Estou falando de componentes significativos do sistema que estão faltando recursos ou que não pediram funcionalidade e nunca serão aprovados no UAT sem retrabalho significativo. Este problema indica que:

• Seu sistema de qualidade está quebrado; por que o desenvolvedor em questão não percebeu o problema na fase de design / implementação. O código não foi revisado / inspecionado? Por que os testes de unidade e integração não perceberam isso? Se você não possui algum tipo consistente de teste de unidade / integração, está ferrado.
• Seu gerente de projeto / líder técnico não está no controle de sua equipe de desenvolvimento. Se eles não conseguirem que os desenvolvedores entreguem o necessário, nunca serão capazes de fornecer uma solução completa.

Quando um desenvolvedor-chave de um projeto não faz check-in de nenhum código há semanas e um marco sério está chegando.

Era um trabalho de contratação e o desenvolvedor mais sênior e o PM decidiram que queriam se unir para tentar obter um corte maior, para que o outro desenvolvedor mantivesse três semanas de reféns críticos do código. No final, demitimos o PM incompetente (que passava 6 meses colocando o projeto em um curso para arruinar) e conversamos com o desenvolvedor.

Basta dizer que o resto do projeto foi uma marcha masoquista da morte, o congelamento das especificações foi adiado, o cliente recebeu vários recursos de concessão para compensar o terrível agendamento que o PM deixou o projeto e a qualidade do projeto sofreu tudo por causa disso.

O PM ainda teve a coragem de voar para o CDR (Critical Design Review) apenas para abandonar a reunião com o cliente e dar um chilique. Quando ele exigiu que suas despesas de viagem fossem pagas no âmbito do projeto, ele foi educadamente instruído a se prostituir.

Posso me identificar facilmente com pelo menos 5 das outras respostas encontradas aqui que afetaram esse projeto. Em resumo, aprendi muitas lições difíceis no meu primeiro projeto sério de codificação.

Meu primeiro sinal em um deles foi quando perguntaram quantas horas extras cada um de nós cumpriria nas próximas dez semanas e ofereceram aos trabalhadores assalariados um bônus por trabalharem as referidas horas extras com base no sucesso do projeto e no cumprimento dos prazos.

Outros sinais importantes que já vi: a definição de requisitos ultrapassa o cronograma e a data final não é movida. Estávamos atrasados ​​antes mesmo de começar. Eles tiraram o tempo do design, então começamos sem design de banco de dados e design de site, mas esperamos entregar pontualmente, entre outras coisas, fazendo importações para tabelas ainda não projetadas e criadas.

Quando itens no caminho crítico estão sendo feitos simultaneamente, em vez de em ordem. (Se eu precisar usar a ferramenta X e o programador A estiver apenas começando a construí-la, isso atrasará minha tarefa.)

Quando os gerentes estão comprometendo o código no Dia de Ação de Graças.

Quando você começa a receber e-mails com um carimbo de data e hora posterior às 23h e antes das 6h.

Quando todas as perguntas sobre como lidar com alguma complexidade são atendidas com a mesma resposta, "Não se preocupe com isso ainda".

Quando eles ainda estão fazendo alterações nos requisitos, no dia anterior ao controle de qualidade ou ao vivo.

Quando você começa a ter reuniões diárias que levam várias horas para discutir sua falta de progresso. Ah, isso seria porque eu estou em reuniões o dia todo. Reunião diária de 5 minutos, reunião diária que dura mais de uma hora, não é boa.

Quando a equipe do banco de dados e a equipe do aplicativo não se comunicam.

Quando o cliente não pode fornecer as informações prometidas no prazo. Especialmente quando esses são arquivos de importação de dados e você precisa desses dados no banco de dados para verificar como o código está funcionando.

Quando você pensa em instalar um semáforo do lado de fora do escritório de um gerente para informar se é seguro abordá-lo naquele dia.

Eu acho que geralmente é fácil identificar um projeto com falha quando o prazo está chegando. Como você disse, a fluência de recursos combinada com um prazo definido é uma maneira de matar um projeto.

A chave, porém, é identificar com antecedência um projeto com falha. Eu acho que o único 'sinal de destruição' nesse caso seria uma completa falta da definição de 'quando terminamos'. A menos que saibamos disso, estamos fadados ao fracasso da OMI.

Estive em três marchas da morte nos últimos cinco anos. Aqui estão algumas coisas que contribuíram para minha sensação de destruição iminente.

• A empresa decide que desenvolvedores juniores projetem e desenvolvam novos recursos e designa desenvolvedores seniores mais caros para corrigir seus erros.
• A empresa terceiriza componentes críticos de software para empresas do terceiro mundo que não possuem o conhecimento de domínio necessário.
• Os ciclos de crise estão tão próximos que a saúde das pessoas está se deteriorando.
• As pílulas que seu líder de equipe toma para se drogar para dormir todas as noites deixam de funcionar.
• O cliente envia requisições de mudança mais rapidamente do que você pode analisá-las.
• Você deve entregar vários anos de trabalho em algumas semanas, mas o gerenciamento se recusa a congelar os recursos.
• Seus fornecedores de hardware estão claramente tendo problemas para entregar um produto viável dentro do prazo, e os tomadores de decisão da sua empresa não consideram alternativas.
• Os protótipos dos desenvolvedores de dispositivos precisam para que eles tenham uma chance fantasma de cumprir o cronograma provavelmente irrealista e retirados e dados aos principais executivos para fazê-los se sentir bem.
• Semana um: "Oh, merda, o código é de buggy. Todo mundo deixa de fazer novos recursos e corrige bugs". Segunda semana: "Oh, merda, não vamos cumprir o cronograma de recursos. Todo mundo parou de consertar bugs e escreveu novos recursos". Repita indefinidamente.
• O desenvolvimento é feito em um país e o controle de qualidade é feito em outro país do outro lado do mundo; portanto, uma comunicação de ida e volta sobre um bug sempre requer 24 horas, e pelo menos uma das pessoas envolvidas está discutindo problemas técnicos complicados em um idioma em que não são proficientes.

Para mim, é quando aqueles que são responsáveis ​​pelo conjunto de recursos (aka gerentes, proprietários de produtos, clientes ...) param de se importar ou parecem ter um ar sem esperança sobre suas respostas. Perguntas sobre recursos são atendidas com apatia e desânimo. É claro que eles perderam investimento ou confiança no projeto.

Isso aconteceu comigo quando um projeto em que participei teve a "mudança de coração da gerência superior". Eu estava fazendo perguntas sobre como deveria funcionar e, de repente, ninguém tinha uma opinião real.

Um pouco mais tarde, o projeto foi cancelado e todo o código bonito que eu escrevi foi descartado.

Paul Vick escreveu um excelente post há vários anos sobre projetos de buracos negros . Eu acho que todos os conselhos são relevantes. (Eu editei os itens e resumos por extensão.)

• Objetivos absurdamente grandiosos . Como "fundamentalmente reimagine a maneira como as pessoas trabalham com computadores".
• Prazos completamente irrealistas . Geralmente, isso ocorre porque eles acreditam que podem reescrever a base de código original em muito, muito menos tempo do que o original.
• Crenças irrealistas sobre compatibilidade . Como acreditar que você pode reescrever e preservar todas as pequenas peculiaridades sem nenhum esforço extra.
• Sempre "seis meses" a partir do prazo final que parece nunca chegar . Ou, se chegar, outro marco é adicionado ao final do projeto para compensar.
• Deve consumir grandes quantidades de recursos . Geralmente, sugando a força vital de um ou mais produtos estabelecidos.
• Envolva-se usando uma tecnologia totalmente nova que ainda não foi comprovada . Como tal, eles conseguem eliminar todos os problemas de escalabilidade com a nova tecnologia.

Eu traduzo mentalmente "Está tudo bem. Não temos nada com que nos preocupar". para "Estamos todos ferrados" toda vez que ouço a gerência dizer. Você geralmente ouve os gerentes incidentalmente em reuniões não relacionadas ("Ah, a propósito, tudo está indo bem. Não há motivo para se preocupar!"), Mas é uma bandeira vermelha ainda maior ter uma reunião especificamente chamada para dizer isso.

Ainda tenho que ouvir um gerente dizer algo nesse sentido e não parecer mentira.

alguns pontos de um projeto morto do qual eu fazia parte:

• A gerência dobra a equipe para terminar mais rápido.
• os desenvolvedores começam a "enterrar" os bugs para cumprir os prazos e, embora seja óbvio, são ignorados durante a revisão do código.

Quando a gerência puxa o projeto para direções diferentes simultaneamente e o carro permanece parado.

Eu já estive envolvido em um projeto gerenciado por dois caras. Ou eles não conversaram um com o outro ou cada um tem algum ego para resolver, mas eles estavam comandando nosso trabalho na direção oposta a cada semana mais ou menos. Não demorou muito para perceber que nunca haverá nenhum resultado. Felizmente, minha participação durou apenas alguns meses.

Veja este artigo sucinto: Quando os projetos de TI dão certo .

A ausência de qualquer um dos elementos mencionados no artigo deve definir o alarme tocando:

Portanto, verifique se o seu projeto tem todo o seguinte, caso contrário, você deve se preocupar:

(para citar o artigo acima :)

1. "O primeiro é que eles são baseados em uma visão clara do que deve ser alcançado."

2. "A segunda característica diz respeito ao apoio e comprometimento das diferentes partes envolvidas no negócio, especialmente a alta administração".

3. "Terceiro, é a compreensão dos problemas a serem enfrentados."

4. "A característica comum final é que recursos e habilidades suficientes foram disponibilizados".

Estatisticamente, o início de um projeto de software é um sinal justo de que ele falhará, como a maioria esmagadora deles ...