¿Los buenos gerentes de proyecto necesitan un fondo de programación? [cerrado]

A veces no lo soporto cuando los gerentes de proyecto me piden que calcule el tiempo para completar varias tareas. Una estimación es una suposición, y las suposiciones pueden estar equivocadas. En general, los malos requisitos y la documentación conducirán a malas conjeturas.

Por lo tanto, a menudo me pregunto si los gerentes de proyecto alguna vez estuvieron en mi lugar tratando de adivinar cuánto tiempo durarán las tareas X e Y, y cuán difícil es asignarle un número en función de lo poco que se sabe y recopila del cliente.

Mi pregunta es: ¿los buenos gerentes de proyecto necesitan tener experiencia en programación?

O tal vez la pregunta debería ser, ¿los buenos gerentes de proyecto deben haber sido buenos programadores antes? ¿Hay alguna correlación?

Administrar proyectos de TI definitivamente no es lo mismo que administrar otros tipos de proyectos. Una vez escuché de un gerente de proyecto sin experiencia en TI. Terminó frustrando a los programadores y básicamente asustándolos.

Por otro lado, un programador que se convierte en Gerente de Proyecto puede convertirse en un fanático del control, pensando que puede arreglar las cosas si no puede lograr que los programadores lo hagan correctamente (ese ha sido mi problema en situaciones similares)

Un gerente con una sólida formación técnica generalmente entiende mejor cómo "piensa" su equipo. Siempre es mejor tener un gerente que te entienda, ¿no?

No. Dos habilidades completamente diferentes. Un mal gerente de proyecto no es necesariamente alguien que no entiende de TI, y viceversa.

Ser razonable, racional, organizado, comprender los objetivos del proyecto y los negocios asociados , y ser un buen motivador no dependen en absoluto de poder programar.

En igualdad de condiciones, preferiría un gerente de proyecto con experiencia técnica sólida y actualizada . Sin embargo, en el mundo real, los programadores que se gradúan en la gestión de proyectos a tiempo completo tienen más probabilidades de permitir que su conjunto de habilidades se vuelva obsoleto y desactualizado, lo que no es mucho mejor que ellos sin experiencia técnica.

He trabajado con buenos gerentes de proyecto y algunos terribles, y honestamente puedo decir que he visto poca correlación entre su capacidad de gestión y su formación técnica. El factor más importante no es la formación técnica, sino la experiencia que tienen en la gestión de proyectos de software . Si tiene dos personas administrando su primer proyecto, el programador que se graduará en administración de proyectos será tan malo como el gerente del proyecto sin experiencia en TI. Ambos pasarán por un empinado proceso de aprendizaje.

La discusión sobre la capacidad de los gerentes de proyecto sin antecedentes técnicos me recuerda un poco a esto:

Sinceramente, creo que la respuesta es no. Se requiere una gran cantidad de competencias para ser un buen gerente de proyecto y ser un programador no es una de ellas. Un buen gerente de proyecto podría administrar cualquier proyecto de cualquier tipo dado que hay buenas personas en el equipo del proyecto que saben lo que están haciendo. La principal cualidad que debe tener un gerente de proyecto son las habilidades de comunicación . El trabajo de un gerente de proyecto es coordinar las tareas del proyecto y mantener fluidas las comunicaciones entre el cliente, los equipos del proyecto y cualquier otra parte interesada. Él / ella debe saber en todo momento el progreso del equipo y si están experimentando obstáculos, pero no necesita saber cuál es el problema o qué necesita solucionarlo, a menos que implique a otra persona en el equipo cuyo tiempo lo hará deben ajustarse para ayudar a solucionar el problema.

En cuanto a las estimaciones, esa es una realidad de la vida en cualquier trabajo. Nunca podría construir una casa a tiempo si el electricista no pudiera decirle cuánto tiempo le tomará hacer el cableado. ¿Cuándo sabría reservar sus paredes? Sin embargo, estoy de acuerdo en que es muy difícil en TI dar estimaciones debido a la gran cantidad de imponderables. Los clientes no siempre saben lo que quieren y tienden a olvidarse de contarte muchas cosas. Lo que solía hacer es estimar aproximadamente cuánto tiempo pensé que tomaría, ¡luego multiplicarlo por 2! Y un buen administrador de programas no debería crucificarte cuando tu estimación sea incorrecta, le causará algunos dolores de cabeza reorganizar el horario, hablar con el cliente, explicarle a los jefes que va a costar más, etc. eso es parte de su trabajo, nuevamente, son principalmente lo que se requiere.

E incluso diría que no tener ninguna habilidad de programación es aún mejor : un exprogramador podría intentar hacer la estimación por su cuenta o adivinar sus estimaciones. Y todos sabemos que las habilidades de TI quedan obsoletas muy rápido. Debe comenzar a hacer preguntas cuando su gerente de proyecto esté más interesado en cómo va a hacer una tarea que en cuánto tiempo le llevará y cuándo terminará. Podrían pedirte que evalúes alternativas y permitirte analizar los detalles, pero el punto principal es saber cómo afectarás el cronograma del proyecto.

Finalmente, no estoy diciendo que no se necesiten habilidades de TI para administrar un proyecto de TI: las personas de TI son del tipo que simplemente no parecen ser capaces de vulgarizar lo que dicen para la gente común (!), Ayuda saber jerga básica para poder comunicarse con ellos! También es crucial conocer los pasos básicos : debe configurar un servidor antes de ejecutar un sitio web en él. ¡No podría manejar un proyecto de construcción si no supiera que el electricista tiene que terminar el cableado antes de cerrar las paredes!

Un primer ministro realmente necesita saber qué hará el proyecto, lo que probablemente requiera algunos antecedentes técnicos pero no se desarrolle.

Aparte de eso, es cuestión de respetar el campo y los desarrolladores, más que el conocimiento real. Un primer ministro necesita tomar en serio a los desarrolladores, lo que necesitan, lo que pueden hacer, lo que no pueden, cuánto tiempo llevará. Un primer ministro que tenga alguna idea de lo que él o ella no sabe puede ser muy efectivo. Un primer ministro que piensa que él o ella tiene todas las respuestas es malo. Este puede ser un ex desarrollador que cree que él o ella lo sabe todo y no lo sabe, o uno que nunca se desarrolló y no cree que necesite ningún conocimiento técnico especial para administrarlo.

No creo que un gerente de proyecto de un proyecto de TI requiera experiencia en TI. Pero él / ella definitivamente debe entender las TI, y debe saber cómo funcionan los proyectos de TI.

Aunque la experiencia en TI es una ventaja adicional, la falta de ella no lo convierte en un administrador de proyectos de TI no tan bueno. Además, tener experiencia en TI no es el factor decisivo.

He trabajado con ambos tipos, y cada uno tenía su conjunto único de cualidades y problemas.

Con el fondo de TI:
- Entendería cuando decimos un error de rendimiento porque el código no es multiproceso
- Pero, en algunas situaciones, diría "oye, vamos, solo está agregando 4 líneas de código, puedes hacerlo en 10 días"

Sin antecedentes de TI:
- Sería muy cómodo negociar para cambiar un plazo cómodo
- Para un proyecto sin ningún requisito (en absoluto, todavía), a veces diría "¿podemos dar una estimación aproximada de 100 días y mencionar un búfer del 30%.

Creo que necesitan algo de experiencia en programación. Si no es así, siempre presionarán a los programadores para que realicen sus tareas rápidamente y esperan que se realice en unas pocas horas, cuando en realidad la tarea requiere mucha reflexión y dedicación. Estas cualidades son conocidas y versan con los programadores, por lo que si el gerente de proyecto tiene experiencia en programación, entonces comprenderá cuánto tiempo llevará una tarea específica y no habrá argumentos dentro del departamento y, por lo tanto, al final, un buen proyecto evolucionará.

@NimChimpsky Estoy de acuerdo.

Es una cuestión de qué , no cómo (la escucha activa es una buena herramienta).

La estimación funciona para pequeñas tareas técnicas, pero para la planificación necesita trabajar juntos para ver toda la complejidad. Y no sois rivales.

Definitivamente ayudaría especialmente si no es un buen gerente de proyecto. Para un buen gerente de proyecto, realmente importa.

No.

Un buen gerente de proyecto es alguien que puede empatizar y comprender cuáles son las necesidades, preferencias y capacidades de su equipo, ya sea en el sitio de construcción, el piso de fabricación o la casa de desarrollo de software.

Un gerente de proyecto bueno o malo puede tener cualquier tipo de experiencia:

Los malos gerentes con antecedentes técnicos podrían haber sido programadores as que no aprecian la dificultad que enfrentan los novatos cuando se trata de conceptos mundanos y "fáciles" como los punteros.

Un buen gerente podría ser ese programador promedio que no fue tan brillante o inteligente como sus colegas, pero que tenía un profundo conocimiento de la estructura del proyecto, los requisitos y entendió las lecciones del Mes del Hombre Mítico de memoria porque vivió días malos de codificación. fue mordido por no terminar sus entregas a tiempo.

Un buen gerente podría ser ese vendedor de software que descubrió que sus amigos codificadores no podían salir con él los fines de semana debido a las promesas poco realistas que él mismo le había hecho al cliente.

El conocimiento técnico no predetermina las calificaciones de un programador como gerente, porque los conjuntos de habilidades requeridos en ambos trabajos son completamente diferentes. Entonces no.

Nunca he visto a un gerente de proyecto sin experiencia en TI que pueda administrar un proyecto de desarrollo de software no trivial que vale la pena. He visto a muy pocos gerentes de proyectos con experiencia en TI que pudieran hacer eso tampoco, pero parecían arruinarlo menos.

En mi experiencia, la gestión se trata de una comunicación efectiva y la toma de decisiones. Con eso en mente, tiene sentido que alguien que entiende los oficios (al menos los conceptos básicos y la terminología) utilizados por las personas que manejan, sea más adecuado para ser un gerente que alguien que tiene menos comprensión, pero definitivamente hay sin correlación. He visto a gerentes con experiencia en programación tener éxito y fracasar, tan a menudo como gerentes sin experiencia en programación.

Cualquiera de los extremos es malo, en mi opinión; Las personas con muy poca experiencia en programación pueden confiar ciegamente en sus programadores (Shepard sigue a las ovejas); Las personas con demasiada experiencia pueden cuestionar continuamente los esfuerzos de su equipo (microgestión).

Personalmente, creo que alguien que tiene una buena comprensión de los conceptos básicos de programación, pero se da cuenta de que no son una "buena opción", es el tipo ideal de gerente.

Seguro.

Tengo que tener cuidado con esto porque está basado en historias reales pero intentaré explicar mi dolor.

Estoy trabajando como ingeniero de software y tenemos un gerente de proyecto con el que trabajo mucho últimamente. No tiene antecedentes técnicos y parece que no le interesa en absoluto, pero ese no es el problema (todos tienen sus propios intereses). Si no le gusta tener conocimientos técnicos porque es un poco "extraño" de lo que es suyo PERO si es su trabajo hablar con el cliente a nivel técnico, es esencial tener conocimientos técnicos que él no tiene. tener.

De todos modos, hay un tipo que no entiende nada sobre cómo funciona un servidor, cómo funciona una página web, cómo funciona la programación, etc. A veces siento que él no sabe NADA. Entonces, cada vez que trato de dejarle claro lo que tenemos que hacer ahora o cuál es el problema que tenemos en este momento, él no entiende nada. Y él no es el tipo de persona que diría "Espera un segundo. ¿Puedes repetir que realmente no lo entiendo?". No, él es ese tipo de persona que no quiere demostrar que no entendió nada en toda la conversación.

Pero no termina aquí porque luego llama al cliente y habla algo que básicamente no es cierto. Y termina por tener que llamar al cliente juntos para que quede claro nuevamente.

Es por eso que digo que es realmente ESENCIAL tener algunos antecedentes técnicos básicos y conocimientos técnicos. No debería poder escribir código, pero debería ser capaz de comprender lo que está sucediendo y qué procesos deben realizarse.

Por cierto, ya que estoy trabajando con él, mi trabajo ya no es divertido.

Yo diría que sí, él debería tener algo de experiencia en programación. Si el administrador no tiene ni idea de cómo es programar, terminará con estimaciones poco realistas para el desarrollo y la corrección de errores. Además, no entendería ningún problema técnico lo suficientemente bien como para tomar una decisión. Los programadores en el equipo podrían mentirle y él podría no darse cuenta, también los programadores podrían decirle un problema y él podría pensar que están bromeando.

Las habilidades técnicas no son un buen gerente, las buenas habilidades de administración sí. Puede ser útil si un gerente ha hecho su tiempo en las "trincheras", ya que pueden apreciar el proceso que los laicos no pueden tener. Sin embargo, también puede dar lugar a una especie de fanatismo de control que incluso los gerentes laicos de control no tienen. Pueden intentar hacer todo el trabajo ellos mismos o examinar el suyo de una manera extremadamente incómoda.

En mi experiencia personal, el mejor gerente que tuve nunca tuvo ni idea de la tecnología, pero sabía que las personas que trabajaban debajo de él sabían lo que sabían y sabía cómo ganarse la lealtad y el respeto de su equipo. Trabajé con él durante cuatro años, y solo dejé la compañía porque él se fue y fue reemplazado por un gerente que no era tan bueno.

Uno de los peores gerentes que he tenido está versado en la codificación (si no es el diseño de software) y hace tanto trabajo por sí mismo que nos deja al resto de nosotros con poco más que recortes, corrección de errores o los proyectos que no quiere. para hacerlo él mismo.

Parece que hay cierta confusión:

El primer ministro no es el jefe de los desarrolladores . La persona responsable del equipo de desarrollo (Líder del equipo, Gerente) y que realiza la contratación y las evaluaciones debe decidir si está trabajando lo suficiente.

Las estimaciones no son perfectas. Creo que el primer ministro entiende esto más de lo que piensas. ¿Esperas seriamente que nadie te pregunte cuánto tiempo tomará hacer algo? Todos los chicos quieren saber cuándo está hecho y el trabajo del primer ministro es rastrearlo.

Puede ser un PM si: A) comprende cómo gestionar proyectos B) comprende el proceso de desarrollo. Ninguno de estos requiere conocimientos de codificación, pero puede ayudar.

Determinar si los programadores están haciendo lo suficiente no es el trabajo del primer ministro a menos que él también sea el líder del equipo. Para saber si alguien está "fumando humo" sobre el momento de completar una tarea, un gerente siempre tendrá una ventaja si comprende lo que implica.

Las estimaciones mejoran con programadores experimentados que tienen un historial de trabajo en un tipo particular de proyecto. Nadie espera que sean perfectos, pero sí esperan que se acerque y mejore con el tiempo.

Me recuerda el viejo dicho: "no tienes que estar loco para trabajar aquí, pero ayuda".

La respuesta corta es que la experiencia práctica de codificación no es un requisito para un buen PM de software, pero generalmente se prefiere. Lo que es crítico para ser un PM capaz es comprender el proceso de desarrollo (cualquiera que sea la metodología utilizada) y confiar en que los desarrolladores están dispuestos y son capaces de hacer su trabajo. La experiencia de desarrollo proporciona conocimiento práctico de ese proceso, por lo tanto, ayuda. Los PM que ascienden en la escala de una empresa también conocen la cultura corporativa (y la base de código) y tienen una buena relación con los otros miembros del equipo de desarrollo, por lo que en su lugar se promocionan los mejores PM. de ser traído desde afuera. Si alguien externo a la empresa puede administrar el equipo mejor que alguien interno, las cosas están MUY mal.

Una cosa que mencioné es una relación entre el primer ministro y el equipo de desarrollo. Esto es tanto a nivel interpersonal como técnico. La clave aquí es la comunicación; los desarrolladores deben sentir que pueden traer problemas, tanto técnicos como interpersonales, al primer ministro, y el primer ministro debe comprender a los miembros del equipo de desarrollo cuando describen un problema.

En cuanto a la naturaleza específica de su pregunta, una estimación es exactamente eso; una suposición educada en cuanto a una cantidad (en oposición a una hipótesis, que es una predicción más general del resultado de un evento futuro). El administrador generalmente aplicará matemáticamente o intuitivamente algún modificador, en función de sus estimaciones recientes en comparación con los plazos reales. Agile incorpora esto al proceso de estimación; el cliente estima intuitivamente la complejidad de los requisitos, luego los desarrolladores hacen lo mismo, y luego los desarrolladores realmente salen y desarrollan la solución, dando al gerente puntos de datos para calcular una relación de puntos de requisitos a puntos de desarrollo y puntos de desarrollo al hombre -hora requisitos.

En resumen, un gerente solo tomará su estimación al valor nominal en uno de los tres escenarios:

• Has sido bastante preciso con tus estimaciones de tareas similares en el pasado.
• Está bajo presión para cumplir, y su estimación es mejor de lo que pensaba.
• Está buscando una razón para despedirte.

Si se trata de la última situación, habrá muchas otras pistas en el lugar de trabajo que tal vez deberían salir.

No tengo idea, pero mi gerente necesita algunos conocimientos técnicos. Es imposible explicarlo a veces.