Por que projetos com falha são bons?

Temos medo do fracasso, pois no caso de um projeto, isso significa perda de tempo, dinheiro e reputação. Mas as experiências ruins podem ajudá-lo a aprender com os erros e tornar mais eficazes os seus próximos passos. A diretora executiva da Factory5, Reseda Nesynova, contou como projetos malsucedidos ajudam a empresa a se desenvolver e se tornar melhor para si mesma e para seus clientes.

Disclaimer: Hoje falaremos exclusivamente sobre projetos malsucedidos, portanto, não citaremos nomes, senhas e presenças.



Todos os casos de falha da experiência minha e do meu amigo podem ser divididos em três tipos de acordo com as fontes de problemas:



1. Trabalhar com as partes interessadas



O motivo de muitos dos problemas do projeto é que não ouvimos ou ouvimos o cliente. Isso é especialmente crítico no início, quando existe o risco de perder a resposta à pergunta "Por que o projeto foi iniciado?"



Caso 1



Fomos confrontados com uma tarefa simples - bloquear todas as transações financeiras possíveis sob contratos que não são acordados dentro da empresa. Calculamos os efeitos e trabalhamos, ao que parecia, todos os riscos. Porém, durante a discussão, o usuário principal argumentou que isso não daria certo: “Teremos um processo de produção”. Parecia uma desculpa, e o principal cliente confirmou nossa hipótese e insistiu em apenas fazê-lo.



No dia X, de acordo com os planos, lançamos a funcionalidade e cerca de uma hora e meia depois, nosso principal cliente, mal-humorado, ligou e pediu para reverter tudo: “Não funciona!”.



Como foi necessário?Ouça as preocupações do usuário que conhece as especificidades do trabalho da organização por dentro e calcule esses riscos. Sempre existe a oportunidade de encontrar opções adequadas a todos.



Caso 2



Foi um cliente funcional que compreendeu perfeitamente a tarefa e o sistema que concebemos. Mas não levamos em consideração o interesse do departamento de TI na implementação deste projeto e chegamos a eles um pouco tarde: em fase de desenvolvimento da arquitetura. Tive que revisar o projeto e adiar o prazo para sua entrega. Perdemos tempo, dinheiro e reputação superestimando a influência e as capacidades do cliente funcional e subestimando os relacionamentos internos entre as divisões em uma grande empresa.



Como foi necessário? Envolver todas as partes interessadas no trabalho do projeto desde o início e ter em consideração os seus interesses, apesar das garantias do cliente.



Caso 3



E este foi um caso que quase não teve sucesso. O cliente funcional, representado pelo CEO, queria mudar a metodologia de contabilidade de custos e, de acordo com todos os cálculos, o efeito das mudanças deveria ter sido significativo. A equipe do bloco financeiro estava pronta para mudanças e no momento em que a tarefa chegou aos analistas de TI, a decisão já havia sido tomada. E aqui fizemos a coisa certa e perguntamos: Por quê? Como vai funcionar? Quem apoiará o processo? Como você considerou o efeito?



Com isso, o efeito foi recalculado levando-se em consideração as mudanças no sistema ERP e os custos de manutenção do processo e da ferramenta. Não apenas o efeito “desapareceu” no dinheiro, mas riscos adicionais também foram descobertos. O projeto foi encerrado e, para os funcionários da área de automação interna, passou a ser regra fazer perguntas no início, mesmo que a tarefa fosse do CEO.



conclusões



  • Sempre procure uma razão, propósito, efeito. Argumente sua posição. Como diz um amigo meu (gerente da turma): “Escuta, não vende ... Depois escute de novo ... e só depois venda”;)
  • Viva um dia com os usuários diretos do produto e conheça detalhadamente sua rotina. Isso ajudará a antecipar todas as nuances possíveis.
  • Analise todos os riscos que pareçam significativos para você, o cliente funcional e qualquer pessoa interessada. Preste atenção especial aos clientes / usuários mais negativos em relação ao projeto. Eles claramente sabem algo! ;)
  • Não perca um único participante do processo. Não pode haver um único participante no processo, e o departamento de TI deve ser sempre levado em consideração!




2. Descrição dos requisitos



O Santo dos Santos para qualquer analista é uma descrição dos requisitos. Vamos considerar os erros nesta área nos outros dois casos.



Caso 1



Uma das equipes de desenvolvimento recebeu um projeto que exigia revisão. O sistema veio com documentação, onde a descrição da lógica do sistema foi escrita usando consultas SQL. Quando o trabalho começou, o sistema já havia sido seriamente redesenhado e as consultas SQL não eram mais relevantes. Tive que gastar tempo fazendo engenharia reversa para entender a lógica e a funcionalidade do sistema.



Como foi necessário? Verifique novamente os documentos quanto à relevância e conformidade com o nível de desenvolvimento do projeto. Especialmente ao repassá-lo para outros desenvolvedores.



Caso 2



Foi um projeto interessante para automatizar todos os processos da organização. O projeto envolveu 5 sistemas de várias classes, que tiveram que ser integrados entre si para que o processo continuasse sem interrupção. A equipe estava desenhando a arquitetura da solução há cerca de dois meses, quando fui conectado ao projeto.



No processo de comunicação com o cliente, percebi que ele vê isso de uma forma e os desenvolvedores de outra. Esses foram os acordos mínimos em palavras que mudaram completamente o projeto. Tive que começar desde o início e trabalhar todos os requisitos do zero: Por quê? O que? Como?



Como foi necessário? Descreva claramente não apenas os requisitos para a implementação de processos e subprocessos (como funcionará), mas também como será o resultado final.



conclusões



Freqüentemente, as equipes têm medo dos comentários dos clientes e correm para se desenvolver quando ouvem "bem, mais ou menos assim". Podemos supor que você encontrou uma linguagem comum com o Cliente apenas se ele próprio começou a fazer ajustes com suas próprias mãos. Algumas pessoas acham conveniente ler textos, outras - esquemas e outras - layouts de interface. Vale a pena tentar de tudo até encontrar uma linguagem comum, mesmo que seja “desenhos em guardanapos”.



3. Desenvolvimento de uma ideia, produto ou solução



São histórias sobre gerenciamento de produto, quando a ideia inunda a mente e tudo o mais não importa.



Caso 1



Tínhamos um ótimo produto para automatizar tarefas rotineiras dentro da organização: desde a inserção de informações até o esclarecimento de dúvidas dos funcionários. E tudo foi ótimo: encontramos os primeiros clientes, entendemos o mercado - parecia que havia muito dinheiro - lançamos alguns projetos e os concluímos com sucesso. E naquele momento abrimos os olhos: ninguém calculou o custo de suportar a solução. E apagou todas as tentativas possíveis de fazer dinheiro a zero.



Como foi necessário? Calcule cuidadosamente todos os aspectos do projeto: do desenvolvimento ao suporte da solução.



Caso 2



Outra história é quando não calculamos o mercado. Foi encontrada uma ideia para um bom produto que não tinha concorrentes no mercado, mas tinha clientes. Pelo menos um, e ele estava disposto a pagar e investir. Entramos nesse projeto e nos deparamos com uma total falta de base teórica para o desenvolvimento dessa funcionalidade, mas conseguimos.



E depois de entrar no mercado com o produto, perceberam que não era à toa que não havia concorrentes. Muitas pessoas negligenciam esse recurso, apesar de todos os efeitos que ele garante.



Como foi necessário? Pense sobre por que não há concorrentes em um setor de mercado tão lucrativo e descubra a verdade.



Conclusões:



Verificar a viabilidade do projeto no quadro não de um cliente, mas da competitividade - de acordo com a situação atual do mercado.



Cultura de fracasso



Para superar as dificuldades e não ser pego por elas novamente, você precisa encontrar um motivo. Na maioria das vezes, está na cultura do fracasso que é adotada nas organizações. Existem duas maneiras ruins de responder ao fracasso nas organizações:



  1. Condenação / Punição

    Condenando os erros, matamos a iniciativa. Os funcionários têm medo de ser criativos e apenas tomar decisões seguras. Isso leva à estagnação da empresa.

    Solução: defina limites para erros. É necessário alocar um recurso para a manifestação das iniciativas e verificá-las nos postos de controle. Bem, acompanhe o sucesso do projeto de acordo com critérios estritos acordados previamente.
  2. Silêncio

    Essa tática leva a repetir os mesmos erros indefinidamente. E isso, por sua vez, leva à perda de posição da empresa aos olhos dos clientes, dos concorrentes e do mercado.

    Solução: construir um sistema de troca de experiências entre os funcionários. A discussão das possíveis soluções para as falhas leva, em última análise, a uma metodologia que ajuda a evitar esses erros.


A reflexão razoável ajuda a desenvolver, mas isso não é motivo para se cercar apenas de falhas. Procure equilíbrio, porque aprender com projetos de sucesso é muito mais agradável



All Articles