¿Qué valor aporta un director de proyecto? ¿Cómo benefician a los miembros técnicos del equipo que realizan el trabajo (por ejemplo, los desarrolladores de software)? ¿Por qué los desarrolladores de software deberían preferir tener un gerente de proyecto como parte de su equipo? ¿Cuáles son algunas de las razones que podrían hacer que presionen para contratar o reclutar a un gerente de proyecto para que se una a su equipo, si aún no tienen uno? ¿Cómo un gerente de proyecto mejora su vida?
Pretenda que le está explicando esto a un desarrollador de software (u otro miembro del equipo técnico) y explíquelo en un lenguaje que apreciaría.
¿Qué valor aportan los gestores de proyectos a un equipo de desarrollo de software?
En la práctica, los gerentes de proyecto pueden o no proporcionar algún valor al equipo de desarrollo. Al igual que cualquier otro rol en una organización, el rol de PM es víctima de las prácticas de contratación de la organización y de la curva de campana como cualquier otro rol (como "desarrollador de software"), y tiene exactamente las mismas posibilidades de estar ocupado con mediocres. intérpretes o servidores de tiempo incompetentes.
Los gerentes de proyecto pueden y deben agregar valor a cualquier proyecto. Simplemente no es automático solo porque alguien está usando el sombrero PM.
La gestión de proyectos es, desde un punto de vista, la gestión de procesos y expectativas. Si bien Scrum no usa el título de Project Manager, definitivamente tiene que ver con la gestión de proyectos y proporciona un ejemplo ilustrativo del valor que dicha gestión brinda a los desarrolladores de software en el equipo cuando se realiza correctamente .
En Scrum, el Scrum Master proporciona el siguiente valor al equipo y a la organización:
En resumen, el rol de Scrum Master es un rol habilitador. Ya sea que su marco sea ágil o tradicional, la gestión de proyectos proporciona estructura al proyecto.
Si la gestión de proyectos (como marco) o un director de proyecto (como función) es difícil de vender dentro de su organización, entonces necesita descubrir las razones por las que esto puede ser así. ¿Ha tenido su equipo malas experiencias con individuos o marcos particulares en el pasado? ¿Ha encontrado su organización que la gestión de proyectos es más un obstáculo que un activo?
Cualquiera que sea la razón, hasta que comprenda completamente el contexto, evangelizar un marco o un rol será un ejercicio inútil. La gestión de proyectos está diseñada para resolver varios problemas comerciales; asegúrese de saber cuáles son realmente esos problemas comerciales (tanto para la organización como para el equipo de desarrollo de software) antes de intentar resolverlos de manera prescriptiva.
Me he desempeñado como gerente de proyectos en varios equipos de desarrollo de software y las analogías que más me gustan son las siguientes:
Piénselo de esta manera: los desarrolladores de software aportan un conjunto de habilidades muy especializadas, y cuando dedican su tiempo a rastrear a otros miembros del equipo para conocer el estado de una próxima transferencia, no están aplicando ninguna de esas habilidades. . Cuando tienen que ir a pedir más gente, un servidor adicional o más fondos, por lo general no son la mejor persona para esos trabajos. En pocas palabras, desde la perspectiva del desarrollador de software, un administrador de proyectos debería permitirle concentrarse en su verdadero trabajo.
Independientemente de la industria o el tipo de proyecto, alguien tiene que vigilar el presupuesto, el cronograma, el estado de los próximos componentes, lidiar con las solicitudes de cambio, verificar que se cumplan los requisitos, arbitrar los desacuerdos o los malentendidos, defender al equipo, hacer progresos como prometido, informar tanto a la dirección como al cliente, etc.
Es más fácil y más sensato que una persona haga eso en lugar de que "el equipo" lo maneje. No solo es desorganizado, sino que agrega otro nivel de toma de decisiones al proyecto: "¿quién se encargará de esto o aquello"?
No importa el proyecto, eventualmente alguien tiene que actuar como coordinador de todas las partes que no son específicas del proyecto o técnicas. Es mejor dejar que alguien se concentre solo en eso, para que el equipo pueda concentrarse en el trabajo.
Aparte de la respuesta de Brian Leach, no he leído las otras porque me gustaría que la mía fuera lo más imparcial posible. Pero en un equipo de desarrollo de software, el PM es vital porque alguien tiene que realizar un seguimiento de los aspectos básicos:
a) Time
b) Milestones
c) Deliverables
d) Communication (by far, the most important)
He trabajado como desarrollador y PM. A los PM les encantó trabajar conmigo porque yo, como desarrollador, puse un gran énfasis en d) (sin embargo, este no es el comportamiento típico de un desarrollador, ya que su trabajo es abordar los requisitos. Simplemente hice todo lo posible para explicar otros escenarios y retos).
A Devs, por otro lado, le encantaba mi trabajo como PM debido a ese mismo énfasis en la comunicación; específicamente, trataba con clientes y profundizaba en los detalles y les brindaba requisitos que eran lo más específicos posible.
El punto es este: sin un miembro del equipo que posea AMBAS habilidades para comunicarse claramente y comprender los requisitos, los desarrolladores deben darse cuenta de que la responsabilidad de estas tareas recaerá sobre ellos. Desde mi experiencia, puedo garantizar que estarían más que felices de tener un PM que maneje estos aspectos por ellos.
Creo que @Brian Leach ha dado en el clavo "Permítete concentrarte en tu verdadero trabajo", pero dado que @DW solicitó un lenguaje para ayudar a explicar a un miembro del equipo, permíteme ofrecer un par de observaciones más.
1) Siempre es mejor trabajar en un proyecto exitoso que en un proyecto fallido. Se ve mejor en su currículum, menos agotador para el alma. El papel del PM es asegurarse de que el proyecto tenga éxito (y hay algunas pruebas estadísticas que respaldan que tienen éxito; desafortunadamente, no puedo recordar ninguna en este momento. ¿Quizás alguien editará esto?)
2) PM debe actuar como un paraguas, manteniendo alejado "aquello que rueda cuesta abajo" de su cabeza. El PM debe estar al tanto de cualquier cosa que obstruya su trabajo y debe hacer el máximo esfuerzo para eliminar los impedimentos y agregar lubricantes. Eso incluye administrar las solicitudes de estado desde el exterior, detener el avance/cambio del alcance, garantizar que los gerentes/partes interesadas/patrocinadores sean conscientes del valor del proyecto y continúen patrocinando/apoyando el proyecto, etc. Si le piden que codifique en un oscuro dialecto de Cobol en una PC de disquete doble con un monitor monocromático ámbar para desarrollar un sistema de juego multiplataforma, es el trabajo del PM luchar por un conjunto de requisitos más razonable, para que los desafíos que enfrenta sean desafíos interesantes.
El gerente de proyecto administra el ciclo de vida del proyecto, mientras que el equipo de desarrollo administraría el ciclo de vida de la entrega del software. El concepto de gestión de proyectos a través de un control y una planificación despiadados es PM.
Por control y planificación despiadados, de ninguna manera me refiero a una dictadura, son las personas las que pueden hacer que un proyecto sea un éxito o un fracaso. Ahora he sido desarrollador, gerente de proyectos, scrum master y gerente de cartera. Como desarrollador, solía hacer la misma pregunta: ¿por qué necesitamos PM? cuando pasé a la gestión me di cuenta de que PM es en realidad una ciencia, es el arte de gestionar personas, expectativas, alcanzar metas. Al final del día, se necesita que alguien esté allí y motive mucho, constantemente a través del viaje para lograr resultados.
Si los desarrolladores de software entienden esto, pueden administrar, pero estarían cumpliendo el rol de gerente de proyecto.
doug b