Os bons gerentes de projeto precisam de um plano de programação? [fechadas]

Às vezes, não consigo suportar quando os gerentes de projeto me pedem para estimar o tempo para concluir várias tarefas. Uma estimativa é um palpite e suposições podem estar erradas. Geralmente, os requisitos e a documentação incorretos levarão a maus palpites.

Então, eu sempre me pergunto se os gerentes de projeto estavam no meu lugar tentando adivinhar quanto tempo a tarefa X e Y levariam e quão difícil é atribuir um número a ela com base no pouco que é conhecido e coletado do cliente.

Minha pergunta então é: os bons gerentes de projeto precisam ter um histórico de programação?

Ou talvez a pergunta deva ser: bons gerentes de projeto precisam ter sido um bom programador antes? Existe alguma correlação?

Gerenciar projetos de TI definitivamente não é o mesmo que gerenciar outros tipos de projetos. Uma vez ouvi falar de um gerente de projetos sem experiência em TI. Ele acabou frustrando os programadores e basicamente assustando-os.

Por outro lado, um programador que se torna gerente de projeto pode se tornar um maníaco por controle, pensando que pode consertar as coisas se não conseguir que os programadores façam isso corretamente (esse foi o meu problema em situações semelhantes)

Um gerente com uma sólida formação técnica geralmente entende melhor como sua equipe "pensa". É sempre melhor ter um gerente que entenda você, não é?

Não. Duas habilidades completamente diferentes. Um gerente de projeto ruim não é necessariamente alguém que não entende de TI e vice-versa.

Ser razoável, racional, organizado, entender as metas do projeto e os negócios associados e um bom motivador não dependem de nada para poder programar.

Tudo o resto é igual, eu preferiria um gerente de projetos com forte experiência técnica atualizada . No entanto, no mundo real, é mais provável que os programadores que ingressam no gerenciamento de projetos em tempo integral permitam que seu conjunto de habilidades fique obsoleto e desatualizado, o que não é muito melhor do que eles sem formação técnica.

Trabalhei com bons gerentes de projetos e alguns terríveis, e posso dizer honestamente que vi pouca correlação entre a capacidade de gerenciamento e a formação técnica. O fator mais importante não é o conhecimento técnico, mas a quantidade de experiência que eles têm no gerenciamento de projetos de software . Se você tiver duas pessoas gerenciando seu primeiro projeto, o programador que se formar em gerenciamento de projetos será tão ruim quanto o gerente de projetos sem experiência em TI. Ambos vão passar por um processo de aprendizado acentuado.

A discussão sobre a capacidade dos gerentes de projeto sem formação técnica me lembra um pouco disso:

Sinceramente, acho que a resposta é não. Há toda uma bagagem de competências necessária para ser um bom gerente de projetos e ser um programador não é um deles. Um bom gerente de projeto pode gerenciar qualquer projeto de qualquer tipo, desde que haja boas pessoas na equipe de projeto que saibam o que estão fazendo. A principal qualidade que um gerente de projeto deve ter é a capacidade de comunicação . O trabalho de um gerente de projeto é coordenar as tarefas do projeto e manter as comunicações fluindo entre o cliente, as equipes de projeto e quaisquer outras partes interessadas. Ele / ela deve saber o tempo todo o progresso da equipe e se eles estão enfrentando obstáculos, mas não precisa saber qual é o problema ou o que você precisa corrigi-lo, a menos que isso implique outra pessoa na equipe cujo tempo será necessário. precisa ser ajustado para ajudar a resolver o problema.

Quanto a dar estimativas, essa é uma realidade da vida em qualquer emprego. Você nunca conseguiria construir uma casa a tempo, se o eletricista não pudesse lhe dizer quanto tempo levará para ele fazer a fiação - quando você saberia reservar o seu muro? Concordo, porém, que é realmente difícil na TI fornecer estimativas devido ao alto número de imponderáveis. Os clientes nem sempre sabem o que querem e tendem a esquecer de contar várias coisas. O que eu costumava fazer é estimar aproximadamente quanto tempo eu pensava que levaria, depois multiplicá-lo por 2! E um bom gerente de programa não deve crucificá-lo quando sua estimativa for errada, isso causará algumas dores de cabeça para reorganizar o cronograma, conversar com o cliente, explicar aos chefes que isso vai custar mais, etc. isso faz parte do trabalho deles - novamente, são principalmente o que é necessário.

E eu diria até que não ter nenhuma habilidade de programação é ainda melhor - um ex-programador pode tentar fazer a estimativa por conta própria ou adivinhar suas estimativas. E todos sabemos que as habilidades de TI são desatualizadas muito rapidamente. Você precisa começar a fazer perguntas quando o gerente de projeto estiver mais interessado em como você irá executar uma tarefa do que em quanto tempo isso levará e quando será feito. Eles podem pedir para você avaliar alternativas e deixar você detalhar os detalhes, mas o ponto principal é saber como você afetará o cronograma do projeto.

Finalmente, não estou dizendo que não são necessárias habilidades de TI para gerenciar um projeto de TI - o pessoal de TI é do tipo que simplesmente não consegue vulgarizar o que está dizendo para o povo comum (!), Ajuda a conhecer o jargão básico para poder se comunicar com eles! Também é crucial conhecer as etapas básicas - você precisa configurar um servidor antes de executar um site nele. Eu não poderia gerenciar um projeto de construção se não soubesse que o eletricista precisa terminar a fiação antes de fechar as paredes !!

Um PM realmente precisa saber o que o projeto fará, o que provavelmente requer algum conhecimento técnico, mas não está em desenvolvimento.

Fora isso, é uma questão de respeitar o campo e os desenvolvedores, mais do que o conhecimento real. Um PM precisa levar os desenvolvedores a sério, o que eles precisam, o que podem fazer, o que não podem, quanto tempo levará. Um PM que tem alguma idéia do que ele ou ela não sabe pode ser muito eficaz. Um PM que acha que tem todas as respostas é ruim. Pode ser um ex-desenvolvedor que acredita que sabe tudo e não sabe, ou um que nunca desenvolveu e não acha que precisa de algum conhecimento técnico especial para gerenciar.

Não acho que um gerente de projeto de um projeto de TI exija um histórico de TI. Mas ele / ela precisa entender definitivamente a TI e deve saber como os projetos de TI funcionam.

Embora o histórico de TI seja uma vantagem adicional, a falta dele não torna um gerente de projeto de TI não tão bom. Também ter formação em TI não é o fator decisivo.

Trabalhei com ambos os tipos e cada um deles teve um conjunto único de qualidades e problemas.

Com o backround de TI:
- Entenderia quando dizemos erro de desempenho porque o código não é multiencadeado
- Mas, em algumas situações, diria "ei, vamos lá, é apenas adicionar 4 linhas de código, você pode fazer isso em 10 dias"

Sem experiência em TI:
- Seria muito confortável negociar a alteração de um prazo confortável
- Para um projeto sem requisitos (ainda), às vezes dizia "podemos dar uma estimativa aproximada de 100 dias e mencionar um buffer de 30%.

Eu acredito que eles precisam de algum conhecimento de programação. Caso contrário, eles sempre estarão pressionando os programadores a executar suas tarefas rapidamente e esperam que isso seja feito dentro de algumas horas, quando, na verdade, a tarefa exige muito pensamento e dedicação. Essas qualidades são conhecidas e bem versadas pelos programadores; portanto, se o gerente de projeto tiver experiência em programação, ele entenderá quanto tempo uma tarefa específica levará e não haverá argumentos dentro do departamento e, portanto, no final, um bom projeto evoluirá.

@NimChimpsky, eu concordo.

É uma questão de quê , não de como (a Escuta Ativa é uma boa ferramenta).

A estimativa funciona para pequenas tarefas técnicas, mas para o planejamento, você precisa trabalhar em conjunto para ver toda a complexidade. E você não é rival.

Definitivamente ajudaria, especialmente se eles não forem um bom gerente de projetos. Para um bom gerente de projeto, isso realmente importa.

Não.

Um bom gerente de projetos é alguém que pode simpatizar e entender quais são as necessidades, preferências e capacidades de sua equipe, seja no canteiro de obras, na área de fabricação ou na casa de desenvolvimento de software.

Um gerente de projeto bom ou ruim pode ter qualquer tipo de plano de fundo:

Os maus gerentes com formação técnica poderiam ter sido bons programadores que não apreciam a dificuldade que os novatos enfrentam ao lidar com conceitos mundanos e "fáceis", como indicadores.

Um bom gerente poderia ser aquele programador médio que não era tão brilhante ou inteligente quanto seus colegas, mas tinha um profundo entendimento da estrutura do projeto, requisitos e compreendia as lições do The Mythical Man Month de cor, porque ele próprio vivia maus dias de codificação e foi mordido por não terminar seus resultados a tempo.

Um bom gerente poderia ser o vendedor de software que descobriu que seus amigos codificadores não podiam sair com ele nos finais de semana por causa de promessas irreais que ele próprio havia dado ao cliente.

O conhecimento técnico não predetermina as qualificações de um programador como gerente, porque as habilidades necessárias nos dois trabalhos são totalmente diferentes. Então não.

Nunca vi um gerente de projeto sem experiência em TI que pudesse gerenciar um projeto de desenvolvimento de software não trivial. Vi muito poucos gerentes de projeto com experiência em TI que também podiam fazer isso, mas eles pareciam estragar tudo.

Na minha experiência, gerenciamento é sobre comunicação e tomada de decisão eficazes. Com isso em mente, faz sentido que alguém que entenda o ofício (pelo menos os principais conceitos e terminologia) utilizados pelas pessoas que gerenciam, seja mais adequado para ser um gerente do que alguém que tenha menos entendimento, mas definitivamente há nenhuma correlação. Vi gerentes com experiência em programação serem bem-sucedidos e falharem, tão frequentemente quanto gerentes sem experiência em programação.

Qualquer extremo é ruim, na minha opinião; Pessoas com pouca experiência em programação podem confiar cegamente em seus programadores (Shepard seguindo as ovelhas); Pessoas com muita experiência podem questionar continuamente os esforços de sua equipe (microgerenciamento).

Pessoalmente, acho que alguém que tenha uma boa compreensão dos principais conceitos de programação, mas perceba que não é um "hot shot", é o tipo ideal de gerente.

Definitivamente.

Eu tenho que ter cuidado com essa porque ela é baseada em histórias verdadeiras, mas tentarei explicar minha dor.

Estou trabalhando como engenheiro de software e temos um gerente de projetos com quem trabalho muito ultimamente. Ele não tem formação técnica e parece que isso não lhe interessa, mas esse não é o problema (todos têm interesses próprios). Se você não gosta de ter know-how técnico, é meio "esquisito" do que o seu, mas se é seu trabalho conversar com o cliente em um nível técnico, é essencial ter um conhecimento técnico que ele não tem. ter.

De qualquer forma, existe esse cara que ele não entende nada sobre como funciona um servidor, como funciona uma página da web, como funciona a programação e assim por diante. Às vezes eu sinto que ele não sabe de nada. Então, toda vez que estou tentando deixar claro o que temos que fazer agora ou qual é o problema que temos no momento, ele não entende nada. E ele não é o tipo de cara que diria "Espere um segundo. Você pode repetir que eu realmente não entendo direito". Não, ele é o tipo de cara que não quer mostrar que não entendeu nada em toda a conversa.

Mas isso não termina aqui porque ele liga para o cliente e fala algo que basicamente não é verdade. E acaba que precisamos chamar o cliente para esclarecer novamente.

É por isso que digo que é realmente essencial ter algum conhecimento técnico básico e conhecimento técnico. Ele não deve escrever código, mas deve entender o que está acontecendo e quais processos precisam ser feitos.

Aliás, como estou trabalhando com ele, meu trabalho não é mais divertido.

Eu diria que sim, ele deve ter alguma experiência em programação. Se o gerente não tem idéia de como é programar, ele terá estimativas irreais para desenvolvimento e correção de erros. Além disso, ele não entenderia nenhum problema técnico o suficiente para tomar uma decisão. Os programadores da equipe podem mentir para ele e ele pode não perceber, os programadores também podem lhe contar um problema e ele pode pensar que eles estão mentindo

As habilidades técnicas não são um bom gerente, mas as boas habilidades de gerenciamento. Pode ser útil se um gerente tiver cumprido seu tempo nas "trincheiras", pois pode apreciar o processo que os leigos não podem ter. No entanto, também pode resultar em um tipo de esquisitice de controle que nem mesmo os gerentes leigos esquisitos controlam. Eles podem tentar fazer todo o trabalho sozinhos ou examinar o seu de uma maneira extremamente desconfortável.

Na minha experiência pessoal, o melhor gerente que já tive foi bastante ignorante em relação à tecnologia, mas ele sabia que as pessoas que trabalhavam com ele conheciam suas coisas e sabia como conquistar a lealdade e o respeito de sua equipe. Trabalhei com ele por quatro anos e só saí da empresa porque ele havia sido substituído por um gerente que não era tão bom.

Um dos piores gerentes que já tive é versado em codificação (se não design de software) e faz tanto do trabalho que ele deixa o resto de nós com pouco mais do que recados, correções de bugs ou projetos que ele não deseja. fazer a si mesmo.

Parece haver alguma confusão:

O PM não é o chefe dos desenvolvedores . A pessoa responsável pela equipe de desenvolvimento (líder da equipe, gerente) e faz as contratações e avaliações deve decidir se você está trabalhando duro o suficiente.

As estimativas não são perfeitas. Eu acho que o primeiro-ministro entende isso mais do que você pensa. Você espera seriamente que ninguém lhe pergunte quanto tempo levará para fazer alguma coisa? Todo garoto quer saber quando está pronto e é o trabalho do PM acompanhá-lo.

Você pode ser um PM é você: A) entender como gerenciar projetos B) entender o processo de desenvolvimento. Nenhuma delas requer conhecimento de codificação, mas pode ajudar.

Determinar se os programadores estão fazendo o suficiente não é o trabalho do PM, a menos que ele seja o líder da equipe. Para saber se alguém está ou não "soprando fumaça" na hora de concluir uma tarefa, o gerente sempre terá uma vantagem se entender o que está envolvido.

As estimativas melhoram com programadores experientes que têm um histórico de trabalho em um tipo específico de projeto. Ninguém espera que eles sejam perfeitos, mas eles esperam que você chegue perto e melhore com o tempo.

Lembro-me do velho ditado: "você não precisa estar louco para trabalhar aqui, mas ajuda".

A resposta curta é que a experiência prática de codificação não é um requisito para um bom gerente de software, mas geralmente é o preferido. O que é fundamental para ser um PM capaz é entender o processo de desenvolvimento (qualquer que seja a metodologia usada) e confiar que os desenvolvedores estão dispostos e capazes de fazer seu trabalho. A experiência de desenvolvimento fornece conhecimento prático desse processo e, portanto, ajuda. Os PMs que sobem a escada em uma empresa também conhecem a cultura corporativa (e a base de código) e têm um relacionamento com os outros membros de longa data da equipe de desenvolvimento, e é por isso que os melhores PMs da IMO são promovidos a partir de dentro. de ser trazido de fora. Se alguém de fora da empresa pode gerenciar melhor a equipe do que alguém de dentro, as coisas estão MUITO erradas.

Uma coisa que mencionei é um relacionamento entre o PM e a equipe de desenvolvimento. Isso é tanto no nível interpessoal quanto no técnico. A chave aqui é a comunicação; os desenvolvedores devem sentir que podem trazer problemas, tanto técnicos quanto interpessoais, para o gerente de projetos, e o gerente de projetos deve entender os membros da equipe do desenvolvedor quando descreverem um problema.

Quanto à natureza específica da sua pergunta, uma estimativa é exatamente isso; um palpite fundamentado sobre uma quantidade (em oposição a uma hipótese, que é uma previsão mais geral do resultado de um evento futuro). O gerente geralmente aplicará matematicamente ou intuitivamente algum modificador, com base nas suas estimativas recentes e nas linhas do tempo reais. O Agile cria isso no processo de estimativa; o cliente calcula intuitivamente a complexidade dos requisitos, os desenvolvedores fazem o mesmo e os desenvolvedores desenvolvem a solução, fornecendo pontos de dados ao gerente para calcular uma proporção de pontos de requisitos para pontos de desenvolvimento e pontos de desenvolvimento para homens requisitos de horas.

Em suma, um gerente fará apenas sua estimativa pelo valor nominal em um dos três cenários:

• Você foi bastante preciso com suas estimativas de tarefas semelhantes no passado.
• Ele está sob pressão para entregar, e sua estimativa é melhor do que ele pensava.
• Ele está procurando um motivo para demiti-lo.

Se for essa última situação, haverá muitas outras pistas em torno do local de trabalho de que talvez você deva dar o fora.

Não faço ideia, mas minha manjedoura precisa de algum conhecimento técnico. É impossível explicá-lo às vezes.