Gerenciamento de projetos, categoria 30+

Pare, pare, limpe imediatamente! Para fechar um projeto com falha, você precisa de duas coisas: precisa entender que o projeto falhou e precisa fechá-lo. Mas não é tão simples.



Este artigo é baseado em um relatório de Maria Belkina, da SEMrush, da OKR-mitap em São Petersburgo : “A experiência de mudar da OKR para o Spotify Rhythm”. Embora o título do relatório implique uma demonstração das deficiências da OKR, das vantagens do Rhythm e da maneira de substituir uma pela outra, seu principal tópico foi a pergunta: “O que fazer com projetos com falha?”. Este é um tópico agudo e doloroso que é interessante de entender.

A cultura de inicialização está comprometida com o sucesso. Se você pode alcançar a meta, precisa continuar no mesmo espírito. Mas nem todos os projetos são bem-sucedidos; na maioria dos casos, apenas resultados medíocres podem ser alcançados, ou pior. O que acontece com esses projetos? - Eles continuam. Para todos: tanto para a gerência quanto para os artistas, é muito mais fácil continuar investindo em um projeto malsucedido do que reconhecer seu fracasso. A escalada do problema pode levar a conflitos na equipe, por isso pode arruinar o relacionamento com os colegas. Ninguém precisa disso. Mas se você não fizer nada, o desenvolvimento será envolvido em projetos pouco promissores e o produto se transformará em um hash não suportado de recursos inúteis. Isso também não é bom.

O dinheiro é sempre importante, mas as pessoas são um recurso essencial de desenvolvimento. Durante um mês de trabalho, um grupo de cem pessoas queimará uma quantidade igual de dinheiro, independentemente do resultado. Obviamente, organizar o melhor resultado é a principal coisa no gerenciamento de desenvolvimento. Mas quando uma nova idéia aparece, "é isso que precisamos fazer!", Muitas vezes acontece que não há ninguém para enfrentá-la. Todos os desenvolvedores estão ocupados com as tarefas atuais, e não as mais importantes, mas você não pode deixá-las. Isso é típico de um produto maduro.

Quanto mais antigo o produto de software, maior a proporção de recursos gastos em seu suporte e mais lento o novo desenvolvimento. Mesmo que os recursos sejam usados ​​por duzentos usuários em cem mil, o bug ainda precisará ser corrigido. A introdução de novas tecnologias exigirá a correção de todo o código, independentemente de o método ser chamado a cada milissegundo ou uma vez por mês. É melhor concluir um projeto iniciado do que deixar inacabado. Quaisquer alterações globais exigirão testes completos e assim por diante. Tudo isso é um pouco preocupante e faz você pensar criticamente sobre as perspectivas.

Nem todos os projetos serão bem-sucedidos, isso é realidade. Você pode conviver com isso, mas, em algum momento, a gerência deve entender que não é possível continuar espalhando brinquedos pelo chão. Periodicamente, eles precisam ser coletados de volta na caixa, caso contrário, haverá uma bagunça. Sim, arrumar é chato. Sim, isso leva tempo. Sim, alguém pode estar chateado porque seu brinquedo favorito foi colocado de volta na caixa. Mas nós somos adultos.

O que significa fechar um projeto com falha? Não se trata apenas de amortizar dez homens-ano de trabalho com prejuízo. Toda funcionalidade desenvolvida também precisa ser removida do produto, e isso é trabalho adicional e custos adicionais. Também haverá usuários insatisfeitos que, por algum motivo, gostaram da funcionalidade do projeto. Não se esqueça das oportunidades perdidas. Parece que o tempo e o esforço despendidos para fechar o projeto podem ser usados ​​com maior benefício. Feche o projeto - caro. Para dar esse passo, você precisa de vontade, determinação e entendimento de que a saúde do produto a longo prazo é mais importante que a economia tática. Mas, mesmo que exista uma disposição para implementar medidas drásticas, o gatilho ainda é necessário, é necessário um meio de entender que o projeto falhou.

Critério de falha do projeto. Normalmente, é habitual definir um critério de sucesso. Parece que, se os critérios de sucesso foram definidos e o projeto não os alcançou, falhou. Absolutamente não. Entre o sucesso e o fracasso, existe uma grande área cinzenta. Não atingindo os valores dos indicadores que determinam o sucesso, sempre há a sensação de que "apenas não fizemos o suficiente", "apenas um pouco mais e tudo vai dar certo". Talvez seja assim. Porém, avaliar um projeto de acordo com critérios de sucesso coloca apenas a pergunta "continuar ou não?", E essa pergunta não implica uma resposta "feche e destrua!".

O critério para a falha do projeto é o limite inferior dos indicadores, abaixo do qual o projeto deve ser destruído. Como um navio que tem um buraco abaixo da linha d'água, ele deve afundar. Com todo o orgulho, grandeza e profissionalismo possíveis.

Assim como o sucesso não deve levar à inveja, o fracasso não deve incitar o ódio em uma equipe. A longo prazo, tudo isso é uma rotina do processo de trabalho. Para que o fracasso do projeto não leve a conflitos, os critérios para o fracasso devem ser determinados e previamente acordados, bem como os critérios para o sucesso. Além disso, um plano de encerramento do projeto precisa ser preparado com antecedência, ainda mais cedo que o próprio plano do projeto. Então, tendo determinado que o projeto falhou, não haverá dúvida sobre o que fazer nessa situação. Você pode avançar imediatamente para uma ação decisiva. Tudo de uma maneira adulta.

É razoável argumentar que nosso cérebro está tão organizado que, pensando antecipadamente no fracasso, nos preparamos para o fracasso. Talvez. Mas a capacidade de pensar nas consequências é um sinal de pensamento maduro. E as dificuldades associadas a isso, ao que parece, podem ser superadas.

---

Dmitry Mamonov,
Wrike

PS Na continuação do tópico sobre como, por que e quando remover recursos do produto, posso recomendar um relatório do meu colega, Yuri Andreikovich.