Quais são os sinais de alerta do destino iminente a ser observado em um projeto? [fechadas]

Codificação Heroica

Codificar até tarde da noite, trabalhar longas horas e registrar muitas horas extras é 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 ter seu único recurso de volta no cronograma, e ele pode ter sucesso; no entanto, a codificação de cowboys é quase sempre o resultado de uma falha de planejamento que inevitavelmente causará mais problemas em breve. Então, quanto mais cedo você ver no projeto, pior ele se tornará.

Quando os programadores começam a ganhar o argumento "O código é horrível, precisamos começar do zero." em qualquer aplicativo maduro.

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

Além disso, um dia você terá que explicar ao gerente do projeto por que, depois de 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 mantenho meus olhos nelas. Quando eles começam a planejar todos os benefícios anunciados dessas ferramentas para o cronograma, fico preocupado. Exemplos divertidos:

• Podemos cortar um mês do cronograma porque vamos tentar usar uma linguagem orientada a objetos (mesmo que todos nós tenhamos desenvolvedores c).
• Vamos experimentar este novo scrum - isso vai resolver todos os nossos problemas de processo!
• Eu sei que está na metade do projeto, mas e se mudarmos os ORMs para algo novo?

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

Para mim, o único grande problema, e um que você pode identificar imediatamente, é quando o negócio considera os requisitos escritos como uma perda de tempo.

Então basicamente; Não há requisitos escritos

É o beijo da morte.

Gerenciamento desconectar

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

• Funcionalidade quando o cliente está falando com alguém que não entende o custo do recurso
• Síndrome do homem-mês, em que novos desenvolvedores são lançados em um projeto com atraso suficiente para ser mais impeditivo do que uma ajuda
• Prazos não realistas, criados por pessoas que têm de lidar com as conseqüências comerciais das decisões de prazo, mas não as conseqüências da implementação.
• Produtos que não resolvem o problema, quando a comunicação com o cliente é prejudicada pelo gerenciamento no meio.
• Gerenciamento de risco inadequado, em que problemas potenciais não são comunicados com a devida antecedência entre os desenvolvedores e o gerenciamento.

Então, quando parece que a gerência não está interessada no projeto, está se comunicando mal, não está ouvindo os clientes, ou não está ouvindo a equipe de desenvolvimento, corra pelas colinas.

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 gravemente fora de contato com a dinâmica da equipe (quem é o "10x super star", quem são os programadores decentes e como eles interagem entre si, etc.).

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

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

Geralmente precede algo que não temos tempo para não fazer, como documentação ou revisões de código (que, estatisticamente, localizam e corrigem mais bugs que qualquer outra coisa, incluindo todas as formas de teste)

Permita que o cliente, o marketing ou a gerência escolha uma data e depois tente retroceder para um cronograma imaginário

Quando o gerenciamento é muito fraco 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 (ou seja, acessar o db sendo executado 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 ...

Outro sinal claro de que a falha está ocorrendo é atribuir novos desenvolvedores à parte mais complicada e mais crítica do processo, em vez das pessoas que já entendem o sistema atual. Então, não os observe atentamente para ver se eles estão realmente concluindo o trabalho corretamente ou se tem dúvidas (BIG BIG BIG BING se não houver perguntas). Novos funcionários precisam ser monitorados até você saber que eles realmente têm as habilidades que eles afirmam ter. Ainda me lembro de ter passado um doloroso verão refazendo o trabalho (já vencido quando consegui) de um novo funcionário que conseguiu uma peça crítica de um projeto e disse a todos que estava tudo bem por meses e depois desistiu sem aviso prévio uma semana depois do prazo final. e nada 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 consegue obter o trabalho atribuído na ordem correta, você está indo pelos tubos.

É claro que o recurso, sem ter que atrasar o prazo, é um dos sinais mais comuns de que as coisas vão ficar ruins. Você adiciona 20 horas de trabalho ao meu prato, o prazo é movido por 20 horas. Se isso não acontecer, o projeto falhará, garantido.

Um sinal claro que vi em minha carreira é quando a gerência começa a falar sobre trazer mais corpos para compensar o tempo no cronograma. Eu 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 fazer. Grande, grande bandeira vermelha!

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

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

Membros da equipe entediados.

Você está "90% pronto", a entrega é na próxima semana, mas tudo bem, porque tudo que você tem é "testar".

• Todo mundo está fisicamente e mentalmente exausto
• Os clientes / usuários estão claramente insatisfeitos com os cronogramas ou com o que estão vendo
• O design originalmente bonito agora parece comprometido
• Você está resignado a enviar alguns erros relativamente significativos que você realmente gostaria de corrigir, mas não conseguirá
• Você está mantendo o orgulho no transporte, e não no que está enviando - mais perto de uma mentalidade de sobrevivência do que de orgulho profissional
• A equipe está com medo de que há certas coisas que não funcionam e estão ignorando essas seções e esperando o melhor, porque eles estão com medo do que pode estar lá
• Todos estão convencidos de que foram além (e estão certos)
• As pessoas estão mostrando sinais de esgotamento (pessimismo geral, desinteresse, raiva)

(escrito a partir da Dinâmica do desenvolvimento de software de Jim McCarthy.

Codificadores Cowboy, grandes egos e aceitação de gerenciamento dos mesmos

Se o plano do projeto exigir uma iteração única de design, desenvolvimento, teste e implantação - a cascata clássica - para um projeto com duração superior a 1 mês, corri uma milha.

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

Desenvolvedores que usam o Wild no intervalo

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 bugs; Estou falando de componentes significativos do sistema que estão faltando recursos ou que não foram solicitados pela funcionalidade e nunca passarão no UAT sem um retrabalho significativo. Esse problema indica que:

• Seu sistema de qualidade está quebrado; por que o desenvolvedor em questão não pegou a questão 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 foram compatíveis? Se você não tiver algum tipo de teste consistente de unidade / integração, você 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 forneçam o que é necessário, eles nunca serão capazes de fornecer uma solução completa.

Quando um desenvolvedor-chave de um projeto não verifica em nenhum código há semanas e um importante marco está chegando.

Era um trabalho de contratação e o desenvolvedor mais sênior e PM no trabalho decidiram que eles queriam se juntar para tentar obter um corte maior, então o outro desenvolvedor realizou 3 semanas de código crítico como refém. No final, demitimos o PM incompetente (que passara 6 meses colocando o projeto em um curso de ruína) e conversamos com o desenvolvedor.

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

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

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

Quando os gerentes estão cometendo 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 11 da noite e antes das 6 horas da manhã.

Quando cada pergunta sobre como lidar com alguma complexidade é recebida com a mesma resposta, "não se preocupe com isso ainda".

Quando eles ainda estão fazendo alterações nos requisitos, no dia em que você apostar, vá para o controle de qualidade ou vá ao ar.

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 estou em reuniões durante todo o dia. Reunião diária de 5 minutos, reunião diária que dura mais de uma hora, não está bem.

Quando a equipe do banco de dados e a equipe de aplicativos não conversam entre si.

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

Quando você considerar a instalação de uma luz de parada fora do escritório de algum gerente para informá-lo se é seguro se aproximar dele naquele dia.

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

A chave, no entanto, é identificar antecipadamente um projeto com falha. Eu acho que o único sinal real da desgraça, neste caso, seria uma completa falta da definição de "quando terminarmos". A menos que saibamos isso no deslocamento, estamos condenados a falhar no IMO.

Eu estive em três marchas da morte nos últimos cinco anos. Aqui estão algumas coisas que contribuíram para a minha intuição de uma desgraça iminente.

• A empresa decide que os desenvolvedores juniores projetem e desenvolvam novos recursos e designe desenvolvedores seniores mais caros para corrigir seus bugs.
• A empresa terceiriza componentes críticos de software para empresas do terceiro mundo que não possuem o domínio necessário.
• Os ciclos de tempo crunch vêm tão próximos que a saúde das pessoas está se quebrando.
• As pílulas que sua equipe leva para drogar a si mesmo para dormir toda noite param de trabalhar.
• O cliente envia pedidos de alteração mais rapidamente do que você pode analisá-los.
• Você deve entregar vários anos de trabalho em algumas semanas, mas a gerência se recusa a congelar os recursos.
• Seus fornecedores de hardware estão claramente tendo problemas para entregar um produto viável dentro do cronograma, e os tomadores de decisão em sua empresa não considerarão nenhuma alternativa.
• Os protótipos de dispositivos necessários para que os desenvolvedores tenham uma chance de conhecer o cronograma provavelmente irreal são retirados e entregues aos principais executivos para que se sintam bem.
• Primeira semana: "Ah, droga, o código está cheio de erros. Todos pararam de fazer novos recursos e consertar bugs." Segunda semana: "Ah, porcaria, não vamos cumprir o cronograma de recursos. Todos param de corrigir bugs e escrevem novos recursos." Repetir indefinidamente.
• O desenvolvimento é feito em um país, e o controle de qualidade é feito em outro país no meio do mundo, então 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 uma língua em que não são proficientes.

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

Isso aconteceu para mim quando um projeto em que eu estava teve a "mudança de gerência superior do coração" bateu nele. Eu estava fazendo perguntas sobre como isso deveria funcionar e, de repente, ninguém tinha uma opinião real.

Pouco tempo depois, o projeto foi cancelado e todo o código bonito que eu escrevi foi descartado.

Paul Vick escreveu um excelente post há alguns anos sobre o buraco negro projetos . Eu acho que todos os conselhos são relevantes. (Eu editei os itens e resumos por extensão.)

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

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

Eu ainda tenho que ouvir um gerente dizer algo nesse sentido e não se tornar uma mentira.

alguns pontos de um projeto que eu fiz parte:

• O gerenciamento dobra a equipe para terminar mais rápido.
• os desenvolvedores começam a "enterrar" bugs para cumprir os prazos e, embora seja óbvio, estão sendo ignorados durante a revisão do código.

Quando o gerenciamento puxa o projeto para diferentes direções simultaneamente e o carro permanece imóvel.

Eu já participei de um projeto gerenciado por dois caras. Ou eles não falavam um com o outro ou cada um tinha algum ego para resolver, mas eles estavam comandando nosso trabalho em direção oposta a cada semana aproximadamente. Não demorou muito para perceber que nunca vai haver qualquer 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 toque dos alarmes:

Portanto, certifique-se de que seu projeto tenha todos os itens a seguir, 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 compromisso das diferentes partes envolvidas em todo o negócio, especialmente a alta administração."

3. "Terceiro é uma 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 claro de que ele falhará, já que a esmagadora maioria deles faz ...