Para aqueles que não estão familiarizados com o desenvolvimento de software, pode parecer estranho que um projeto tenha um gerente de
produto e um gerente de
projeto . A diferença é que o primeiro é responsável por determinar o produto, e o segundo é responsável pelo status do projeto e informa as partes interessadas se a data de entrega estiver em risco.
Os gerentes de projeto tendem a se esforçar para garantir a previsibilidade dos prazos por meio de padronização e processos cíclicos. Esses processos se concentram nos relatórios de status para acompanhar o progresso. É geralmente aceito que, quanto mais de perto você monitorar os processos, mais previsível o cronograma do projeto se tornará e maior a probabilidade de o projeto ser entregue no prazo.
A maldição do gerente de projetos é a qualidade das estimativas para o tempo que elas recebem da equipe. Essas estimativas podem variar bastante. Eles geralmente variam de pessoa para pessoa, e atualizações diárias podem ser necessárias. Esse giro nas estimativas pode tornar impossível determinar o momento do projeto, mas é esperada uma data firme do gerente. Quando esses prazos são perdidos, o gerente deve encontrar uma maneira de explicar por que os prazos são perdidos, sem tornar os últimos funcionários diretamente responsáveis pelo prazo perdido. A diplomacia inadequada nessa área geralmente leva a equipe a acusar o gerente de projeto de "jogá-los sob o trem", independentemente da precisão de suas avaliações anteriores.
A seguir, são apresentadas personalidades problemáticas entre os gerentes de projeto:
Planejador de reuniões
O gerente do projeto, que acredita que todos os problemas do projeto são causados por falta de comunicação e coordenação, e um número abundante de reuniões será a solução.
- Pode mudar para estatística
- Perigoso em combinação com o gerente de produtos, como o autor da patente
- Probabilidade de correção: alta
- Perigo para o projeto: baixo
O problema
Em teoria, as pessoas se reúnem em reuniões para discutir opções e tomar decisões. De fato, isso raramente acontece. O planejador de reuniões não está ciente desse fenômeno e tenta agendar reuniões o mais rápido possível, com o maior número possível de pessoas. Ele acredita sinceramente que isso melhorará a colaboração na equipe: a idéia de que a comunicação não é suficiente para o sucesso do projeto se firmou firmemente em sua mente.
Esse tipo de gerente exacerba três problemas principais inerentes à grande maioria das reuniões:
- Por via de regra, a seleção dos participantes é mal realizada, e alguns ouvem informações de que não estão interessados e expressam uma opinião sobre questões que não lhes interessam.
- A organização das reuniões também costuma ser mal realizada, o que geralmente leva a debates caóticos que não são relevantes para o objetivo da reunião, o que, por sua vez, não leva a conclusões práticas.
- Os projetos são concluídos não nas reuniões, mas nos locais de trabalho. Se você leva os funcionários para as reuniões em vez do trabalho, eles gastam um tempo valioso.
Solução
Um planejador de reunião não representa uma ameaça séria para um projeto porque os funcionários geralmente não participam de reuniões que prejudicam sua produtividade. Portanto, o trabalho continua apesar das reuniões em andamento.
Este gerente de projeto pode ser corrigido com uma instrução simples:
- Classifique todos os tipos de reuniões que eles costumam realizar: relatórios de status, revisões de projetos, agendamento, etc.
- Determine quais resultados (se houver) dessas reuniões podem ser alcançados por outros meios, por exemplo, por email, ferramentas de rastreamento, conversas informais.
- Para reuniões obrigatórias, determine com que frequência elas devem ser realizadas e quem deve estar presente.
- Agende reuniões em blocos para evitar várias distrações devido à alternância de contexto.
- Deixe alguns dias da semana livres de reuniões.
- Isento de assembléia por algumas semanas como um todo (você será amado por isso).
- Programe cada reunião com pelo menos uma semana de antecedência com uma agenda publicada e qualquer material que precise ser considerado antes da reunião.
- No início da reunião, revise a agenda, os objetivos da reunião e ajude a alcançá-los.
- Encerre a reunião imediatamente: não continue se o objetivo original for alcançado.
São necessárias reuniões para concluir o projeto, mas o mais importante:
- Torne cada reunião o mais eficaz possível.
- Minimize o impacto negativo no desempenho.
Assim que o planejador da reunião entender isso, seu comportamento mudará imediatamente para melhor.
Estatístico
Um gerente de projeto que está envolvido apenas na criação de listas e na verificação de itens, independentemente do seu conteúdo.
O problema
A conclusão de qualquer projeto requer duas etapas essenciais:
- Faça uma lista de tarefas.
- Marque os itens da lista que são criados.
O gerente de projeto do tipo de estatística chegou à conclusão de que manter essa lista é a totalidade de suas responsabilidades no trabalho. Ele não está preocupado com o que está na lista. Somente pelo fato de ter pontos e serem verificados em um ritmo previsível. O estatístico não avalia e não oferece nenhuma abordagem crítica ao que são os itens da lista, mas confia em outros, informando o conteúdo do item e o prazo.
A maior preocupação para esse gerente é que o software de gerenciamento de projetos possa fazer seu trabalho. Assim, torna-se desnecessário. Muitas vezes, são fornecidas estatísticas para liderar projetos em um programa desse tipo, e ele mantém cuidadosamente as informações atualizadas. O projeto em si pode estar em ruínas, a equipe pode lançar um produto completamente errado com um atraso de vários meses e baixa qualidade, mas até agora tudo está devidamente documentado, o estatístico não vê problemas.
Felizmente, se um estatístico mantiver apenas listas e excluir itens, ele não fará mal ao projeto, se não levar em consideração sua ignorância do verdadeiro estado de coisas. O principal problema é que as estatísticas podem se transformar rapidamente em algo muito pior.
Solução
É difícil corrigir as estatísticas porque sua atenção aos detalhes está profundamente enraizada na natureza, possivelmente desde a infância. Se alguém considerar as listas importantes, ele não mudará repentinamente de mentalidade depois das suas palavras. Além disso, as listas são realmente importantes, mas são apenas um mapa, não uma paisagem. Esse paradoxo confuso das listas, que é importante, mas não primordial, torna as estatísticas especialmente difíceis de corrigir.
Uma habilidade essencial que falta às estatísticas é a capacidade de trabalhar com pessoas. O gerente interage com a lista e não com as pessoas. Convide-os a conversar com as pessoas que vivem sobre o que estão fazendo e por que, e não apenas solicitar uma lista de itens. No entanto, no caso de má execução, as estatísticas podem deslizar para o microgerenciamento (consulte gerente
inseguro ).
Por fim, peça para escrever um resumo de um parágrafo sobre o status do projeto e não mostrar o resultado como uma lista de itens. Isso os fará apresentar de forma mais holística o projeto.
Erro
O gerente está tão separado das realidades do projeto que fornece informações falsas às partes interessadas.
- Pode se transformar em otimista ou pessimista
- Perigoso quando combinado com um desenvolvedor otimista
- Probabilidade de correção: alta
- Perigo para o projeto: muito alto
O problema
A principal responsabilidade do gerente é relatar o status do projeto. Isso é chamado de “definir expectativas” e “atender às expectativas” é a medida pela qual o sucesso de um projeto é determinado. Um bom gerente de projetos define as expectativas com base em uma combinação de dados quantitativos e qualitativos, bem como em sua própria experiência profissional. Por outro lado, um gerente que erra é baseado apenas em seus instintos.
A seguir, frases-chave que permitem reconhecer o gerente de projetos nas nuvens:
- "Eu tenho um mau pressentimento."
- "Acho que não chegaremos a tempo a essa altura."
- "Acho que tudo ficará bem conosco."
- "Não vejo nenhum problema."
- "Esta decisão me confunde."
Preste atenção ao uso de "I" e "nós" - esses são bons indicadores de que a percepção do gerente se baseia em impressões subjetivas, e não nos dados coletados e analisados.
É importante observar a diferença entre um gerente equivocado, um
pessimista e um
otimista :
- Um pessimista , com base em sua interpretação de informações quantitativas e qualitativas, acredita que o projeto falhará.
- Um otimista , com base em sua interpretação de informações quantitativas e qualitativas, acredita que o projeto será bem-sucedido.
- O gerente errado apenas por seus próprios sentimentos forma uma opinião sobre o sucesso ou fracasso do projeto, o que é completamente falso.
Essa é uma das poucas personalidades que podem arruinar um projeto inteiro por conta própria. Se esse gerente costuma se reunir com as partes interessadas, a vigilância deve ser aumentada, pois pode acontecer o seguinte:
- O gerente diz às autoridades que tudo está perdido, o projeto nunca entrará em produção e, como resultado, o projeto será cancelado.
- O gerente diz que tudo está em ordem e tudo será pontual, como resultado das autoridades ficarão ainda mais decepcionadas se chegarem atrasadas, o que levará ao cancelamento do projeto.
Solução
Felizmente, esse gerente pode ser corrigido em duas ações:
- Pergunte a ele por que ele sente o que sente.
- Mostre a ele dados quantitativos e qualitativos contrários aos seus instintos.
Por que pedir para articular como ele se sente? Isso o ajudará a entender que o julgamento não se baseia em algo material, mas em uma avaliação subjetiva, ou seja, em sentimentos. É vital que ele chegue a essa conclusão por conta própria - não é preciso dizer que ele tem maus instintos. Continue perguntando "Por que você pensa assim?" Até chegar a um avanço.
Assim que o gerente conseguir, mostre a ele os fatos sólidos sobre o projeto. Por exemplo, se ele disser "Qualidade do produto não é boa", imagine um gráfico mostrando um declínio constante no número de bugs nos últimos meses. Se ele disser: "Estaremos prontos a tempo", forneça uma lista de tarefas incompletas e o tempo usual para a conclusão da tarefa, o que prova o contrário. Nesse estágio, deve ser simplesmente uma questão de prevalecer a mente e a lógica do gerente. Se ele permanecer na ilusão, repita o processo quantas vezes for necessário.
Pessimista
Um gerente que fala com confiança do fracasso do projeto e é impossível convencê-lo do contrário.
- Pode sofrer mutação no erro
- É perigoso em combinação com um testador, como um alarmista
- Probabilidade de correção: não
- Risco do projeto: extremamente alto
O problema
A maioria dos projetos de desenvolvimento de software pode ser considerada malsucedida de um lado:
- Orçamento em excesso.
- Excedendo os prazos.
- Falta de todas as funcionalidades necessárias.
- Problemas de desempenho, estabilidade ou escalabilidade.
- Um grande número de bugs.
No mundo real, isso pode ser esperado, e às vezes percebido como uma realidade inevitável. Mas o pessimista faz exigências tão altas que o projeto não pode ser atendido e
anuncia sua falha muito antes da falha real do projeto.
Um pessimista é facilmente identificado por duas características principais:
- Ele escolhe especificamente métricas negativas sobre o estado do projeto, a fim de se concentrar no negativo, ignorando ou desvalorizando quaisquer sinais positivos.
- Ele é apaixonado por suas performances, que geralmente são cheias de drama emocional.
Essa posição pode convencer as autoridades de que o projeto não tem esperança e é realmente cancelado.
Solução
O gerente pessimista não pode ser consertado, pois muitas vezes é infeliz em sua vida pessoal, insatisfeito com o trabalho, a carreira ou a própria empresa. Assim, seu negativo não tem nada a ver com o próprio projeto, mas representa um problema pessoal. A melhor coisa que você pode fazer é oferecer aconselhamento psicológico, o que poucas empresas fazem. Isso leva ao resultado muitas vezes inevitável: o gerente sai ou a empresa o despede.
Optimist
Um gerente de projeto que se convenceu do sucesso do projeto, independentemente de evidências em contrário.
- Pode se transformar em capitão da equipe ou errar
- Perigoso quando combinado com um desenvolvedor otimista
- Probabilidade de correção: Baixa
- Risco do projeto: extremamente alto
O problema
Como regra, as pessoas gostam de trabalhar com pessoas positivas. A desvantagem de um gerente otimista é que sua visão de mundo positiva
não deixa claro os sinais de alerta no projeto . Em vez de tomar medidas para resolver os problemas, ele prefere ignorar esses sinais, considerando-os negativos negativos e preferindo relatar apenas os bons. Isso cria uma cultura de complacência ou desânimo entre os membros da equipe, enquanto os chefes têm a ilusão de que tudo está indo bem.
Em qualquer posição de liderança, o otimismo diante da adversidade é uma vantagem importante. Para distinguir um gerente otimista de um líder ousado, use os seguintes testes:
- Ele se sente grato pelas más notícias?
- Quantas vezes ele faz elogios infundados?
- Ele está sempre de bom humor, por mais baixo que seja o moral da equipe?
- Ele evita o confronto, mesmo que seja justificado?
- Não parece que as pessoas gostam mais dele do que o sucesso do projeto?
Um gerente otimista geralmente causa falha no projeto, porque ignora problemas que podem levar à falha. Quanto mais tempo o projeto demorar, pior será o efeito.
Solução
Um otimista é facilmente confundido com um líder ousado, razão pela qual eles raramente são identificados e, portanto, raramente corrigidos. Quando o disfarce otimista aparece, muitas vezes é tarde demais, pois o projeto já falhou.
As organizações se esforçam para promover líderes corajosos. Como resultado, um gerente otimista tem uma maior chance de promoção se conseguir convencer seus superiores de que o projeto falhou por razões fora de seu controle.
Independentemente do motivo pelo qual o gerente se comporte dessa maneira - para o crescimento pessoal da carreira, não querendo enfrentar uma verdade desconfortável ou apenas ingenuidade -, o dano ao projeto é o mesmo. A única diferença é se ele está sendo promovido ou demitido.
Capitão da equipe
Um gerente de projeto que se concentra em fazer todos os programadores felizes e não no sucesso do projeto.
- Pode se transformar em otimista
- Perigoso quando combinado com um gerente de desenvolvimento de manutenção da paz
- Probabilidade de correção: alta
- Perigo para o projeto: baixo
O problema
O moral elevado é importante para qualquer projeto: os desenvolvedores geralmente são mais criativos e produtivos quando o moral é alto. Quando um projeto corre mal, naturalmente, o moral cai até que a situação melhore. Neste momento, em vez de resolver os problemas do projeto, o capitão da equipe está empenhado em melhorar o moral.
O capitão da equipe e o
otimista têm em comum uma atitude positiva, mas sua manifestação é fundamentalmente diferente:
- O otimista ignora qualquer problema enfrentado pelo projeto e relata informações incorretas às autoridades.
- O capitão da equipe considera o sucesso do projeto apenas em termos de moral: moral baixa é um projeto malsucedido; moral elevada é um projeto bem-sucedido. Ele pensa nos interesses dos clientes e superiores depois, se é que o faz.
O capitão da equipe é muito fácil de identificar:
- Ele vem espontaneamente com guloseimas como café e rosquinhas.
- Ele considera importante manter conversas em privado com cada funcionário "para ouvir suas necessidades".
- Como regra, ela gosta de falar sobre coisas pessoais, sobre a vida de um funcionário fora do trabalho (pensando que isso pode ser uma fonte de insatisfação).
- Ele envia cartas positivas, coloca motivadores em todo o escritório e geralmente é excessivamente positivo.
- Ele representa o melhor mobiliário de escritório, a melhor iluminação e, em regra, o melhor ambiente de trabalho.
- Luta ferozmente contra más condições de trabalho, como falta de desenvolvimento de carreira para os funcionários, treinamento insuficiente e horas extras.
- Organiza reuniões extracurriculares com a equipe, não vinculadas às etapas importantes do projeto.
- Muito preocupado que todos os participantes do projeto o amem.
Essa pessoa parece um gerente de projeto ideal, mas há duas razões para preocupação:
- Todos esses eventos aumentam temporariamente o moral, que desaparece rapidamente quando as pessoas se lembram das realidades do projeto.
- Eles não eliminam as causas fundamentais da baixa moralidade, preferindo incentivos de curto prazo.
Assim, o capitão da equipe, em última análise, todo mundo gosta, mas na verdade não faz o trabalho do gerente de projeto.
Solução
O principal problema é que o capitão da equipe geralmente não tem muita experiência como gerente de projeto. Portanto, a solução é treiná-lo. Felizmente, há uma enorme quantidade de recursos de treinamento para gerentes de projeto.
Fornecendo ao gerente as ferramentas necessárias, é necessário incentivá-lo a identificar as causas do baixo moral e depois corrigi-las. Levando em conta a tendência natural do capitão de equipe de melhorar o humor dos funcionários, ele certamente fará tentativas agressivas para encontrar e corrigir as causas do declínio moral assim que entender o que procurar.Nesse estágio, você obtém um gerente de projeto com uma mistura muito poderosa de motivações: primeiro, ele usa a moralidade como uma medida de problemas no projeto e, em segundo lugar, ele encontra esses problemas e os corrige. Como sua motivação vem da compaixão pelo próximo, os problemas subjacentes à baixa moralidade serão rapidamente erradicados.A propósito, em seu caráter, para serem gentis com os outros, é improvável que os "cure" desse componente, e sua "correção" não deve implicar a eliminação das partes positivas do personagem. No final, se é possível melhorar o nível do gerente de projetos, é difícil encontrar uma opção melhor para esses investimentos do que o capitão da equipe.Tirano
Um gerente que trata os membros do projeto com desprezo em nome de sua motivação para trabalhar mais.
O problema
Muitas personalidades fortes geralmente estão envolvidas em projetos de desenvolvimento de software, mas todos devem estar subordinados a um objetivo e focados na implementação do projeto. Portanto, os gerentes de projeto têm autoridade para liderar os participantes do projeto para garantir o sucesso do projeto. O tirano abusa desses poderes, usando reforço negativo para obter resultados.Embora os tiranos possam não ser amados, os chefes geralmente acreditam que sua "mão firme" é exatamente o que é necessário para que um projeto seja bem-sucedido, especialmente se estiver atrasado. Ameaças e punições realmente atuam como um motivador para muitos tipos de personalidade (veja um desenvolvedor como um soldado ), o que ajuda a espalhar tiranos.Problemas reais com tiranos são difíceis de detectar, mas são incrivelmente prejudiciais ao projeto.Quanto mais um tirano trabalhar, mais dramático será esse lento fluxo de talentos. No final, quando todos os participantes competentes do projeto forem expulsos, será impossível convidar participantes talentosos e experientes para o projeto, pois os funcionários em potencial não vão querer trabalhar com uma equipe incompetente (o fato aparece facilmente durante a entrevista).É importante observar que o tirano geralmente é apresentado ao projeto no momento mais inoportuno: quando o projeto está com problemas. Projetos em risco de falha devem despejar membros da equipe incompetentes, mantendo a competência, mas o tirano causa o efeito exatamente oposto.Solução
Para corrigir um tirano, é necessário trazer à sua consciência que esse comportamento afeta negativamente o projeto. Existem duas abordagens gerais para isso:Primeiro, forneça dados quantitativos que refletem seu estilo de gerenciamento de projetos:- Quantos funcionários valiosos deixaram o estado.
- Sucesso na atração de talentos.
- Quantos recursos lançados.
- Quantos bugs estão registrados.
- Quantas datas faltando.
Ao comparar essas informações, os cronogramas são especialmente eficazes.Em segundo lugar, informe a eles quais indicadores você espera em um futuro próximo. Provavelmente, eles mostrarão irritação e desesperança, porque não sabem como melhorar esses indicadores. Mas esta é uma oportunidade ideal para oferecer conselhos e treinamento sobre como se tornar um gerente melhor. O treinamento deve abranger o seguinte:- Como eles se comportam com os funcionários.
- Como eles discutem as falhas e os sucessos dos projetos.
- Como identificar e eliminar participantes incompetentes do projeto.
- Como atrair e reter participantes competentes.
Desde que exista um especialista adequado para esse treinamento, o gerente-tirano pode ser completamente corrigido, porque as seguintes características são naturalmente inerentes a uma pessoa:- As pessoas não querem ser más.
- As pessoas gostam de ser amadas.
- As pessoas gostam de ser eficazes.
O principal é que a equipe adote uma nova abordagem, apesar da reputação do tirano no passado. O problema pode ser resolvido de maneira muito simples, por exemplo, para convocar uma reunião com o tema "Sinto muito" e "Eu mudei para melhor".Obcecado com o processo
O gerente está tão obcecado com o processo que esquece sua tarefa - ajudar o projeto a alcançar o sucesso.
- Pode se transformar em um tirano
- Perigoso quando combinado com um gerente de produto do tipo ditador
- Probabilidade de correção: alta
- Perigo para o projeto: baixo
O problema
Ao final de qualquer curso de treinamento ou da leitura de qualquer livro sobre gerenciamento, cada gerente corre o risco de ficar obcecado pelo processo. Isso pode acontecer mesmo com os melhores, por isso é importante ter paciência ao corrigi-los.Existem duas categorias amplas de processos obcecadas por:- Obsessão em cachoeira
- Obsessão pelo desenvolvimento ágil (Agile)
Talvez o curso ou o livro de treinamento tenha chamado esses processos de maneira diferente, mas você pode colocá-los facilmente na categoria correta aplicando o seguinte teste:- Obcecado com a cachoeira, acredito que todos os problemas podem ser resolvidos com a ajuda de documentação adicional, por exemplo, "a partir de agora escreveremos requisitos de sistema para cada documento com requisitos de negócios".
- Os obcecados pelo desenvolvimento ágil acreditam que todos os problemas podem ser resolvidos com a ajuda de reuniões curtas e frequentes, por exemplo: "a partir de agora organizaremos reuniões diárias pela manhã não mais que 15 minutos".
O objetivo de qualquer gerente é entregar o projeto dentro do prazo e do orçamento. O processo que usamos facilita isso. Quando o gerente de projeto fica obcecado, ele pode ignorar o objetivo principal e, em vez disso, se concentrar na pergunta "O processo está dando certo?" em detrimento de outros deveres oficiais.Solução
Faça o que fizer, não tente roubar o processo ou desafiá-lo. Você está lidando com um fanático religioso, e não com uma pessoa racional. Ele se convenceu de que seu processo "consertaria" o projeto. Se eles acharem que o projeto está "quebrado" e você tentar dizer "isso não vai nos ajudar", eles simplesmente o considerarão parte do motivo pelo qual o projeto foi quebrado.É fácil consertar o processo obcecado: basta se contentar com tudo o que ele diz, lembrando gentilmente que “leva tempo para virar um navio grande” e “Roma não foi construída em um dia”. O objetivo é forçá-lo a concordar com a implementação de um novo processo por meio de uma série de pequenas inovações, em vez de uma grande mudança. Isso permitirá que eles aprendam com sua própria experiência quais métodos são eficazes e quais não são. Ao adquirir essa experiência, eles aprenderão como adaptar o processo à situação no terreno. Há esperança de que eles entendam: o processo é um meio para um fim, não um fim em si mesmo.Inseguro
Um gerente de projeto que solicita constantemente o status atual dos funcionários, considerando necessário que eles se concentrem no cumprimento de suas tarefas.
O problema
Quando um gerente se senta em sua mesa, longe dos participantes do projeto que estão fazendo o trabalho, ele pode facilmente ter uma sensação de inutilidade. Isso os leva a fazer o que for necessário para se sentirem necessários e úteis. Para um gerente incerto, a maneira mais óbvia de parecer produtivo é verificar o trabalho atual dos funcionários. Isso geralmente é alcançado usando os seguintes métodos:- Distribuição de e-mails solicitando o status do projeto.
- Agende reuniões para discutir o status.
- O requisito de preencher as folhas de ponto em detalhes.
- A exigência de dividir objetivos soltos em pequenas tarefas.
- Organizar reuniões espontâneas presenciais para perguntar aos membros da equipe sobre seu status.
Um gerente inseguro é amplamente conhecido por outro nome: microgerenciador. Seus métodos de gerenciamento de projetos são interpretados pelos membros da equipe do projeto como um ou todos os seguintes:- Nitpicking
- Assédio
- Preocupação
- Distração
- Interrupção
- Chato
Muitas vezes, os funcionários desenvolvem profundo ressentimento em relação a um gerente de projeto incerto, porque em sua percepção:- O gerente não confia em suas habilidades de gerenciamento de tempo.
- O gerente não acredita na avaliação dos prazos.
- O gerente não entende a necessidade de ficar sozinho para resolver problemas.
- O gerente não tem nada a fazer além de pedir e relatar status.
Essa percepção cria um confronto entre o gerente de projeto e os desenvolvedores, suprime a comunicação útil que o gerente poderia usar para corrigir problemas reais. Em vez de interagir com esse gerente para cooperação e cooperação, os desenvolvedores evitam contatos adicionais com ele, temendo que eles (mais uma vez) sejam solicitados por status.Solução
Um gerente inseguro é tão comum que esse comportamento é considerado o trabalho principal do gerente. Assumindo o inevitável, a maioria dos desenvolvedores forma um certo limite, com que frequência será solicitado seu status atual. Como a maioria aprendeu a se adaptar à constante busca pelo status, um gerente inseguro não representa um alto risco para o projeto, embora priva a equipe da possibilidade de comunicações úteis que poderiam ter ocorrido.Esse gerente nasce devido ao fato de que o desempenho da equipe não é bem visível para ele. Portanto, a solução é colocar esse gerente ao lado da equipe. Caso contrário, esse gerente é superado pelo desejo de perguntar diretamente o status de cada desenvolvedor. Se estiverem próximos, o gerente poderá entender o estado atual do projeto, apenas ouvindo as conversas dos desenvolvedores entre si. Nesse modo, o gerente é mais eficaz, pois ele só precisa intervir quando a produtividade é realmente difícil.Veja também: