Sou desenvolvedor de uma equipe de 5 membros e acredito que nosso projeto está destinado a um desastre. Descreverei o motivo daqui a pouco, mas minha pergunta é: como devo me comportar?

O prazo é daqui a 1,5 meses e, não importa o que façamos, esse projeto falhará. Sou da opinião de que deveríamos terminar o projeto e parar de desperdiçar nosso tempo, mas politicamente acho que é impossível para o nosso gerente fazer isso.

O que devo fazer neste caso? Devo fazer um esforço extra ou devo ir com calma? E o que devo dizer ao gerente?

Razões pelas quais este projeto está destinado ao fracasso

• Com o prazo se aproximando, muitos dos recursos obrigatórios não estão concluídos
• A aplicação é instável e muito difícil de usar
• O sistema é muito complicado, código muito difícil de entender, muito difícil de mudar - o modelo de dados é muito orientado por um banco de dados relacional complexo (mais de 100 tabelas)
• Liderança pouco clara; o gerente responde a novas informações com grandes mudanças
• Quase nenhum teste automatizado ou teste de unidade
• Depende fortemente de outros sistemas, mas ainda não há testes de integração

Na verdade, nós realmente herdamos esse projeto (junto com a bagunça) cerca de um a dois meses atrás de outra equipe de desenvolvimento sob o mesmo gerente, que trabalhou nele por alguns meses.

Comunique suas preocupações da maneira mais concisa e sem confrontos possível na escada da gerência. Resuma os riscos, mas não imponha sua conclusão sobre eles.

A gerência deve sempre ter a escolha do que fazer, mas é seu trabalho avaliar e comunicar a situação. Use o e-mail, para deixar um rastro de papel quando as coisas vão para o sul.

Feito isso, continue trabalhando no projeto de boa fé.

Lembre-se de que talvez você não saiba tudo o que há para saber sobre o projeto, seus patrocinadores e decisões financeiras por trás dele. As decisões de gerenciamento que parecem estúpidas para você podem realmente se basear em raciocínio inteligente que não é visível para você.

Mantenha uma trilha de papel (por exemplo, diário, e-mails salvos, etc.). Inclua apenas fatos e observações objetivas . Deixe todas as conclusões para quem lê (se houver) o que você escreveu.

Como desenvolvedor, se você não é visto como um obstáculo ao projeto, provavelmente sairá bem do apontar com o dedo que, sem dúvida, acontecerá. Seu gerente pode não ter tanta sorte, mas isso não é relevante aqui.

Apenas de acordo com os princípios gerais, atualize seu currículo e verifique se você ocasionalmente se encontra com outros desenvolvedores fora da empresa. Se você não faz parte de nenhum grupo local de desenvolvedores, junte-se aos 2 ou 3. Demora anos para criar uma rede de amigos e conhecidos, mas a longo prazo vale a pena. Não deixe de vê-la como uma via de mão dupla - se você puder ajudar a preencher uma vaga na sua empresa com alguém capaz, isso é tão bom quanto alguém que ajuda você a encontrar um emprego.

Vou recomendar que você reserve um tempo para ler 2 livros.

A Marcha da Morte é o livro canônico que descreve um estilo patológico de gerenciamento de projetos, amplamente difundido no desenvolvimento de software. Devido à compactação do cronograma, inchaço dos recursos ou má administração, muitos projetos acabam em mau estado; ajuda a entender que você não está sozinho e que seu projeto não é a única marcha da morte. O autor Edward Yourdon classifica os projetos sem saída em quatro quadrantes, cada um dos quais com diferentes estratégias de enfrentamento. Às vezes, a única estratégia de enfrentamento é ir embora. Acho que este livro o ajudará a descobrir qual é o seu leque de opções e a restringir o que você pode ou não fazer.

Desassociação de catástrofe é escrito mais para gerentes de projeto. O objetivo é descobrir como fazer a triagem de um projeto interrompido: o que precisa ser cortado, o que pode ser cortado e como enviar isso aos clientes? O gerenciamento de projetos de software "convencional" nos leva a projetos confusos e não escapamos dos nossos problemas usando o mesmo pensamento que nos levou a eles em primeiro lugar. Este livro é um pouco mais difícil de ler do que a Marcha da Morte , mas é bom ter na sua estante.

3 estratégias simples e cínicas para manter a carreira / sanidade.

1. Veja um desastre de trem em andamento - saia do trem: projetos fracassados ​​são terríveis para a moral e, a menos que você tenha habilidades de gerenciamento ascendente ninja, terá algum impacto negativo em sua carreira. Salte agora se você puder ver algum pouso suave.

2. Se isso não funcionar, mantenha a cabeça baixa: as pessoas vão começar a procurar pessoas para culpar - não facilite para elas! Embora a escalada de preocupações na cadeia de gerenciamento possa ser a coisa certa a fazer, é ineficaz e arriscada. É improvável que o seu próprio gerente passe suas preocupações adiante e ignorá-lo não apenas fará com que ambos pareçam ruins, mas também poderá classificá-lo como um “causador de problemas”, ou seja, o tipo de pessoa que pode ser responsabilizada por minar o projeto em primeiro lugar etc. Isso, é claro, também significa ser profissional, colocar em seu horário, mas sem heroísmo.

3. Planeje uma saída de emergência em T + 1: dê a si mesmo algumas opções e faça as bases para uma possível transferência interna ou externa agora. Falar com pessoas; não há razão para esperar que outras pessoas decidam o que fazer com você quando o financiamento do projeto for cortado ou se afundar na inevitável 'debandada' de pessoas que migrarão em alguns meses.

Desculpas se parece excessivamente cínico, mas se você o chamou corretamente, não há vantagens em sofrer o desagradável surgir no seu caminho. Seja profissional, otimista, mas sempre realista.

Que impacto esse projeto em breve fracassará terá em sua carreira na empresa e além dela? Na minha experiência, apenas estar associado a projetos bem-sucedidos não é um indicador de sua própria excelência pessoal.

As qualidades que você exibe diante da adversidade e, às vezes, o que parece ser um fracasso, geralmente são notadas pelos superiores, mais do que você pensa. E estou falando além do seu gerente imediato.

Pessoalmente, experimentei ver meu gerente imediato ser demitido por incompetência e depois me vi promovido à sua posição no mesmo dia. Não é agradável, mas mostrou que as pessoas estavam me observando e gostaram do que eu fiz.

Muitas vezes, o mesmo caos e desorganização que vem com um projeto em falha, oferece a você a oportunidade de brilhar.

Portanto, olhe o projeto da seguinte maneira: que oportunidade esse projeto fracassado oferece para que a luz brilhe em todos os meus pontos fortes e melhores qualidades? Que lições estou aprendendo dessa experiência que me tornará um profissional melhor e uma pessoa melhor?

Essencialmente, a soma de experiências extraídas de falhas é o que alimenta o verdadeiro sucesso.

Nota: Thomas Owens perguntou: que coisas específicas uma pessoa pode fazer em um projeto como este. Tenho algumas sugestões gerais, que usei como diretrizes pessoais nessas situações. Ajudará um projeto de angústia a milagrosamente ter sucesso? Não - mas descobri que me ajudou a manter uma perspectiva adequada das coisas e a ter sucesso pessoal, apesar da situação ruim.

1) Concentre-se na excelência pessoal - procure escrever um código cada vez melhor, atenda a padrões cada vez mais altos de qualidade e funcionalidade.

2) Concentre-se em métricas pessoais - quanto código você escreve e gera bugs subsequentes? Reduza essa proporção para o menor valor possível. Quando solicitado a fornecer uma estimativa para uma tarefa atribuída a você, você geralmente é preciso ou acha que superou ou subestimou demais a linha do tempo? Quando uma tarefa é realmente atribuída, você fornece um bom nível de feedback sobre a progressão do trabalho, incluindo um aviso prévio com antecedência dos problemas do cronograma de entrega?

3) Concentre-se nas métricas da equipe - Essas são apenas algumas coisas que estão fora de minha cabeça: outros membros da equipe estão atrasados ​​devido à dependência de uma tarefa na qual você está trabalhando? Você é bom em delegar ou dividir suas tarefas / subtarefas para outras pessoas da equipe? Você acha difícil se comunicar com um ou mais membros da equipe? Todas as áreas em que trabalho para melhorar regularmente.

Em uma situação como essa, como o degrau mais baixo da escada, há muito o que você pode fazer para ajudar o projeto.

• Verifique se o seu trabalho é impecável
• ajudar a identificar as maiores áreas problemáticas
• Tente fornecer respostas, não apenas problemas. Parece que você está tentando corrigi-los.

Além disso, você realmente precisa cuidar do número 1.

• Documente tudo
• mantenha todos os emails, conversas por mensagens instantâneas
• Tente encontrar uma saída do projeto, se possível

Projetos fracassados ​​podem ser tóxicos para a alma, causar depressão, excesso de trabalho e baixa auto-estima.

É tudo relativo à perspectiva.

Eu trabalhei em projetos horríveis enquanto me sentava diante de outro cara que tinha um sorriso no rosto todos os dias. Oh, como eu queria tirar esse sorriso de seu rosto.

Algumas pessoas não se incomodam com o estado atual de um projeto. Eles apreciam sua contribuição, suas tarefas e estão trabalhando no domínio de seus interesses. Enquanto outros, têm uma forte reação negativa ao estado atual das coisas. É tudo sobre nossas expectativas percebidas para o nosso trabalho diário.

Enquanto você pode estar fazendo um pouco do trabalho de que gosta. Há claramente elementos no projeto atual que você não gosta.

Você precisa identificar quais são esses elementos problemáticos e resolvê-los.

• pressão de prazo
• controle de qualidade
• profissionalismo
• orientação pela gerência

Existem muitas equipes e empresas que não consideram importantes os aspectos de desenvolvimento acima. O que eu descobri é que eles costumam pensar o seguinte.

• A pressão do prazo é percebida como uma maneira de motivar as pessoas.
• Qualidade custa mais e limite de devoluções.
• O profissionalismo se aplica a outras áreas do negócio.
• Um gerente é um cronometrista e não uma pessoa que contribui para o desenvolvimento.

Esses problemas não são seus. É deles, e você não deve desperdiçar energia com o comportamento deles. Se você não é um dos caras que sorri e gosta do trabalho dele, mesmo quando se dirige para um penhasco, pense em encontrar um lugar para like mindeddesenvolvedores.

Você será muito mais feliz.

Tente ser proativo em encontrar uma nova maneira de obter sucesso no projeto. Pense em como você pode propor algumas alternativas. No momento, seu chefe provavelmente está se espantando com o fato de o projeto ser um fracasso, ele não gostaria que alguém viesse com soluções em vez de problemas?

Talvez haja uma maneira de dividir os recursos em entregas escalonadas? Muitas vezes, existem graus de "must have"; portanto, veja se você consegue priorizá-los e agrupe-os em marcos. É melhor ter algum produto no final da linha do tempo do que nada. Ou considere dividir a equipe entre pessoas que trabalham em novas funcionalidades e outras que trabalham na estabilidade, dessa forma, você pode mostrar algum progresso nas duas frentes.

Se esses esforços forem bem-sucedidos, você terá mostrado que é um membro da equipe que pode encontrar uma maneira de obter sucesso; caso contrário, ainda demonstrará que não desiste e trabalhará para encontrar uma solução.

Parece a maioria dos projetos em que estive. Provavelmente não terminará tão mal quanto você pensa, no entanto:

1) Faça seu trabalho. Não se preocupe tanto com o projeto geral, desde que você complete suas responsabilidades.

2) CYA. Se o projeto falhar e você suspeitar que o gerente começará a culpar todos, menos a si mesmo, verifique se você tem provas suficientes de que fez tudo o que era necessário (consulte o item 1).

3) Faça algumas sugestões educadas para melhoria. Não toque os sinos de advertência, não seja desolador e sombrio, apenas seja educado e sutil.

Por exemplo, se a equipe não estiver escrevendo testes de unidade eficazes (ou quaisquer testes), escreva alguns testes de unidade mais próximos do que você gostaria de ver e mencione como causal isso ajudou a resolver um problema específico ou economizou seu tempo.

Seja o que for, se você quiser afetar a mudança, concentre-se nas etapas positivas que têm resultados concretos. Esse projeto pode nunca se tornar um vencedor, mas talvez a equipe possa aprender para o próximo.

Além disso:

4) Refatoração oportunista é seu amigo.

1. Trabalhar duro; mas não à custa da sua família ou da sua saúde.
2. Mantenha um registro de todas as decisões críticas de design; especialmente no que se refere ao seu trabalho.
3. Mantenha a rede e mantenha suas opções em aberto se a situação se tornar muito difícil ou você for vítima de uma demissão em massa.
4. Tente não pensar no seu projeto como um "projeto com falha". Todo mundo gosta de pessoas que permanecem positivas e lutam muito diante das adversidades. Portanto, pelo maior tempo possível, tente ser essa pessoa. Uma perspectiva positiva, determinação e determinação são sempre boas para o local de trabalho.
5. Se você está antecipando um projeto com falha, está antecipando uma reunião post mortem. Na reunião post-mortem, todos serão responsabilizados. Esteja preparado para defender todo o seu código. [Nota: Como regra geral, você deve sempre escrever um código limpo para que seja fácil defendê-lo mais tarde.] Se você tiver um email ou documento de design que inspirou suas decisões, será ainda melhor.
6. Na reunião post-mortem, tente permanecer positivo; e apresente apenas seu e-mail e a evidência do documento de design se seu julgamento, esforço ou mão de obra forem questionados.

O que eu achei mais eficaz é a recomendação de Robert L. Read sobre como combater a pressão do cronograma . Aqui está o que Read escreve:

A chave para combater a pressão do cronograma é simplesmente transformá-la em pressão de chegada ao mercado. A maneira de fazer isso para dar visibilidade à relação entre o trabalho disponível e o produto. Produzir uma estimativa honesta, detalhada e, acima de tudo, compreensível de todo o trabalho envolvido é a melhor maneira de fazer isso. Ele tem a vantagem adicional de permitir que sejam tomadas boas decisões de gerenciamento sobre possíveis trocas de funcionalidades.

O principal insight que a estimativa deve deixar claro é que o trabalho é um fluido quase incompressível. Você não pode empacotar mais em um período de tempo mais do que empacota mais água em um contêiner além do volume desse contêiner. De certa forma, um programador nunca deve dizer 'não', mas sim dizer 'O que você vai desistir para conseguir o que deseja?' O efeito de produzir estimativas claras será aumentar o respeito pelos programadores. É assim que outros profissionais se comportam. O trabalho árduo dos programadores será visível. Definir um cronograma irreal também será dolorosamente óbvio para todos. Os programadores não podem ser enganados. É desrespeitoso e desmoralizante pedir que façam algo irrealista.

Quando você diz que o projeto está "pronto para o fracasso", isso se baseia em sua avaliação de quais tarefas precisam ser realizadas e quanto esforço cada uma delas exigirá. Faça essa avaliação explícita , compreensível e detalhada . Separe as tarefas em suas partes componentes; explique com o máximo de detalhes possível como será gasto o tempo de desenvolvimento.

Depois de fazer isso, você tem uma base sólida para discutir preocupações com a gerência. Com toda a probabilidade, depois de dividir sua avaliação em todas as tarefas específicas que precisam ser concluídas, você poderá demonstrar que o trabalho leva mais tempo do que o necessário - possivelmente muito, muito mais.

Depois de discutir esse cronograma detalhado com seu gerente, esteja preparado para ser flexível. Seu gerente pode dizer: "A Tarefa X não levará um mês; levará uma semana no máximo" ou "A Tarefa Y é totalmente desnecessária, retire isso do cronograma". Você certamente pode discutir esses pontos, mas o mais importante é alcançar um entendimento entre você e seu gerente sobre uma versão realista de um cronograma. Dessa forma, se você não está alocando tempo para, digamos, testar, então você tem uma diretiva explícita para não testar, em vez de ficar sem tempo "inesperadamente". E é definitivamente possível que seu gerente esteja legitimamente disposto a cortar explicitamente certos cantos para chegar a tempo. Há muitos casos em que isso '

A estimativa fornece substância concreta para debate e discussão. Coloca você na mesma página; ajuda você a se sentir confiante de que seu gerente levou em consideração suas preocupações. E isso leva você a um ponto em que, se seu gerente está claramente pedindo o impossível, será perfeitamente evidente para os dois. Se o projeto estiver bem e verdadeiramente condenado, você terá deixado isso claro e caberá ao seu gerente decidir com precisão como ele deseja que você gaste seu tempo.

Como seu gerente sabe que provavelmente falhará, você está melhor do que a maioria. Eu consideraria trabalhar com o gerente e ver se existem partes / recursos do aplicativo que possam ser excluídos.

Com muita frequência, achamos que cada solicitação de cliente é um 'matador de ofertas' e nos esforçamos para prometer a entrega. Até que alguém trabalhe com o cliente e analise mais profundamente, talvez você não consiga tomar essas decisões. Se você não conseguir fazer isso, tente entregar o que acha mais importante. Às vezes, é mais fácil pedir perdão do que permissão.

Participei de três projetos que foram claramente fracassos. Isso foi bastante doloroso, mas olhando para trás, dois dos três não tiveram consequências negativas na minha carreira, e mesmo o terceiro não foi o fim do mundo.

Aqui estão algumas observações que eu lembro.

Desenvolvedores em posições juniores ("código por especificação", "consertar o bug", coisas assim) não são afetados muito, a menos que relaxem devido ao moral reduzido na equipe. Em posições como essas, uma estratégia de sobrevivência sensata e, às vezes, bem-sucedida pode estar apenas fazendo o melhor que você pode.

• ^{Por exemplo, uma das falhas que experimentei foi superada pela correção simples e metódica de mais de cem bugs conhecidos que (juntamente com uma abordagem particularmente inteligente de promover esse progresso pelo líder técnico) acabaram levando a alta gerência à decisão de recuperar o projeto e fornecer mais uma chance com um novo lançamento, que, por sua vez, obteve um sucesso razoável.}

Programadores em posições influentes mais seniores estariam melhor preparados para compartilhar as consequências negativas do fracasso do projeto. Espera-se que um arquiteto, líder técnico e desenvolvedor sênior cause um impacto grande o suficiente para ser considerado responsável pelo sucesso ou fracasso do projeto.

Na posição sênior, seria melhor estar preparado para ganhar com a falha "indiretamente", analisando o que deu errado e o que poderia ter sido feito melhor.

Esses conhecimentos, lições post-mortem podem ser inestimáveis ​​se aprendidos corretamente, a carreira de muito sucesso em cargos seniores pode depender de quão bem eles são aprendidos, conforme explicado nesta brilhante resposta no WP :

O julgamento não vem do sucesso, mas de fracassos. A maioria das empresas deseja contratar pessoas que tiveram suas falhas pagas por empresas anteriores ...

Em uma nota mais prática, pode-se considerar a abordagem "próxima versão / atualização" como uma possível saída da falha. Coincidentemente ou não (acho que não ), mas as duas falhas que não prejudicaram minha carreira passaram por cenários muito semelhantes: o lançamento Nfoi um desastre total, o lançamento N+1foi tolerável, o lançamento N+2e, posteriormente, o sucesso.

Andando no seu lugar, eu provavelmente colocaria algum esforço na preparação / promoção da idéia de "próximo lançamento". Faça (e comunique !) Algo como uma lista provisória de problemas conhecidos que você deseja corrigir após a liberação planejada. Rascunhe um roteiro informal e áspero para os próximos lançamentos.

Pense em como você pode comunicar essas idéias às pessoas ao seu redor, como você pode influenciar a gerência a considerar esse plano. Se o projeto tiver alguém com boas habilidades de marketing, tente envolvê-los na amortização do dano por falha, agrupando a versão futura em termos mais suaves, como "acesso antecipado", "beta", "visualização do cliente", "versão introdutória", coisas como este.

Pense em um plano de backup para o caso de altos aparecerem surdos a essa idéia. Lembre-se da história acima sobre "consertar mais de cem bugs conhecidos"? realmente há uma chance de as coisas mudarem.

A gerência pode parecer surda às idéias do próximo lançamento agora, mas há uma boa chance de reconsiderar diante de fortes evidências convincentes do progresso da qualidade do projeto.

• ^{É bem provável que haja muito tempo entre o congelamento do código para a liberação planejada e a decisão de gerenciamento para eliminá-lo completamente. Essa é a sua chance: se você se concentrar em resolver problemas conhecidos e "evangelizar" adequadamente o progresso, isso pode fazer a diferença (como antes me ocorreu).}

Já existem vários conselhos práticos (e de outra forma) aqui, mas para mim as chaves desse mistério são os dois itens a seguir (ênfase minha):

O prazo é de 1,5 meses

e

... na verdade, acabamos de herdar este projeto (junto com a bagunça) cerca de 1 a 2 meses atrás de outra equipe de desenvolvimento sob o mesmo gerente ...

Assim....

Bem-vindo à equipe Patsy Os Vingadores

A equipe anterior tinha coisas melhores para fazer ... do que falhar. E de alguma forma o gerente concordou com isso. Mudar de equipe tão perto do prazo não é a melhor jogada de gerenciamento de projetos a ser feita, então ... o que há com isso?

Correção: A equipe anterior foi substituída, ~ 3 meses antes do prazo.

-> Descubra como a equipe de desenvolvimento anterior conseguiu escapar e faça isso. <-

Três meses são apenas tempo suficiente para acelerar um sistema com esse tamanho aparente, muito menos corrigir sua arquitetura, adicionar testes e finalizá-la. Você precisa de mais tempo

E se você não pode fazer isso, a menos que tenha certeza absoluta de que o projeto será estendido indefinidamente ou auxiliado por elfos mágicos ou algo assim, você não quer ser o último homem que está segurando a sacola.

Harsh? Sim. Mas, embora o planejamento deficiente (pelo menos!) Das equipes / gerentes anteriores não seja sua culpa, o "não cumprimento" será .

A equipe anterior foi socorrida . A equipe anterior foi chutada até o meio-fio. O que isso lhe diz? Isso me diz que você é a equipe de recuperação ... e seu gerente está contando com seus heróis para salvar o dia.

Uma equipe de 5 pessoas e faltam 1,5 meses. A nova equipe teve o projeto apenas por um a dois meses, portanto, a nova equipe não está nem na curva de aprendizado . Adivinhando o tamanho deste projeto, parece-me que não há como a nova equipe ultrapassar a curva de aprendizado, mesmo que o projeto não tenha problemas.

Então, eu (ainda) acho que você foi enganado.

Se for esse o caso - e apenas você pode decidir o que é verdade ou o que você quer acreditar - você não deve a ninguém uma explicação ou um pedido de desculpas por sair do caminho desse acidente de trem. Você precisa ser discreto sobre isso.

Duvido seriamente que o gerente não esteja ciente de que o projeto está em risco, o que significa que explicações gentis receberão apenas uma atenção negativa. A menos que seu gerente seja o Sr. Rogers , seu futuro está em risco.

Mas lembre-se sempre : não tome conselhos profissionais de estranhos na Internet.

Esta é uma oportunidade incrível para você! Vamos assumir um ponto de vista empresarial sobre isso.

Supondo que a gerência deseja que esse projeto seja bem-sucedido, você está em uma ótima posição para ajudá-lo a fazê-lo. A razão pela qual essa realização é tão importante é porque você precisa desenvolver a convicção e a confiança de que os sinais de alerta que está vendo levarão ao fracasso deste projeto [1].

Esta é sua chance de praticar habilidades importantes no pensamento sistemático e na comunicação interpessoal. Entenda e visualize os problemas e as oportunidades potenciais que estão sendo perdidas, para que você possa desenvolver uma estratégia para comunicá-los da maneira mais clara e simples possível.

Reconheça sua oportunidade aqui para melhorar suas habilidades.

[1] Cancelar o projeto seria realmente um sucesso. O fracasso seria gastar um bom dinheiro depois do mal.

O que você pode fazer

• Trate isso em seus próprios termos de auto-excelência, é o projeto "deles", mas também o seu, tome posse mesmo sabendo que falhará. Por quê? porque a) você pode ajudá-lo a fracassar um pouco menos, b) em tempos de desafios, é aqui que você aprende mais c) você deve se medir por meio de suas próprias métricas de excelência, fazer o seu melhor pode não salvar o projeto, mas você pode acabar ainda orgulhoso de si mesmo

• Converse com outros colegas desenvolvedores e veja o que eles pensam. Você provavelmente descobrirá que muitos compartilham a mesma frustração, se feitos com cuidado (não faça as pessoas pensarem que deseja iniciar um motim ou algo assim), isso pode ajudar não apenas você, mas outros também

• Ignorar o problema não vai fazer com que ele desapareça, falar sobre maneiras de como, apesar de todas as probabilidades, ainda pode ser resolvido, por exemplo, pelo menos obter alguns itens decentes, ou o principal caso de uso do "fator uau" feito corretamente, pode fazer com que isso aconteça. projeto falhar menos miseravelmente. Como fazer isso? bem, poucas idéias de "quando as coisas ficam difíceis são difíceis" ou "tempos desesperados justificam medidas desesperadas" e outros clichês, por exemplo: uso maciço de OSS, programação extrema / metodologias ágeis, hackathons de fim de semana (apenas voluntários, não forçando as pessoas a finais de semana de trabalho). Este é o momento em que você pode mostrar liderança (com cuidado, se não estiver em uma posição de líder / sênior de equipe), mas você pode aproveitar essa vantagem e tornar-se o mockingjay deles, apenas faça com que as pessoas sintam que podem obter esse projeto com um pouco menos de falha do que todo mundo sabe que sim.

• Certifique-se de que sua gerência saiba, mas com muito cuidado, se eles souberem, eles apreciarão que você diga isso de uma maneira calma e sem confrontos; se não, eles apreciarão ainda mais e se perguntarão por que ninguém disse eles sobre isso antes. Você deve dizer isso a eles como um serviço, sem nenhum lado emocional, apenas fatos simples e sem uma agenda. Se eles perguntarem o que você acha que devem fazer (o que é um ótimo sinal, mas raro), consulte a próxima seção

O que você não pode fazer, mas sua gerência provavelmente deveria

• Eles não devem adicionar mais pessoas ao projeto "para ajudar" a ver isso

• Ligue para o cliente imediatamente e conte as más notícias. Por que essa é uma boa ideia? bem, vou deixar citando o manifesto para o desenvolvimento ágil de software, mas mesmo sem ele, até os amantes de quedas d'água odeiam más surpresas. Se o cliente souber com antecedência que este projeto está fadado ao fracasso, ele ficará insatisfeito, mas ficará muito mais feliz ao dizer que há problemas antes que ele apareça na cara deles, e que você está nele e fazendo o possível para acomodar isto. O cliente pode fazer muitas coisas, mas a maioria delas não é pior do que descobrir no último minuto que não possui um produto a ser entregue (ou o faz, mas é de qualidade não utilizável). O cliente irá apreciá-lo, pois poderá adiar a contratação de equipes de teste, pessoal de TI offshore, alterar seus planos de treinamento interno e tudo porque você foi honesto com eles.

• com o cliente, pense em maneiras de ainda tirar algo do projeto, o mais comum é desvalorizar as coisas. por exemplo, pode haver alguns recursos que são muito difíceis de desenvolver da maneira como foram projetados e, se o cliente concordar com algumas pequenas modificações e simplificações, alguns recursos se tornarão mais simples.

• Atualize seu próprio gerenciamento superior, que também os ajudará a manter seu emprego ...

O que você NÃO deve fazer

• Peça para adicionar mais pessoas ao projeto (veja isso )

• Saia / procure outro emprego (pelo menos ainda não), isso é algo que você pode aprender e o que o tornará um dia um desenvolvedor ou gerente melhor. Você aprenderá a apreciar muitas coisas melhor, gerenciar melhor o tempo, projetar melhor, escrever melhor o código e trabalhar melhor com os colegas e o gerenciamento. Procure um emprego após esses dois meses, se você não gosta de trabalhar lá, não por qualquer outro motivo.

• Lamentar, reclamar ou ser negativo sobre o projeto, gerenciamento, o design ruim que você herdou, os desenvolvedores iniciantes que você orientou que você leva 3 horas para explicá-los a fazer algo que leva 1 hora, seja positivo quanto você pode.

• Critique a gerência e torne-se um alvo como criador de problemas, eles estão no mesmo barco e podem saber coisas que você não conhece, tudo o que você pode fazer é atualizá-las (sempre atualize seu próprio gerente direto, nunca ignore-o)

• Culpar as pessoas (ou você mesmo), isso não ajuda, nunca

• Leve isso muito a sério, a menos que seja um equipamento médico, é provável que ninguém morra se você perder os prazos, é um software, nós perdemos os prazos de vida, relaxe.

Isso é apenas meus dois centavos, YMMV

Encontre os problemas nos quais seu projeto está se deparando e tente quantificar claramente o mais objetivamente possível. Com cada "métrica" ​​quantificada, certifique-se de definir por que você acredita que essa métrica é importante. Você deseja fornecer ao seu gerente informações sobre quais seriam as consequências se uma determinada métrica não estivesse dentro do "intervalo aceitável". Você precisará fornecer algumas diretrizes para cada métrica para indicar quais valores são "Bom", "Aceitável", "Problemático" ou "Ruim". Defina todos os critérios antecipadamente. Se possível, você poderia descrever o que seria minimamente necessário para um projeto ser bem-sucedido e contrastar isso com o projeto atual.

• A qualidade do código estático pode ser quantificada por várias ferramentas de análise estática. Você pode manter isso tão simples ou detalhado quanto achar melhor. As métricas sugeridas por você começam com:
  • Complexidade ciclomática
  • Tamanho do seu código (por exemplo, Nº de linhas por função / classe, número de arquivos, número de tabelas ...)
  • Identifique quais módulos são muito grandes
  • Duplicação.
  • Adesão ao estilo do código
• Taxa de defeito
  • por KLOC por módulo e ou subsistema (identifique partes problemáticas do seu sistema)
  • você pode calcular quanto por membro da equipe, mas acho que deve guardar isso por si mesmo
  • resolvido vs encontrado
  • tempo necessário para resolver um bug (talvez se isso for inclinado, faça um gráfico disso)
  • talvez faça uma estimativa de quanto tempo é necessário se isso continuar na taxa atual
• Planejamento
  • Extrapolar o tempo usado para os recursos criados. Leve em consideração a complexidade do recurso. Isso não precisa ser muito preciso. O que você deseja transmitir com isso seria ao longo das linhas "Os recursos A, B e C têm a mesma complexidade de D, E e F. Com os recursos ABC usados ​​170% se o tempo planejado. Se nada mudar, esperamos o mesmo é necessário tempo para a DEF "ou na linha de" O recurso médio está demorando X% mais tempo que o calculado. Não temos motivos para supor que o restante da funcionalidade seja mais fácil de construir, portanto, devemos compensar isso no planejamento futuro Não adianta ter um planejamento se não for realista.
  • Tente ter um cronograma de lançamento mensal ou, de preferência ainda mais curto. Se apenas interno. Isso pode ajudá-lo a extrapolar o tempo necessário para o projeto. Isso também pode evitar que você faça compromissos irrealistas (se você não se comprometer com um novo trabalho antes que uma liberação seja concluída). Faça um planejamento para cada cilindro e verifique se os novos recursos entram no próximo ciclo (ou seja, nunca podem ser adicionados ao ciclo atual).
• Cobertura de teste: explique os valores "normais" da cobertura de teste e mostre como é sua cobertura atual
• Documentação: Quanto% está realmente documentado? Que bom?
• Modularidade:
  • Classe (acoplamento e coesão)
  • Baseado em pacote
  • Baseado no subsistema (quantos caminhos de comunicação existem?)

Você deve trabalhar e fazer o que faria em qualquer projeto, seja ele bem-sucedido ou não. Você está sendo pago para realizar seu trabalho. Faça isso da melhor maneira possível. Supondo que você não seja o gerente / líder do projeto, não é sua responsabilidade decidir se um programa deve ser cancelado ou não. Você decidir relaxar é o mesmo que tomar a decisão de cancelar o projeto. Isso não faz parte da descrição do seu trabalho.

No entanto, no quadro geral, isso não significa que você deva trabalhar 50, 60 ou mais horas por semana para tentar cumprir o cronograma. Mais uma vez, é tarefa da gerência descobrir como alcançar os objetivos do projeto. Mais de 50 horas semanais de trabalho não são uma opção razoável, a menos que estejam dispostas a pagar horas extras e você esteja disposto a adiar sua vida familiar. Mais uma vez, era tarefa da gerência elaborar um cronograma viável. Eles não podem assumir que podem forçar os funcionários a ignorar sua vida familiar, a fim de cumprir horários irrealistas.

Além disso, enquanto o cronograma pode indicar 1 1/2 meses restantes. Provavelmente essa não é a data de "desistir". Alguns clientes podem levar o que você tem até essa data, mesmo que não seja tudo. Alguns clientes podem obter financiamento extra, pois já investiram muito dinheiro no projeto. Às vezes, a própria empresa pode assumir custos extras para garantir um cliente satisfeito. Tudo isso está fora de seu controle. Faça o seu trabalho da melhor maneira possível. Isso dará opções de gerenciamento para que possam transformar um projeto de desastre em uma grande história de sucesso. Eu já vi isso acontecer muitas vezes.

Só posso reiterar o que os outros disseram, mas enfatizo enfaticamente: sempre se esforce pelo seu melhor trabalho e mantenha um rastro de papel. por CYA e razões técnicas.

Qualquer briga que surja no seu caminho depende do caráter pessoal da gerência; mas deixe-me dizer-lhe que é um inferno receber uma administração incompetente e mentirosa. Mas o pior que você deixará com o seu respeito (e seus colegas) intacto.

Faça boas anotações dos aspectos técnicos da sua Marcha da Morte. Quando você recebe a inevitável pergunta da entrevista , está em um projeto que falhou; por que falhou e o que você fez para tentar evitá-lo? O gerenciamento do bonehead não é uma resposta - mesmo que seja o motivo.

Pode ser uma maneira fácil de assumir que é um fracasso inevitável e absoluto e simplesmente desistir do projeto. Como consultor, sou frequentemente convidado a ajudar nos projetos que estão em vários estágios de degeneração, com ou sem sucesso, e parte do que estou sendo pago é reviver e concluir esses projetos.

O que você vê como um fracasso completo pode não ser percebido como tal por todos, dependendo da perspectiva. Em um mundo ideal, todos os recursos seriam completos, codificados de forma elegante e independente de outros sistemas e todas as linhas de código testadas. Não vi um único projeto que se parecesse com isso na rev 1. No mundo real, enviar um projeto significa assumir alguns compromissos, talvez até perdendo alguns dos principais recursos, mas o produto pode ser enviado e, embora seja, na melhor das hipóteses, qualidade beta , pelo menos, você receberá o feedback sobre quais coisas corrigir primeiro. A vantagem disso é que ele pode informar ao gerenciamento que o software nunca é feito e, em vez de tentar desenvolver uma certa v 1.0 no vácuo, é melhor iterar e responder às mudanças de maneira ágil. Finalmente, para você como desenvolvedor nesta posição, Eu acho que o mais importante é desenvolver o código o melhor possível nessas condições - documente, escreva você mesmo, se necessário (especialmente para dependências externas) e use seu conhecimento do sistema para comunicar quais recursos são realmente cruciais e devem ser -ter e quais podem esperar uma semana ou um mês. Expresse suas preocupações e justifique-as como fez conosco. Em vez de se preparar para o plano B, prepare-se para o fato de que você e outras almas pobres provavelmente estarão corrigindo todo esse código de bugs e ainda não pronto DEPOIS do envio do produto - como mencionado acima, isso significa escrever seu código de forma modular desacoplada - se você acha que o código da camada de persistência está incorreto, esperamos poder substituí-lo completamente na próxima revisão. Por fim, não se desespere - lidar com essa situação faz parte do que você está sendo pago e é um processo de aprendizado. Independentemente do resultado desse projeto em particular, isso contará como uma experiência valiosa no futuro.