¿Los Project Managers son redundantes en una agencia digital?

Descargo de responsabilidad: nunca he trabajado en una agencia digital y soy consciente de que el rol de Project Manager en las agencias digitales puede ser algo diferente al comúnmente aceptado en otras operaciones de TI, ya sea internamente o con proveedores de desarrollo de software. Además, no tengo claras las diferencias exactas.

A pesar de mi descargo de responsabilidad anterior, y tomando la pregunta y los roles al pie de la letra, creo que hay una serie de problemas con las suposiciones hechas aquí:

1. El administrador de proyectos/cuentas no es un desarrollador

¿Así que lo que? Estos son roles muy diferentes con responsabilidades muy diferentes. En mi experiencia, los desarrolladores a menudo piensan que el rol de Gerente de proyecto es similar de alguna manera al Líder de equipo o Líder de desarrollo. Sin duda, en algunas organizaciones ese es el caso en la práctica, pero asumo que no está aquí, ya que ya ha dicho que tiene Dev Leads. Así que esta es una declaración de hecho en lugar de un problema real. Puede generar problemas importantes en el proyecto si el PM necesita una apreciación técnica para completar su trabajo de PM o si el equipo de desarrollo usa la falta de experiencia técnica del PM en su contra, por ejemplo, sobreestimando o subestimando la carga de trabajo cuando el PM no lo hace. Tener las habilidades necesarias para revisar y cuestionar las estimaciones. Pero no es, en sí mismo, un problema.o al proyecto , ya que descubrirá problemas que se pueden abordar.

2. El efecto de los susurros chinos ocurre y los requisitos se pierden/confunden

Este es un problema de proceso. No cuenta con procesos de gestión de cambios, recopilación de requisitos y registro lo suficientemente sólidos para garantizar que los requisitos no se "pierdan". El PM debe reconocer eso, incluso si la organización no lo hace, e implementar algo localmente en el proyecto. Sin embargo, el hecho de que usted (y presumiblemente por extensión) el resto del equipo de desarrollo sepa que esto es un problema y que no ha implementado una solución habla de otros problemas no escritos aquí. Es responsabilidad de todos asegurarse de que los requisitos se gestionen correctamente.

3. El cliente quiere hablar directamente con los desarrolladores.

No hay ninguna razón inherente por la que esto sea un problema. puede _ser un problema si los desarrolladores no pueden comunicarse de manera efectiva con los clientes y este suele ser el caso en el mundo de TI en general. Tenga en cuenta que (espero) no estoy estereotipando aquí: los desarrolladores están orientados a los detalles, principalmente personas, y a menudo los clientes desean hablar a un nivel más conceptual con otras agendas que los desarrolladores no perciben. Por el contrario, los clientes a menudo no pueden discernir el verdadero significado y la consecuencia detrás de las preguntas técnicas de los desarrolladores. Siempre hay excepciones en ambos lados y lo he visto funcionar bien, pero no siempre. Si existe una necesidad real de que los clientes y los desarrolladores se comuniquen, el PM debe facilitarlo y administrarlo. No me refiero a que tienen que ser el cartero entre el diálogo o presente en cada reunión,

4. Los desarrolladores acaban convirtiéndose en gestores de proyectos.

¿Sin embargo? ¿O se convierten en lo que los desarrolladores creen que son gerentes de proyecto? ¿Los desarrolladores comienzan a administrar activamente los riesgos de los empleadores y los clientes? ¿Comienzan a negociar niveles de recursos, contratos y expectativas? ¿Reorganizan el plan del proyecto para tener en cuenta las nuevas dependencias y garantizar que las comunicaciones regulares y claras vayan en contra del plan de comunicaciones? etc. etc. etc. Si realmente comienzan a ser gerentes de proyecto, entonces claramente tiene un gerente de proyecto ineficaz. ¿O tal vez tiene un PM que no tiene experiencia y no se comunica correctamente, o no trabaja con el equipo de desarrollo para comprender lo que está sucediendo con el proyecto?

Resumen/TL:DR

Me parece que todos estos "problemas" son en realidad síntomas. Ninguno de ellos por sí solo es un problema real (excepto el punto 2, que es una falla grupal hasta donde puedo ver).

Entonces, ¿cuál es el resultado neto de estos síntomas?

• ¿El proyecto se entrega tarde?
• ¿El proyecto supera el presupuesto?
• ¿La calidad de entrega es mala?
• ¿El cliente está insatisfecho?

Lo que ha descrito es, posiblemente, un equipo disfuncional, tal vez con un PM sin experiencia o simplemente basura, pero tal vez no.

Comience por definir cuáles son los problemas materiales reales, no lo que usted o los desarrolladores o el PM piensan que son problemas de prácticas de trabajo locales. Parece que se ha acumulado algo de resentimiento, intente y vea más allá de los problemas reales. Luego, cuando sepa lo que realmente está mal, puede comenzar, como empresa, equipo e individuo, a pensar en lo que debe cambiar para corregir la situación.

Primero, todavía no ha definido un problema. Los clientes quieren hablar con los desarrolladores, ¿qué hay de malo en eso? ¿Qué efecto tiene eso en el alcance/calendario/costo del proyecto? ¿En alguna otra métrica del proyecto?

• ¿Existe un plan de comunicación? Las comunicaciones entre los desarrolladores y el cliente deben estar cubiertas por el plan de comunicaciones, que también debe contener disposiciones para garantizar que las partes interesadas adecuadas tengan la oportunidad de participar o estar al tanto de las discusiones.

• ¿Existe un plan de gestión de requisitos? Si los requisitos no están claros, entonces parece que hay una oportunidad para mejorar la captura y gestión de requisitos. Si se gestionaran los requisitos, ¿quizás el problema disminuiría?

• ¿Hay control de cambios? Aunque no lo has dicho, infiero que el problema es que cuando los clientes tienen la oportunidad de dialogar con los desarrolladores, la "aclaración" de los requisitos se traduce en cambios de alcance/cronograma/costo/calidad que impactan en el contrato. Esto no sucedería si los requisitos estuvieran bajo administración de cambios.

En la medida en que entiendo el problema, parece que el PM está fallando en al menos una sección de su trabajo. La solución parece ser entrenar/entrenar/aumentar al PM para permitir un desempeño exitoso.

Aparte: también recomendaría observar detenidamente la descripción del puesto para asegurarse de que la empresa requiera esas habilidades y el proceso de contratación para asegurarse de que está entrevistando para esas habilidades. Si falla la intervención con el gerente de proyecto actual, querrá asegurarse de no repetir el problema. (pero creo que eso está fuera del alcance de PM:SE)

Lo que exhibe el OP es un sesgo, y está utilizando los síntomas de su organización de lo que parece ser inmadurez del equipo, inmadurez del proceso y quizás problemas culturales como evidencia para apoyar el pensamiento perjudicial.

Cada rol tiene un conjunto de requisitos de conocimientos, habilidades y capacidades, y cada persona que ocupa un rol viene con diferentes grados de fortalezas y debilidades que cumplen con esos requisitos de conocimientos, habilidades y capacidades. A algunos de nosotros nos va mejor que a otros en la gestión de esas debilidades en términos de identificar mitigadores de cierre de brechas, pero la mayoría de nosotros, que finalmente no somos seleccionados para el puesto, encontramos una manera de desempeñarnos en algún nivel.

Un PM al que le falta un área técnica en conocimiento y habilidad, pero que tiene fortalezas sobresalientes en los 100 o más requisitos de conocimiento y habilidad ciertamente puede tener éxito en el puesto si encuentra mitigadores decentes para cerrar la brecha para lo que no sabe mientras explota sus fortalezas. en todos esos otros requisitos.

La validez de la selección es muy difícil de precisar porque no existe una talla única para todos. Las necesidades de cualquier proyecto dado en un momento dado podrían requerir un PM no técnico que tenga habilidades blandas sobresalientes para el servicio al cliente / capacidad de venta en un punto y luego cambiar a donde sería mejor un PM técnico muy fuerte.

Como PM y exdesarrollador que trabaja en una agencia digital, esta es mi opinión sobre el tema en función de mi experiencia y lo que he visto anteriormente trabajando con líderes técnicos (como exdesarrollador) y viendo a los desarrolladores ejecutar los proyectos en mi actual empresa:

• No había una estructura real sobre cómo se entregaban los proyectos, por lo que, a pesar de que el equipo técnico era técnicamente capaz, esto no equivalía a poder comunicarse de manera eficiente. Sin embargo, esto realmente sucedió cuando había varias personas trabajando en un proyecto, el equipo técnico tenía problemas para distribuir el trabajo y pronosticar los plazos con precisión.

Los desarrolladores simplemente no tenían la imaginación para mejorar los procesos existentes para aumentar la eficiencia y mejorar la forma en que se entregaban los proyectos.

• El equipo técnico tuvo problemas para recopilar los requisitos de manera eficiente, muy a menudo los técnicos miraban un requisito de manera demasiado técnica en lugar de cómo lo ve un usuario y carecían del "conocimiento" para organizar los requisitos en función de lo que brinda el mayor valor comercial. Este es más un rol de analista de negocios en lugar de PM, pero un PM debe poseer esta habilidad.

• Los técnicos que administraban los proyectos antes carecían de fuertes habilidades interpersonales, lo cual es imprescindible. Mantener a la gente motivada suena fácil, pero puede ser muy difícil sin recurrir a la microgestión cuando un proyecto va mal. He trabajado para líderes técnicos que veían las cosas tan en blanco y negro (como la codificación), que simplemente no sabían cómo mantener motivados a sus equipos y sacar lo mejor de sus colegas, dejándolos descontentos en el proceso.

• La gestión de cuentas es una habilidad no técnica pero vital. Muy a menudo tengo que comunicar el estado del proyecto al cliente final, y cuando las cosas no van bien, tengo que encontrar una manera de difuminar la situación para que el cliente siga siendo un cliente. Esta es una habilidad completamente no técnica y más sobre habilidades interpersonales.

• Presupuestar, un componente clave de mi función es asegurarme de que los márgenes de beneficio sean altos para cualquier proyecto que tenga que entregar. Esto significa tener una hoja de cálculo para realizar un seguimiento de todos los costos del proyecto.

Así que ahí lo tienes, ser técnico ayuda, pero PM es mucho más que conocer los aspectos técnicos de un proyecto de adentro hacia afuera. Un buen PM necesita tener suficiente conocimiento técnico para que los desarrolladores no se pongan lana en los ojos, pero no necesita ser profundo. Un PM talentoso encontrará personas talentosas para manejar ese lado del proyecto por él, que se vincula con la gestión de recursos. Entonces, en todo caso, podría decirse que tener una buena visión general del proyecto es mucho más importante, desde el nivel de las partes interesadas hasta los tecnicismos del proyecto.

Es cierto que los desarrolladores pueden aprender a convertirse en PM, pero no todos los desarrolladores tienen la personalidad adecuada para hacerlo, como el líder técnico que mencioné.

He trabajado como PM en 2 agencias digitales, mi opinión:

• ¡Eso depende!

¿En qué? Depende de la agencia en sí, y si realmente necesita a alguien que no sea un administrador de cuentas y líder de desarrollo para desempeñar algún papel en el proyecto.

A veces, sentí que mi papel era innecesario, y otras veces, sentí que el proyecto se desmoronaría si no lo mantenía unido.

Todo se reduce a la división del trabajo. ¿Hay trabajo real para que lo haga el PM? ¿O solo está allí porque alguien en la gerencia sintió que era necesario tener un gerente de proyecto en el equipo, por cualquier motivo?

A veces, solo hay una manera de averiguarlo. ¿Por qué no intentar lanzar un proyecto sin un PM y ver cómo va? Averigüe qué tareas fallan, qué no se comunica, etc. Si encuentra que las cosas van bien sin esta persona adicional en la mezcla, es probable que su trabajo sea redundante en su empresa. Si todo sale mal (y con prisas), sabrá que este miembro del equipo ha estado desempeñando un papel clave, aunque al principio no fuera obvio.

Los buenos PM mejoran a sus equipos, encuentran problemas y los resuelven de manera proactiva, para que nadie sepa que se evitó un problema potencial. Dicho de otra manera: cuando tienes un gran PM, a veces ni siquiera sabes que está ahí. No se supone que el trabajo en sí sea llamativo. En cambio, se supone que deben mantener las cosas en movimiento sin problemas y apartarse para que todos puedan hacer su trabajo de la manera más eficiente posible, sorteando los obstáculos del proyecto antes de que alguien más se dé cuenta de ellos. Es como si fueran el capitán de un barco, navegando entre icebergs, mientras todos se aseguran de que el motor funcione correctamente. El hecho de que no vea todo el trabajo que hacen, no significa que no estén desempeñando un papel clave.

Mirando la lista de síntomas, diría:

• No.

• los PM malos son redundantes (al menos en el sentido de que podrías deshacerte de ellos sin perder mucho).

• los desarrolladores que muestran talento para ello pueden convertirse en PM, pero esto debe ser reconocido y apoyado formalmente (y estar constituido por algo más que "Yo hago mis propios horarios").