Se debe liderar un equipo de ingenieros (software en este caso). El liderazgo puede implicar:
Todos esos roles contribuyen mucho. Pero, para un equipo de, digamos, 6 ingenieros, 4 líderes realmente no tiene sentido. Y dividir a los líderes entre múltiples proyectos tampoco funciona bien.
Entonces, dado que un equipo es lo suficientemente grande como para necesitar liderazgo, ¿cómo lo haces?
ACTUALIZACIÓN: En respuesta a las solicitudes de aclaración:
Esta es una empresa pequeña y en crecimiento, con solo 1 equipo de ingeniería. No es lo suficientemente grande para una organización matricial. Hasta ahora, han sido solo 2 (luego 3) ingenieros, que también son los gerentes comerciales, propietarios, empresarios, etc. Ahora que se está moviendo a un equipo de ingeniería distinto de la administración y propiedad comercial, está claro que el equipo necesita liderazgo. La pregunta es tanto sobre la contratación (para qué tipo de función debemos contratar) como sobre la estructura (cómo deben estructurarse la autoridad y la responsabilidad).
En otros lugares, he visto equipos en los que se suponía que todos tenían estos roles, lo que significaba que nadie los tenía. Hay muchos ingenieros competentes que pueden realizar tareas, pero no pueden diseñar, administrar un proyecto o comprender las necesidades del cliente. Por lo tanto, existe una necesidad real de asegurarse de que estos roles se cubran.
Esta respuesta depende un poco de tu cultura. Una estructura matricial no es infrecuente en los EE. UU. Con esta opción, los ingenieros informarían a un líder sobre sus problemas técnicos, quizás el Arquitecto o el Ingeniero líder. Sin embargo, para cuestiones no técnicas, el PM brindaría el liderazgo necesario. Esta estructura matricial permite a los trabajadores obtener lo que necesitan de aquellos que están mejor capacitados para brindárselo, al mismo tiempo que proporciona una formalidad a la estructura.
En algunos países, por ejemplo en Francia, los trabajadores normalmente no aceptan fácilmente la idea de tener dos jefes. Por esta razón, la estructura matricial es extremadamente rara en esos países.
Si utiliza una estructura matricial, no tendrá un líder a tiempo completo sino dos líderes a tiempo parcial. Los líderes que son 'líderes a tiempo parcial' también pueden ayudar con la moral, ya que esas personas también estarán haciendo un 'trabajo real' junto con los ingenieros.
TL: DR En su escenario, use un ingeniero líder que tenga conocimientos sobre técnicas de PM y aspectos técnicos.
Respuesta detallada Hay muchos matices y variaciones, por supuesto, y no hay una respuesta correcta para esto. Pero creo que está equivocado en algunos de sus principios básicos. Si está hablando de Liderazgo de proyectos, donde el proyecto es la entrega de software, entonces solo se deben considerar dos de sus roles para ese liderazgo; Jefe de proyecto e ingeniero jefe.
Un Arquitecto no es un líder de un equipo de entrega de software, es un miembro del mismo con sus propios entregables (la visión arquitectónica y el diseño, etc.)
Un Product Owner (a menos que esté hablando de Agile aquí, en cuyo caso no estoy seguro de mi posición) no es un líder de un equipo de entrega de software, alimenta los requisitos al equipo en nombre de la base de usuarios y facilita la prueba de la salida en en nombre de la base de usuarios.
Entonces, en términos de liderazgo, debe (generalización masiva) considerar solo el PM y el TL de su lista.
Para un equipo pequeño, como el que usted describe, yo diría que el líder técnico (ingeniero líder) debe asumir el rol de líder del proyecto, pero solo sobre la base de que entiendan que el liderazgo del equipo técnico NO es lo mismo que la gestión del proyecto (yo volveré a esto).
En este escenario, se podría utilizar un Project Manager puro, pero a menos que sean técnicos, no podrán facilitar la toma de decisiones técnicas y la adjudicación. Además, pueden verse abrumados por los detalles técnicos y volverse menos efectivos.
El problema es que la gestión de proyectos requiere cosas diferentes al liderazgo técnico o de ingeniería y usted destacó algunas de ellas arriba. Pero una de las diferencias clave en este escenario es que el PM considera la entrega del proyecto como un todo, no solo las actividades de codificación y desarrollo. Por lo tanto, planificarían y facilitarían las pruebas, los talleres de usuarios y la gestión de expectativas, informando a las partes interesadas principales sobre el progreso general del proyecto, la gestión de riesgos y problemas que fácilmente pueden no tener nada que ver con la ingeniería, y muchas cosas más. Por lo tanto, su ingeniero principal tendría que ser experto en PM, o su PM tendría que ser algo técnico,
También debe tener en cuenta que los codificadores/desarrolladores/ingenieros técnicos a menudo no se llevan bien con la gestión de proyectos ("se hará cuando esté terminado") y ahí es donde realmente se necesita una interfaz técnica entre el PM y los desarrolladores. .
Si entiendo bien su pregunta, algo que ayudará es hacer una distinción entre liderazgo de proyecto y liderazgo de equipo.
El liderazgo del proyecto, es decir, el liderazgo en cuestiones relacionadas con el trabajo del proyecto en sí, se puede compartir con bastante facilidad y puede obtener mucho valor del liderazgo colaborativo. El mayor éxito que he tenido (y visto en otros equipos) es tener diferentes personas que tengan la última palabra en diferentes áreas: PM es su última palabra sobre el proceso, PO sobre decisiones sobre características y funcionalidad, arquitecto de diseño de software, etc. Aunque son la última palabra, todos pueden opinar. Esto generalmente mantiene a todos involucrados y comprometidos, pero usted tiene la última palabra una vez que la conversación simplemente está dando vueltas y ya no agrega más valor.
Por liderazgo de equipo, me refiero a las personas que brindan liderazgo en los asuntos de los miembros del equipo directamente. Esto incluiría cosas como desempeño insatisfactorio, orientación profesional, etc. En grupos que son demasiado pequeños para tener un gerente dedicado, he visto que los gerentes de proyecto comparten bien este rol. Los OP tienen mucho en juego en la entrega, por lo que cuando hacen demandas al equipo, es egoísta. Puede funcionar tener un PO que dirija el equipo, pero creo que PM funciona mejor. Hacer que un miembro del equipo lo haga es muy difícil porque está demasiado metido en la maleza. Eso no quiere decir que otras personas no lo hayan hecho funcionar, pero no es lo que recomendaría.
Espero que eso ayude. ¡Buena pregunta!
Olvídate del "liderazgo" y piensa en las "responsabilidades". "¿Quién es responsable de qué?" es una pregunta mucho más importante y correcta que "¿quién nos dirige?"
Tu arquitecto tiene que ser responsable de las decisiones técnicas, y su palabra debe ser definitiva. El propietario de su producto dirá cómo debe verse el producto, y su palabra es final, etc. Tal actitud creará un ambiente mucho más saludable que aquel en el que la gente lucha por el "liderazgo".
jmort253