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

65

Ter trabalhado em um projeto com falha é uma das poucas coisas que a maioria dos programadores tem em comum, independentemente da linguagem usada, da indústria ou da experiência.

Esses projetos podem ser ótimas experiências de aprendizado, desastres que esmagam a alma (ou ambos!) e podem ocorrer por uma série de motivos:

  • mudança de administração superior de coração
  • equipe com recursos insuficientes / com recursos insuficientes
  • surgimento de competidor superior durante o ciclo de desenvolvimento
  • sobre / sob gerenciamento

Depois de trabalhar em alguns desses projetos, é possível reconhecer em um estágio inicial exatamente quando um projeto está fadado ao fracasso?

Para mim, um grande sinal é ter um hard & prazo de validade rápido e externo combinado com recurso de fluência . Eu já vi projetos que foram bem planejados e que continuam dentro do cronograma, saindo horrivelmente dos trilhos assim que os últimos pedidos de recursos começaram a aparecer e serem adicionados ao "deliverable" final. Os proponentes dessas solicitações obtiveram o apelido de Columbo , devido a raramente saírem da sala sem pedir "só mais uma coisa".

Quais são os sinais de alerta que você procura, que desencadeiam os alarmes da morte iminente em sua cabeça?

    
por ConroyP 10.07.2015 / 18:26
fonte

38 respostas

70

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á.

    
por 08.09.2010 / 23:35
fonte
44

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.

    
por 06.02.2011 / 01:10
fonte
41

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.

    
por 08.09.2010 / 23:43
fonte
40

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.

    
por 08.09.2010 / 23:37
fonte
33

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.

    
por 08.09.2010 / 23:32
fonte
25
  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.

    
por 11.09.2010 / 19:25
fonte
24

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)

    
por 10.09.2010 / 04:33
fonte
21

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

    
por 10.09.2010 / 04:31
fonte
21

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 ...

    
por 20.01.2013 / 13:31
fonte
21
O primeiro sinal ruim em que consigo pensar é quando a administração não está disposta a transmitir notícias ruins para a cadeia ou para o cliente, na esperança de que isso desapareça - ou seja, o gerenciamento por meio de uma ilusão. Eu não consigo pensar em quantas vezes, os desenvolvedores provaram que não podem cumprir o prazo de semanas ou mesmo meses à frente dele e ainda ninguém quer dizer ao cliente. Eu raramente vi um cliente que não quisesse cumprir um prazo quando houvesse uma razão genuína para quando a necessidade fosse explicada com antecedência; Eu sempre vi um cliente chateado quando disse no dia do prazo que ele não seria cumprido e que não seria cumprido no dia seguinte, mas apenas dois meses na estrada. Neste ponto, eles devem, com razão, acrescentar, questionar seus processos - como você não sabia disso antes? (Resposta verdadeira, mas a que nunca damos - nós sabíamos, mas tínhamos medo de contar para você.)

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.

    
por 10.06.2017 / 11:12
fonte
18

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.

    
por 10.12.2010 / 14:45
fonte
16

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!

    
por 10.09.2010 / 06:08
fonte
16

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.

    
por 10.12.2010 / 14:51
fonte
13

Membros da equipe entediados.

    
por 09.09.2010 / 10:53
fonte
11

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

    
por 10.12.2010 / 18:41
fonte
10
  • 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.

    
por 10.12.2010 / 15:16
fonte
10

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

    
por 02.02.2016 / 14:31
fonte
9

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.

    
por 09.09.2010 / 15:06
fonte
9

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.
por 29.12.2010 / 09:22
fonte
8

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.

Basta dizer que o resto do projeto foi uma marcha da morte masoquista, o congelamento das especificações atrasou, o cliente recebeu um monte de recursos de concessão para compensar a péssima programação que o PM deixou o projeto e a qualidade do projeto. o projeto sofreu tudo por causa disso.

O PM até teve a coragem de voar para CDR (Critical Design Review) apenas para dispensar a reunião com o cliente e jogar um ataque de raiva. Quando ele exigiu que suas despesas de viagem fossem pagas pelo projeto, ele foi educadamente instruído a se entregar a si mesmo.

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.

    
por 11.09.2010 / 13:06
fonte
8
Meu primeiro sinal em um deles foi quando eles perguntaram quantas horas extras de trabalho cada um se comprometeria nas próximas dez semanas e ofereceram aos trabalhadores assalariados um bônus pelo trabalho, disseram horas extras com base no sucesso do projeto e no cumprimento dos prazos. p>

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.

    
por 10.12.2010 / 16:49
fonte
6

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.

    
por 08.09.2010 / 23:21
fonte
6

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.
por 10.12.2010 / 20:30
fonte
5

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.

    
por 08.09.2010 / 23:21
fonte
5

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.
por 05.02.2011 / 19:33
fonte
4

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.

    
por 30.12.2010 / 23:13
fonte
4

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.
por 23.01.2011 / 20:41
fonte
3

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.

    
por 10.12.2010 / 15:26
fonte
3

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."

por 16.12.2010 / 20:46
fonte
3

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

    
por 20.01.2013 / 12:00
fonte