7 fatores para falha garantida

Não aprecie os funcionários, subestime a complexidade ou confie em mitos. Se esses e outros fatores forem levados em consideração, seu projeto certamente falhará.

Você conhece isso? Durante semanas e meses, o gerente de projeto relata seu projeto. Obviamente, as clássicas lâmpadas de status não devem faltar. E isso está constantemente no verde: tudo ok. Mas um dia o semáforo muda repentinamente para vermelho! Consequentemente, inicia-se um processo de processamento bastante desagradável para os responsáveis. Na maioria das vezes a primeira pergunta se aplica ao culpado, a segunda às causas, e depois se dedica apenas às possíveis soluções.

Abaixo estão 7 fatores típicos que quase garantem o fracasso.

Fator 1: desconsidere o fator humano

Em muitos anos como desenvolvedor, gerente de projeto, treinador e gerente de crise, descobri que as tensões interpessoais são o maior obstáculo para a implementação de projetos de TI. Por outro lado, a química entre os funcionários é correta e existe um clima aberto e tolerante a falhas, soluções podem ser encontradas para todas as dificuldades – mesmo em situações críticas.

É da natureza do homem evitar conflitos. E, portanto, é natural que as pessoas (por exemplo, o gerente de projeto) ignorem completamente ou desviem o olhar por muito tempo. Mas os conflitos geralmente não se resolvem sozinhos. A pesquisa é necessária, como moderação e pelo menos a perspectiva de mudança ou solução.

Às vezes, são as pequenas coisas que têm um grande impacto, como um novo emprego para um funcionário. Porém, muitas vezes são necessários gastos maiores, como a reorganização das equipes, para trazer novamente a tranquilidade ao projeto. Porém, a pior alternativa é desconsiderar o fator humano.

Fator 2: Pense muito grande ou faça muito pequeno

Algumas empresas assumem um projeto. Subestimam a complexidade, os riscos e o imenso esforço pessoal e material. A minha organização – independentemente dos custos – é capaz de gerir um projeto com 100 funcionários? Temos empregos suficientes, salas de reunião, capacidade de rede, servidor de desenvolvimento, etc.?

A empresa é capaz de atender aos requisitos de uma grande equipe de desenvolvimento ágil para uma trilha de desenvolvimento e teste incluindo Integração/Entrega Contínua? Previsto tais questões, o caso de negócios deveria ter sido calculado de forma realista. Já vi várias vezes que só ficou claro pouco antes do início de um projeto gigantesco que o sistema resultante realmente não era necessário porque não se encaixava no modelo de negócios da empresa. Infelizmente, ninguém havia notado isso antes.

Outro padrão reconhecível: um protagonista deseja absolutamente realizar um SW, por exemplo, por motivos de prestígio ou para utilizar funcionários, e calcula os custos como insignificantes. Se o gerente de projeto posterior não for forte o suficiente para apresentar a discrepância no contexto dos órgãos de tomada de decisão, isso cria um alto potencial de crise.

Fator 3: confie 100% nas estimativas e no planejamento

Um mito generalizado é a confiabilidade das estimativas e do planejamento. O conceito do projeto é definido por sua singularidade. Talvez já existissem projetos semelhantes, mas, em princípio, uma empresa está entrando em um novo território a cada projeto. Isso significa que as estimativas só podem ser tão boas quanto as experiências dos criadores e suas habilidades de adaptação em relação ao projeto atual.

No entanto, os planos nunca podem incluir eventos espontâneos, mudanças em termos de requisitos, tecnologias ou a entrada de riscos não esperados. Em última análise, as estimativas e os planos a partir delas nada mais são do que uma aposta no futuro! Aceitar esse fato é um primeiro passo adiante. Disciplina, coragem e sistema ajudam a prevenir ou aliviar possíveis crises.

Fator 4: O triângulo PM mágico consistentemente desconsiderado

Estudou ciência da computação, primeiro semestre, primeira palestra gerenciamento de projetos: “O triângulo mágico do PM“ . A pessoa interessada em tarefas de gestão é introduzida nas leis deste triângulo desde muito cedo. Eles dizem que a mudança em um dos três parâmetros leva inevitavelmente às consequências de pelo menos um dos outros parâmetros.

No entanto, essas leis são muito felizes em ignorar na prática. Conforme já mencionado no contexto de estimativa e planejamento, um projeto é único e a probabilidade de influências não planejadas é excepcionalmente alta. É por isso que mais cedo ou mais tarde é necessário para quase todos os projetos que os responsáveis ​​reajam a essas influências. Porém, se todos os parâmetros estiverem fixos, ou seja, o cliente continuar exigindo cumprimento de prazo, orçamento e conteúdo, a falha é apenas uma questão de tempo.

Fator 5: Documentação de tudo

Livre depois de Franz Beckenbauer: “Nós o chamamos de clássico!” Apesar de cada vez mais empresas confiarem em procedimentos ágeis (principalmente scrum), ainda se encontram organizações e projetos que dão maior importância à extensa documentação do que ao software a ser criado. Este é um risco alto, especialmente em grandes projetos. Muitas vezes, uma busca de consultores e especialistas de departamento em milhares de páginas muitas vezes funcionou por meses ou até anos, que posteriormente serão traduzidas por outra equipe em SW.

Quanto mais extensa a documentação, maior o tempo de realização e menos provável que o SW corresponda aos requisitos reais dos usuários. As reações às mudanças do mercado não são possíveis ou só são possíveis com muito esforço e concessões temporais. Um documento oferece uma base contra a qual o produto pode ser removido. Infelizmente, o que está escrito não é necessariamente claro e o resultado é pensado de forma diferente do que originalmente pensado. Quantas vezes já ouvi a frase de funcionários de departamentos e usuários finais: “Ah, imaginei bem diferente!” .

Fator 6: Simplesmente nenhuma organização de projeto equilibrada

Uma equipe de 20 desenvolvedores e 1 contato técnico? Não há necessidade de conhecimento especializado para reconhecer que essa construção falhará mais cedo ou mais tarde. No início de um projeto, seja em cascata ou ágil, ainda pode funcionar porque os desenvolvedores estão ocupados com os frameworks ou configurando os ambientes. Mas muito em breve os funcionários farão perguntas – precisam de suporte profissional intensivo.

Um especialista em um único assunto nunca pode suportar essa pressão temporal e emocional e requer suporte, tanto em termos de pessoal quanto durante o processo de implementação. No entanto, é uma péssima ideia combater o gargalo de pessoal com a restrição da comunicação.

Também uma ideia popular e muito frontal na escala dos erros típicos de gerenciamento: um funcionário coleta as perguntas dos desenvolvedores, as discute com a pessoa de contato técnico e devolve as respostas. Dessa forma, você cria um gargalo por excelência, aciona uma taxa de erro extremamente alta e atrasa significativamente o desenvolvimento.

Fator 7: Esquente o sapo lentamente

Você conhece essa história? Se você colocar um sapo em uma panela com água e esquentá-lo continuamente para cozinhar, o sapo não tentará escapar. Se você jogá-lo diretamente na água quente, ele pula imediatamente.

Um dos meus conhecimentos mais importantes sobre mim nos últimos anos é que os funcionários de projetos de TI expiram com duração crescente de cegueira crescente. Processos outrora estabelecidos talvez sejam questionados em retrospectivas, mas raramente sendo realmente drásticos. A capacidade das pessoas de reagir às mudanças desaparece de forma proporcional à duração de um projeto.

Portanto, a iluminação esporádica (Health Checks) é recomendada por (enormes) projetos de um consultor externo, previamente não envolvido, a fim de descobrir o vazamento, caminhos potencialmente não direcionados. O mais tardar depois de reconhecer uma crise total, é quase impossível criar uma reviravolta apenas com a equipe existente.

Então pode ser possível

Os erros típicos de gerenciamento descritos são apenas uma pequena seleção de minha lista pessoal de padrões de comportamento, que impedem ou mesmo impedem a conclusão bem-sucedida de projetos de desenvolvimento de SW. À distância, pode-se ter a impressão de que é fácil reconhecer os problemas e corrigi-los nas fases iniciais dos projetos. Mas as condições estruturais supostamente inamovíveis e a cegueira mencionada muitas vezes dificultam a tomada de decisões corretas. As estatísticas do Standish Group ditas no início demonstram isso ano após ano.

Se um projeto está com problemas, é altamente recomendável que um gestor de crise externo possa analisar e agir com objetividade, livre de suscetibilidades e sem o lastro do histórico do projeto. A única participação de um especialista que ouve as pessoas no projeto já pode causar efeitos positivos. A seleção de medidas adequadas também consegue a transformação e, finalmente, a reviravolta.