Qual é a maneira mais produtiva de lidar com falhas relacionadas ao desenvolvimento? [fechadas]

Todos nós já estivemos lá:

• Seu projeto falhou ou foi cancelado.
• O código em que você passou dias trabalhando foi rejeitado por sua equipe.
• O padrão de design que você introduziu na equipe criou o caos.
• Todo mundo ignora suas idéias.

Minha pergunta é: qual é a maneira mais produtiva para um programador lidar com falhas relacionadas ao desenvolvimento como essas?

Seu projeto falhou.

O desenvolvimento de software é altamente propenso a falhas de projeto e, dependendo da gravidade, isso é melhor tratado pelo gerenciamento.

Muitos projetos falharam e muitos outros falharão, então faça anotações! Saiba por que seu projeto falhou para não cometer os mesmos erros da próxima vez. Você aprende muito mais com suas falhas do que com seus sucessos.

O que você passou dias codificando foi rejeitado por sua equipe.

Salve seu trabalho (para mais tarde). Há duas possibilidades: (a) É péssimo, e o fato de várias pessoas responderem da mesma maneira é uma indicação disso. (B) É realmente um trabalho genial, mas muito à frente do que as pessoas estão acostumadas ou podem entender. As pessoas geralmente não gostam do que não entendem. Talvez seja melhor mostrar quando é a hora certa OU em um lugar diferente com uma "Cultura" diferente

Ninguém ouve suas idéias em sua empresa.

Provavelmente é uma má ideia, OU a cultura não está alinhada com o seu pensamento. Ou mude para um lugar que apóie sua cultura ou avalie criticamente sua ideia novamente (objetivamente sem seu próprio viés) -> a minha ideia é realmente boa? <- Mate seu ego

O padrão de design que você introduziu com força em sua equipe criou uma bagunça.

Seja honesto, você tentou o seu melhor, mas não deu certo como planejou. Pode ser melhor começar de novo ou aprender com os erros cometidos no design como equipe e seguir em frente.

Eles não são falhas - são experiências

Você aprende e cresce com suas experiências, refletindo sobre como elas fizeram você se sentir e se você deseja mais desse sentimento.

Se for uma experiência ruim (como a lista que você ofereceu), o sentimento ruim que a acompanha é provavelmente algo que você deseja evitar (supondo que você não seja tão grossa que não se importe com o impacto de suas ações).

No geral, não se envolva muito em se comparar com os outros, pois eles estão tendo tantos problemas em trabalhar com tudo quanto você .

• Fique calmo - não entre em pânico, isso não vai melhorar nada
• Controle de danos - salve o que ainda pode ser salvo
• Aprenda com seus erros - fazer a coisa errada novamente provavelmente não fará com que ela funcione
• Considere um novo começo - comece sua próxima tentativa sem uma mochila de decepções e sentimentos de culpa
• Observe falhas maiores - em comparação com o primeiro voo do Ariane 5 , sua falha é insignificante
• Consulte um psicoterapeuta se você não puder lidar sozinho

Você constrói algo.

Para mim (acho que não é certo para todos), construir algo (quadrinhos, desenhos, joguinhos, qualquer coisa) é como construir um pouco de confiança para voltar ao combate ao fracasso. Também pode ser uma boa maneira de expressar sua raiva ou amargura ou qualquer sentimento relativo ao fracasso, mas de maneira "construtiva".

Isso funciona para mim de qualquer maneira.

Bem, você perguntou :) Um por um:

* Your project failed.

Isso não é novidade. Todos falhámos em particular e todos falhámos à vista dos nossos pares. Qualquer pessoa que tenha passado pelo ensino fundamental e médio já passou por isso.

Se não posso cometer erros e esperar um emprego estável, considere enviar um memorando ao RH, informando que os seres humanos serão banidos de consideração futura.

Várias falhas consecutivas significam que você tem exigências e especificações irracionais ou não aprende com seus erros. Qualquer cenário implora ação imediata.

É concebível que muitas pessoas se inscrevam em algo apenas para obter emprego e, então, desenvolvam alguma maneira de fazer com que os requisitos aconteçam.

* What you have spent days coding was rejected by your team.

Isso acontece. Como outros observaram, salve-o. Faça isso novamente. É por isso que chamamos isso de trabalho. Acho que, nesse caso, você provavelmente não envolveu muito a equipe no que estava fazendo.

Também pode ser que os requisitos tenham mudado ontem ou uma hora atrás. Isso deve ser uma exceção, não uma norma, no entanto. A revisão por pares é tão brutal quanto útil. Se seu código é constantemente descartado como 'inadequado' (ou algo assim), você deve gastar mais tempo escolhendo cérebros e envolvendo outras pessoas. Acredito que essa pergunta seja uma falácia na maioria das configurações de equipe, a menos que a 'equipe' seja qualquer coisa menos descritiva.

* Nobody listens to your ideas in your company.

Novamente, isso precisa de contexto. Quanto tempo voce esteve lá? Quanto seus colegas hackers confiam em sua capacidade? Você já pensou que as idéias que resultam em mais trabalho para muitas pessoas podem convidar QUALQUER motivo para descartá-lo? Certa vez, algo foi descartado porque não estava pronto para IPV6, mas usava um soquete de domínio simples no dispositivo de loopback (exclusivamente). A pessoa que afundou simplesmente não aguentou mais trabalho.

Além disso, como você se articula? Você pode fazer amigos e influenciar pessoas?

* The design pattern you introduced with force in your team created a mess.

Por isso, a força deveria ter sido evitada. Ser capaz de falar não é um pré-requisito para ser capaz de ouvir. Nenhum outro comentário.

Oh garoto, é muito se você realmente quis dizer que tudo aconteceu com você!

AVISO : Em muitos dos pontos abaixo, você pode sentir que eu o critico e que quero torná-lo responsável pelos erros e não considerar fatores externos. Eu não. Só que você não fornece muitos detalhes, e apenas forneço listas de verificação de ações a serem tomadas para garantir que as coisas não corram mal. Sei que cometi muitos erros (todo mundo comete) e só melhoramos se aprendermos com eles. E para aprender com eles, precisamos começar a vê-los como erros em primeiro lugar, e aceitar a responsabilidade pelo que deu errado de nossa parte. Inferno, aceite a responsabilidade pelo que deu errado nas partes de outras pessoas, você pode aprender com isso também.

Seu projeto falhou

Não há muito que você possa fazer para mitigá-lo agora.

No entanto, você pode fazer muito para evitar que seja reproduzido no futuro. Sugiro tentar melhorar suas habilidades de gerenciamento de projetos e tempo.

Um dos livros com a melhor proporção ((conselhos válidos) / páginas) que li sobre o assunto, embora talvez não seja o melhor, é o Radical Project Management de Rob Thomsett .

Você realmente não especifica o que seu projeto falhou, mas eu presumiria uma combinação de coisas que trouxeram desequilíbrio no triângulo habitual de custo / tempo / qualidade . O fator mais importante aos meus olhos é liderar o projeto e o desenvolvimento e estar sempre em contato com seus atores técnicos (desenvolvedores e testadores), mas também com seus stakeholders. Muitos projetos falham porque não ouvem patrocinadores ou partes interessadas e não os pressionam a se envolver no processo.

Se eles não estiverem envolvidos, você não poderá saber o que eles querem. Se você não pode saber o que eles querem, você não pode entregá-lo. Se você não entregá-lo, eles serão infelizes. Isso é um fracasso. Além disso, se você não envolver seus stakeholders, eles serão desconectados da realidade da engenharia de software, o que significa que eles não entenderão seus problemas. Se eles frequentemente estão em contato com você, eles conseguem entender melhor o que você precisa lidar. Eles serão mais capazes de entender quando você lhes disser que um recurso "pequeno" [risos] levará meses. Eles podem confiar melhor no seu planejamento porque ajudaram a construí-lo. Um projeto não pode ter sucesso apenas com "especificações no início, desenvolvimento, teste, entrega no final". Isso nunca acontece. Você pode entregar o que foi solicitado nas especificações,

E o mais importante, faça uma retrospectiva e garanta que ela seja menos egoísta e não um jogo de culpa. Apenas identifique problemas.

O que você passou dias codificando foi rejeitado por sua equipe

Eu estive nessa situação. Novamente, você não pode fazer muito para mitigar isso, exceto:

• Mantenha-o no SCM para mais tarde.
• Talvez tente inserir pequenos pedaços progressivamente na principal base de códigos, em vez de uma grande refatoração.

Mas há outras coisas que você pode fazer para evitar esse tipo de situação:

• Por que isso aconteceu? Qual o motivo da rejeição?
• Na maioria das vezes, quando vejo isso acontecer (e esse também foi o meu caso), significa que o desenvolvedor ficou sozinho ou no modo de codificação cow-boy e produziu coisas que nunca foram solicitadas. O código que não vem dos requisitos de negócios pode ser sofisticado e "melhor", mas geralmente é um desperdício de tempo e dinheiro. Além disso, custará ainda mais se você integrá-lo, pois precisará testar novamente. Pense como as pessoas que negociam o dinheiro: você também precisa ser eficiente nesse nível.
• A qualidade do software produzido foi satisfatória? Cumpriu os padrões e convenções em atividade na sua empresa?
• Você se reportou periodicamente (e freqüentemente!) Aos diretores sobre isso? Você trocou ocasionalmente com outros desenvolvedores da equipe? Caso contrário, eles não sabem nada sobre isso, será um custo de tempo enorme para eles avaliarem e revisarem agora. NÃO conta ao mesmo tempo no final. É como sempre tentar adiar a limpeza do seu apartamento alugado e depois limpá-lo somente quando você sai: é um trabalho ruim, cansativo, mais difícil do que teria sido se fosse feito regularmente, e muitas vezes não é feito direito.
• Você produziu testes de produção? Testes de unidades? Testes de integração?
• Seu código foi verificado regularmente no SCM? Foi em um ramo diferente? Precisava de um ramo diferente ou poderia ter sido feito no porta-malas? Adiar o código de confirmação geralmente é um mau sinal. Obviamente, às vezes você é tentado a fazê-lo, mas apenas se atira no pé.

Ninguém ouve suas idéias em sua empresa

Bem, existem 2 opções aqui, e veremos as duas:

• Suas idéias eram ruins.
• Suas idéias eram boas.

Vamos começar a supor que eles eram ruins (mais uma vez, refletir sobre isso e aceitar sua ideia era simplesmente ruim, pode ser difícil, eu sei). O que você faz para mudar isso?

• Por que você teve a ideia? Qual é a lógica ? Existe uma necessidade real do que sua idéia tenta trazer para a mesa?
• Como você teve esta ideia? Você fez isso sozinho? Você compartilhou? Chuva de ideias? Plano? Protótipo? (faça isso na ordem certa. Se falhar no caminho, descarte a ideia, não continue. Ou, pelo menos, não no seu horário de trabalho.)

Ideias são apenas idéias. Se você apenas as sugere como idéias e elas são rejeitadas, não vejo por que você se sentiria mal por isso. Se, no entanto, você agir de acordo com eles sem notificar ninguém e ENTÃO apenas enviar suas idéias e elas forem rejeitadas, obviamente eu sinto a frustração perdida no momento. E seus gerentes fazem para!

Supondo que suas idéias fossem boas:

• Sua apresentação foi boa?
• A sua maneira de fazer a apresentação foi boa? (Sou desenvolvedor, sei do que estou falando: somos PITAs mal-humorados, arrogantes e pedantes , que estão sempre certos e com quem é difícil trabalhar por causa de nossos egos desproporcionais ).
• Você tem um plano para implementá-lo? Você pensou no custo e no tempo? Você pensou como isso beneficia usuários / clientes? Você pensou em como isso afeta as vendas? Você achou que o trabalho com essa ideia poderia impactar outros projetos e prioridades? Você vai me dizer: "por que devo fazer tudo isso, é o trabalho do meu gerente e das equipes de marketing ou vendas ?!" Exceto agora, você está tentando fazer parte de todos os trabalhos deles.

O padrão de design que você introduziu com força em sua equipe criou uma bagunça

• Por que você introduziu o padrão?
• Se ele criou uma bagunça, provavelmente:
  • não era o padrão certo,
  • não foi implementado corretamente,
  • não foi integrado corretamente.
• Como você o apresentou? Como exatamente você define o estado "bagunça"?
  • código menos legível?
  • menos sustentável?
  • compilações estão quebradas?
  • Existem diferentes tipos de "bagunça". Saber o que a bagunça é pode ajudar a saber o que o fracasso em que havia, e se era culpa do padrão de design.

Além disso, estou um pouco surpreso com a abordagem em si. Você realmente precisou pressionar para que um padrão de design fosse introduzido? Isso parece bastante estranho. Um padrão já está lá ou é necessário refatorar uma parte da sua solução de acordo com o padrão. Você não pressiona como adotaria uma estrutura ou tecnologia (como as pessoas pressionam muito para ter XML em todos os lugares, e agora como as pessoas começam a pressionar para poder escrever HTML5 na capa do produto em letras grandes e brilhantes).

Por que você teve que empurrar? Por que houve resistência? Talvez tenha sido justificado.

Você conseguiu fornecer exemplos de que esse padrão específico ajudaria a melhorar sua base de código de maneiras significativas (por exemplo, combinando-o com um exemplo de Refatoração para Padrões ).

Observação completamente fora do tópico, mas foi nisso que pensei pela primeira vez quando li o título da pergunta, pois considerava que ela se referia a falhas de software ... Eu tinha um software que implementou uma classe BlackHole para gerenciar um tipo muito especial de exceções em uma das componentes. Pode parecer (e realmente é) um hack obviamente estranho e sujo, mas o nome em si era tão excelente que todos nós apreciamos por uma maneira bastante legal de lidar com uma falha! :)

Passo 1: Não há problema em ficar com raiva!

Primeiro, é compreensível ficar chateado ou com raiva ao encontrar um fracasso. Se você estiver aconselhando alguém em tal situação, é provável que não queira ouvir "Apenas supere isso e siga em frente" ou "Apenas pense nisso como uma oportunidade de aprendizado".

Na verdade, acho que pode ser saudável e produtivo ficar chateado e desabafar suas frustrações, desde que você faça isso em particular ou com um amigo. As pessoas têm maneiras diferentes de fazer isso, mas acho que uma das maneiras mais produtivas é escrever uma carta falsa com raiva (Importante! Não envie essa carta para ninguém ). Explique seus sentimentos, como por que você acha que o que aconteceu foi injustificado.

Etapa 2: reserve um tempo para se acalmar.

Certifique-se de expressar tudo o que está sentindo, e depois de desabafar sua raiva, leve um tempo para se acalmar. Talvez você precise apenas de alguns minutos ou talvez de algumas horas.

Etapa 3: revise o que aconteceu na etapa 1

Neste ponto, esperamos que você consiga pensar mais objetivamente sobre a situação. Se você escreveu uma carta, leia-a para si mesmo. Se você confiou em alguém, tente se lembrar do que disse. Se você imaginou gritar com alguém, revise-o mentalmente.

Costumo escrever uma carta quando estou com raiva e, depois de me acalmar, trabalharei no aprimoramento da carta para comunicar mais claramente o que estava originalmente tentando dizer, até ficar satisfeito que alguém que a lê entenderia o que eu era. sentindo no momento.

O ponto é tentar objetivamente escolher quais eram seus pontos. Eles faziam sentido? Talvez eles precisem de esclarecimentos ou mais detalhes. Eles são infundados? Se você se colocasse objetivamente no lugar de outra pessoa, entenderia os argumentos que fez? Você concorda com esses pontos? Você pode usar esta oportunidade para se avaliar. O que você fez bem? Quais foram algumas das coisas que você poderia ter feito melhor?

Etapa 4: decida um curso de ação

Existe algo que pode ser feito para remediar a situação ou, pelo menos, melhorá-la? Reserve um momento para considerar se existe algo realístico que possa ser feito para corrigir ou melhorar a situação. Muitas vezes não há, mas às vezes existe.

Se você é culpado de alguma coisa, isso pode ser tão simples quanto um pedido formal de desculpas a alguém, explicando claramente o que deu errado, o que você fez, por que o fez e o que fará para corrigi-lo ou impedir que isso aconteça. o futuro.

Em seguida, considere o que você pode fazer para melhorar o futuro. O que você pode fazer para impedir que a mesma coisa aconteça novamente? Decida o que você deseja alcançar e use o que aprendeu na etapa 3 para criar um plano para si mesmo.

Se tudo mais falhar, tente reiniciar:

        try
        {
            // ...
        }
        catch (OhNoes111Exception)
        {
            // reboot fixes everything!
            System.Diagnostics.Process.Start("ShutDown", "/r");
        }