¿Dividir la responsabilidad del PM entre el líder técnico y el PM no técnico en un proyecto ágil?

En primer lugar, podría usar diferentes métodos/marcos para ejecutar proyectos. Scrum no sería necesariamente la solución aquí, ya que su principal preocupación es la línea de responsabilidades entre estos dos roles, ambos diferentes y requeridos. Además de establecer el nivel adecuado de comunicación.

He captado algo del tono de su pregunta que parece resaltar ya un problema. En tu pregunta dices:

Un PM no técnico no puede identificar ciertas dependencias porque no tiene idea de que existen. De ahí mi pregunta.

En este sentido, le recomiendo encarecidamente que empiece a eliminar el atributo "no técnico" del rol. Ese no es el verdadero problema. El papel del PM no es resolver las dependencias técnicas por sí mismo, sino administrarlas con el apoyo y la experiencia del equipo involucrado. Si usted es el líder técnico, para eso está. Tienes la mejor información detallada sobre los aspectos técnicos del proyecto y entiendes mejor las dependencias.

Volviendo a la separación de funciones, puede referirse a marcos de gestión y entrega de proyectos como DSDM Atern . Si observa el siguiente diagrama de funciones y responsabilidades de DSDM Atern, podrá apreciar que las funciones de Gerente de proyecto (azul) y Coordinador técnico (verde) trabajan juntas para brindar valor comercial (trabajando junto con el Patrocinador comercial y el Visionario).

Algunas de las responsabilidades del Project Manager en este modelo serían:

• Comunicarse con la alta dirección y las autoridades de gobierno del proyecto (patrocinador comercial, junta del proyecto, comité directivo, etc.) con la frecuencia y la formalidad que consideren necesarias.
• Planificación y programación de proyectos de alto nivel, pero no planificación detallada de tareas
• Supervisar el progreso con respecto a los planes del proyecto de referencia
• Gestionar el riesgo y cualquier problema a medida que surja, escalando a
  roles comerciales o técnicos superiores según sea necesario
• Gestionar la configuración general del proyecto Motivar a los equipos para cumplir sus objetivos
• Gestión de la participación comercial dentro de los equipos de desarrollo de soluciones
• Especialista en recursos Roles según sea necesario Manejo de problemas escalados desde los equipos de desarrollo de soluciones
• Entrenando a los Equipos de Desarrollo de Soluciones cuando manejan situaciones difíciles

Mientras que para el Coordinador Técnico :

• Consensuar y controlar la arquitectura técnica
• Determinación de los entornos técnicos.
• Asesorar y coordinar las actividades técnicas de cada equipo.
• Identificar y hacerse cargo de los riesgos arquitectónicos y otros riesgos técnicos, escalando al Gerente de Proyecto según corresponda
• Asegurar que los requisitos no funcionales sean alcanzables y posteriormente cumplidos
• Asegurar el cumplimiento de los estándares apropiados de las mejores prácticas técnicas
• Controlar la configuración técnica de la solución
• Gestionar los aspectos técnicos de la transición de la solución al uso real
• Resolución de diferencias técnicas entre los miembros del equipo técnico

La combinación de los dos roles es realmente poderosa y generalmente conduce al éxito del proyecto.

Ahora, tenemos que abordar el problema de la comunicación.

Siempre les digo a las personas que deben dejar de esperar a que sucedan las cosas y señalar con el dedo más tarde si las cosas no salieron como esperaban. Este comportamiento no ayuda a nadie.

Si el gerente de proyecto de su equipo no se ha presentado para trabajar con usted sobre la frecuencia con la que deben reunirse o las herramientas para informar, siéntase más que capacitado para iniciar esa conversación usted mismo.

Mencionó que ya está usando Jira, por lo que tal vez podrían sentarse juntos un par de horas para determinar la mejor manera de usar la funcionalidad para capturar dependencias técnicas: vincular problemas de diferentes proyectos a una lista de proyectos de "Dependencias" , estado del informe, e informar si hay un equipo que ya está analizando el problema, etc.

Yo personalmente he usado Jira con GreenHopper para informes similares y ha funcionado muy bien.

Entiendo que la situación es:

1. Usted es un líder técnico (TL),
2. Le reportas a un PM que no tiene o casi no tiene conocimiento del dominio, conocimiento técnico.
3. El PM no te entiende.

"Un PM no técnico no puede identificar ciertas dependencias porque no tiene idea de que existen".: No tiene que hacerlo. Creo que es su principal responsabilidad explicar los problemas para que pueda entender.

Si yo fuera usted, hablaré en el idioma que el PM pueda entender y esté de acuerdo conmigo.

Hablar directamente con el PM y definir una matriz RACI clara será una buena idea.

El punto principal para la matriz RACI aquí podría ser: 1. El líder técnico administra e informa sobre problemas técnicos, alerta sobre posibles problemas no técnicos que puede detectar 2. El PM administra todos los aspectos no técnicos del proyecto, tales como: Recursos humanos , requisitos, riesgos, comunicaciones, presupuesto...

Puedes buscar en google

• "líder técnico" "director de proyecto" RACI

para ver en qué se diferencian un TL y un PM.

Para ser totalmente honesto, si su proyecto tiene un gerente de proyecto no técnico que no es muy fuerte en la lógica comercial o los aspectos funcionales del proyecto y también está involucrado en otros proyectos, su participación en el proyecto no debe ser mayor que la de tareas gerenciales, que es una forma más agradable de decir: "Quitar la basura del camino de su equipo y permitir que usted y el equipo de desarrollo se concentren en el trabajo real".

El podria:

1. Asista a reuniones de negocios interminables e informe al equipo de desarrollo y a usted sobre las cosas relevantes en 5 minutos, liberando así al equipo (y a usted) para que se concentren en hacer un trabajo de desarrollo real.
2. Ayude a mantener las hojas de tiempo y los planes de proyectos y actualícelos meticulosamente para que el resto del equipo no tenga que presentar informes de TPS . :)
3. Haga toda la documentación no técnica que nadie en el equipo esté interesado en hacer.
4. Póngase al día con usted y el equipo de manera informal y ayude al equipo a obtener lo que necesitan para hacer su trabajo (servidores, licencias, hardware, pizzas, café, etc.)
5. Promover el equipo y el trabajo que el equipo está haciendo para el resto del negocio. Las vibraciones y percepciones positivas sobre el proyecto y el equipo contribuyen en gran medida a que el proyecto sea exitoso. Los narradores de historias son tan importantes como los constructores .

Con gerentes que no son técnicos o que desempeñan un papel no técnico, los mejores saben cómo apartarse del camino del equipo, mantener los problemas fuera del camino del equipo, mostrar empatía, crear una vibra y una percepción positivas sobre el proyecto y el equipo, brinde al equipo lo que necesita para realizar su trabajo (servidores, licencias, etc.) y permita que los equipos de desarrollo hagan el trabajo real con un enfoque indiviso.

Como describe Steve Yegge en su publicación legendaria pero controvertida, cualquier otro intento por parte de gerentes no técnicos de administrar programadores puede ser peligroso .

Si no hizo clic en el enlace de arriba: http://steve-yegge.blogspot.in/2006/05/not-managing-software-developers.html es una lectura obligada.