ti-enxame.com

Quais são os sinais de alerta do Doom iminente a serem observados em um projeto?

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 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 do recurso . Eu vi projetos que foram bem planejados e procediam dentro do prazo estipulado de maneira horrível quando Rails) uma vez que os pedidos de recursos atrasados ​​começaram a aparecer e são adicionados ao "produto final" final. um desses pedidos ganhou o apelido de Columbo , devido a raramente sair da sala sem pedir "apenas mais uma coisa".

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

66
ConroyP

Codificação Heroica

Codificar até altas horas 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 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ê vê o projeto, pior ele se tornará.

70
Fishtoaster

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.

44
JohnFx

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; sem requisitos escritos

É o beijo da morte.

41
John MacIntyre

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 tentaremos usar uma linguagem orientada a objetos (mesmo que tudo o que temos sejam desenvolvedores c).
  • Vamos experimentar 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.

41
Fishtoaster

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, onde 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 cliente é dificultada 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.

33
Fishtoaster
  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 muito fora de sintonia 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.

25
MrDatabase

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

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

25
Mawg says reinstate Monica

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 para o cliente na esperança de que elas desapareçam - ou seja, a administração por pensamento positivo. Não consigo pensar em quantas vezes, os desenvolvedores provaram que não podem cumprir o prazo semanas ou meses antes dele e, no entanto, ninguém quer informar o cliente. Eu raramente vi um cliente que não cumprisse um prazo quando houver motivo genuíno para quando a necessidade for 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. (Resposta verdadeira, mas a que nunca damos - sabíamos, mas tínhamos medo de lhe contar.)

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 tiverem perguntas (GRANDE GRANDE BANDEIRA VERMELHA, 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 dar errado. Você adiciona 20 horas de trabalho ao meu prato, o prazo é adiado por 20 horas. Caso contrário, o projeto falhará, garantido.

21
HLGEM

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

21
adolf garlic

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

21
Mawg says reinstate Monica

Um sinal claro que 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 do projeto.

18
Walter

Quando 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!

17
GrandmasterB

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

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

16
user281377

Membros da equipe entediados.

13
Ashalynd

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

12
Scott Whitlock

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

10
Mawg says reinstate Monica
  • 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 você envia - 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 estão com medo do que possa 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)

(Criada por Jim McCarthy's Dynamics of Software Development ).

10
Jon Hopkins

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

9
ChrisF

Desenvolvedores que correm soltos 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 insetos; Estou falando de componentes significativos do sistema que estão faltando recursos ou que pediram funcionalidade e nunca passarão 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.
9
MagicAndi

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

Era um trabalho de contratação e o desenvolvedor mais sênior e o PM decidiram que queriam se juntar para tentar obter um corte maior, para que o outro desenvolvedor mantivesse três semanas de reféns críticos de código. No final, demitimos o incompetente PM (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 por causa disso.

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

8
Evan Plaice

Meu primeiro sinal em uma delas 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 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 um 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.

8
HLGEM

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

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

6
Jaco Pretorius

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 Doom 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 poucas 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, para que eles tenham a chance de cumprir o cronograma provavelmente irrealista, são retirados e dados aos principais executivos para que se sintam bem.
  • Semana um: "Oh, merda, o código está com bugs. 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.
6
Bob Murphy

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

  • Metas absurdamente grandiosas . 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 nunca parece 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 usando tecnologia totalmente nova que ainda não foi comprovada . Como tal, eles conseguem eliminar todos os problemas de escalabilidade com a nova tecnologia.
5
Chris Smith

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.

5
Vaccano

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

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 chamada especificamente para dizer isso.

Ainda tenho que ouvir um gerente dizer algo nesse sentido e fazer com que não acabe sendo uma mentira.

4
Jason Baker

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

3
therobyouknow

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

3
user8685

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

3
Nitsan Wakart

O último projeto profissional em que trabalhei falhou. Uma das razões pelas quais acho que falhou é uma combinação de todas as outras respostas (especialmente nenhuma especificação escrita). Mas acho que a causa principal é a falta de tomada de decisão.

Eu era um desenvolvedor primário e perguntava ao meu gerente como ele queria que algum recurso funcionasse. Sua resposta é "precisamos coletar mais informações de clientes em potencial". Então, trabalhei em uma área diferente do projeto. Eventualmente, chegou a onde eu estava reescrevendo componentes para ficar mais limpo, porque todas as outras áreas do projeto dependiam de decisões não feitas. Perto do fim, comecei a tomar decisões eu mesmo. Fui demitido devido ao lixo do projeto cerca de um mês depois que comecei a tomar decisões.

Resumirei algumas coisas a serem observadas:

  1. Nenhuma especificação escrita
  2. Nenhuma decisão sendo tomada ou, se estavam sendo tomadas, foram formuladas apenas como "faremos dessa maneira e reimplementaremos mais tarde da maneira correta"
  3. Vários prazos perdidos
  4. Equipe inexperiente ou com falta de pessoal (este projeto foi a primeira vez que usei o .Net e, no entanto, fui um desenvolvedor primário!)
  5. Ter que trabalhar em áreas já concluídas porque outras áreas precisam de decisões tomadas antes que o trabalho possa começar. (é claro, estou falando de refatoração por semanas apenas para ficar ocupado)
  6. A ideia de que alguma nova ferramenta reduzirá meses de tempo de desenvolvimento
2
Earlz

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.

Bom, isso é um alívio!

Eu acho que não ter diariamente, útil supervisão da gerência é a chave para detectar fluência. Acredito que, se você tiver as informações corretas, se você conseguir que seus desenvolvedores insiram as informações corretas, poderá detectar derrapagens rapidamente. O que você faz com isso depois disso - bem, isso é mais política e menos dev ...

2
Tom Morgan

Existem muitos sintomas (esgotamento, horas extras, frustração, silêncio ...), mas, no final das contas, você sabe que isso está acontecendo quando as datas de lançamento estão começando a cair e você não consegue mais entregar o produto com a frequência que deveria.

1
Martin Wickman

Bem, a melhor maneira de responder a isso é com um exemplo:

Bob inicia um projeto apresentando uma idéia genial. Ele começa criando um plano para o projeto de software que começa com etapas específicas que precisam ser concluídas. No entanto, as etapas não levam ao resultado final, mas apenas vão uma parte do caminho até lá.

No final, o projeto falha porque os planos estavam incompletos. Não é tanto falta de planejamento quanto é planejamento insuficiente.

0
Nathan Osman

Projetos que estão prontos para produção, mas os recursos continuam sendo adicionados.

Tempo de desenvolvimento longo, sem compromisso claro de liberação.

0
dukeofgaming

Um projeto e futuros projetos estão condenados quando a empresa decide escrever uma "estrutura" interna, porque todas as estruturas disponíveis não atendem perfeitamente às suas necessidades.

0
Jeremy Heiler

Quando a gerência decide, e não oferece espaço para ajustes, em todos os seguintes itens:

  • Data limite
  • Escopo
  • Recursos alocados
0
Pete