Cómo estructurar un equipo de desarrollo

Soy el gerente de un equipo de 11 desarrolladores de software que se ocupan de los sitios web / aplicaciones web de mi compañía, ejecutando hasta 4 proyectos concurrentes más el soporte diario en cualquier momento. Dentro de los 11 desarrolladores hay una mezcla de habilidades técnicas, títulos de trabajo y experiencia, aunque la estructura del equipo es plana y los 11 desarrolladores me informan directamente.

Todo el equipo que tiene un solo gerente está comenzando a demostrar que no escala muy bien. Estoy empezando a difundirme demasiado, así que quiero reducir mi número de informes directos. Todas las formas en que puedo pensar para hacer esto tienen desventajas significativas:

• Haga que los desarrolladores junior reporten a los senior. Esto reduce el tiempo dedicado al desarrollo por los mejores técnicos.
• Divida el equipo por producto de software, por ejemplo, los desarrolladores 1-6 trabajan en la intranet y 7-11 trabajan en sitios externos, con cada sección con un nuevo líder del equipo (posiblemente una nueva descripción del trabajo con más responsabilidad de gestión / tutoría / entrenamiento que los desarrolladores senior actuales ) Esto agrega silos artificiales y podría dificultar que un "desarrollador de intranet" trabaje en un sitio web externo si así lo deseo.
• Mantenga la estructura plana y agregue soporte gerencial en la forma de Gerentes de Proyecto / Administradores de Equipo solo para aliviar la presión. Esto no resuelve el problema ya que el equipo no puede seguir creciendo así para siempre.

¿Existe una forma estándar de resolver este problema que me falta?

Si no, ¿cómo han resuelto este problema otros?

Algunos pensamientos rápidos:

• Los sub-equipos son una buena idea: 11 informes directos sin ninguna estructura son demasiado grandes para un equipo viable (no tendrá suficiente tiempo para el entrenamiento directo, y las reuniones de equipo con tantas personas tenderán a ser improductivas).
• Considere separar las operaciones del desarrollo: es un conjunto de habilidades ligeramente diferente y ser interrumpido por problemas operativos todo el día puede dañar seriamente la productividad del desarrollo en los proyectos.
• Como resultado de los primeros dos puntos, creo que debería tener quizás 3 equipos secundarios: Intranet, Sitios externos y Operaciones. Los encargados de operaciones se ocuparán de todos los problemas cotidianos / arreglos de mantenimiento, etc., mientras que los dos equipos de desarrollo se centran en entregar nuevos proyectos / valor a la empresa.
• Ciclo de personas entre equipos de forma regular. Esto puede ser ocasional (por ejemplo, hacer que la gente revise el código en otro equipo secundario), para un proyecto o de forma permanente. Pero asegúrese de que se entienda que los roles del equipo cambiarán siempre que haya una necesidad comercial: nadie "posee" un rol específico para siempre.
• No agregue más gerentes / administradores: esta es una forma segura de reducir la efectividad / productividad general de sus equipos. Haga que la persona con más experiencia en cada equipo juegue un rol de líder / entrenador del equipo. Asegúrese de que ellos vean su papel aquí como entrenador y hacer que todo el equipo tenga éxito, y asegúrese de que están equipados para comportarse de esta manera en lugar de actuar como un "administrador de tareas".
• Su función debe centrarse en la gestión de partes interesadas externas, la priorización de recursos / tareas dentro del grupo y actuar como "entrenador principal". Tendrá que manejar el problema ocasional escalado de los sub-equipos, pero en general debe alentarlos a resolver los problemas por sí mismos sin acudir a usted.
• Si usted es muy técnico, también puede elegir desempeñar un papel de arquitecto / garantía de diseño. Si no, encuentre a alguien que pueda, dentro del equipo o en otro lugar .....

Además, siempre vale la pena ir y (re) leer el Manifiesto Ágil , y especialmente los doce principios .

Esa estructura principalmente depend on project specifications

Idealmente, debería haber 3 juniors por desarrollador senior en un equipo. En consecuencia, hay 2-3 desarrolladores senior por líder de enseñanza.

Por lo tanto, solo los líderes tecnológicos informarán al Primer Ministro sobre el estado de progreso del proyecto. La estructura descrita aún asume que para problemas no técnicos (vacaciones, tiempo libre, conflictos, etc.) todos pueden tener acceso a PM.

Uno de los equipos de desarrollo de software relativamente exitosos de los que formé parte fue algo así por proyecto:

Un Gerente de Desarrollo de Software / Desarrollador Senior / Mentor, a quien todos los demás informaron directamente.

• Un gerente de proyecto, que mantuvo los horarios, facilitó los requisitos y la negociación de aceptación, e hizo comunicaciones. Todas las líneas punteadas también informaron a esta persona. Una persona de documentación (que ocasionalmente también era el primer ministro, pero solo cuando la experiencia lo permitía).
• Una combinación de 1-3 desarrolladores o desarrolladores senior, según las necesidades del proyecto.
• Un desarrollador junior cuando esté disponible.
• Alguien asignado de un grupo de control de calidad.
• Una persona de infraestructura (un rol a menudo desempeñado por el gerente, ya que también tenía una sólida competencia de SA).

Funcionó perfectamente bien, y me encantó esa organización. Por otro lado, yo era el Gerente de Desarrollo de Software, y la estructura organizativa del equipo estaba evolucionando.

Considere seguir el patrón de Organización Funcional del Personal . Esto hablaría hacia su segunda opción de dividir el equipo por producto de software.

Para citar el artículo en su contexto:

La mayor fortaleza de una organización funcional es que vincula las estructuras sociales con la entrega de valor comercial. En mi opinión, los proyectos de software tienen tanto éxito como mejoran la efectividad de la actividad que respaldan, generando valor comercial. Al organizar sus equipos de la misma manera, tiene un equipo orientado a satisfacer a sus usuarios comerciales.

La estructura real de gestión / recursos humanos es irrelevante más allá de eso.

¿Existe una forma estándar de resolver este problema que me falta?

Realmente no. Dependerá de su equipo, de usted, de lo que necesite hacer y de los recursos que la empresa pondrá a su disposición.

Personalmente, el mejor tipo de cambio es dividir la gestión técnica de la gestión administrativa. Es raro que las personas sean buenas en ambos, y rara vez tienden a interactuar.

Una persona maneja los aspectos técnicos. Lo que hay que hacer, quién lo va a hacer, cómo deben alinearse las cosas. El otro maneja aspectos administrativos. Revisiones, reuniones de presupuesto, planificación de productos, etc. Luego, trabajan juntas para comunicar ideas de un lado a otro y proporcionar un frente unido.

Cómo se divide esto puede ir de diferentes maneras. Lo más común es que el gerente de ingeniería sea el lado administrativo y un logro sea el lado técnico. Son pares e informan a un director / vicepresidente.

Otro trabajo que he visto es que el gerente de ingeniería sea la persona administrativa, y luego el líder del equipo actúe como la persona técnica. Esto es más complicado y requiere que las personas adecuadas actúen como (en su mayoría) pares, incluso si el informe es jerárquico.

Para su escenario específico, recomendaría tener 2-3 equipos y tener líderes técnicos que hagan los aspectos técnicos y se concentre en los administrativos. Sí, reduce el tiempo de los clientes potenciales que realmente escriben código, pero deberían (si están haciendo un buen trabajo) recuperar ese tiempo haciendo que los desarrolladores más jóvenes sean más eficientes / productivos. También les proporciona más motivación y una sensación de logro con la promoción real. Y más prácticamente, es más fácil vender a la gerencia que abrir una nueva posición.