¿Cuál es la mejor manera de organizar / estructurar un grupo de programadores?

Esto depende en gran medida de su operación y del tipo de proyectos en los que sus programadores estarán trabajando. El talento que necesita adquirir y cómo / si los divide en equipos (o no) van de la mano con los proyectos que entregarán.

No existe una regla de estructuración absoluta que garantice una alta productividad y un rendimiento elevado.

Dicho lo anterior, tenga en cuenta lo siguiente:
1. Pequeños equipos:
1.1 generalmente funcionan mejor que los más grandes.
1.2 son más fáciles de gestionar y definir sus tareas.
1.3 aumentan la facilidad de monitorear su desempeño.
1.4 tiene menos sobrecarga de comunicación y colaboración.

2. Calidad no cantidad:
  1.1 Los desarrolladores de Rockstar (odian este término) no necesariamente significan:
1.1.1 Buenas habilidades de liderazgo.
1.1.2 Buen entendimiento comercial.
1.1.3 Buena comprensión de la dinámica de operación.
1.1.4 Buenas capacidades de mentoría.
1.1.5 Buenas habilidades de colaboración.
1.2 Los desarrolladores de Rockstar tienden a ser obstinados y un poco tercos.
1.3 Igual talento significa necesariamente que 5 desarrolladores promedio igualarán la productividad de un desarrollador Rockstar.

3. Diferentes combinaciones de habilidades son mejores:
   1.1 Ningún desarrollador, Rockstar o no lo sabe todo.
1.2 Los desarrolladores coincidentes con diferentes antecedentes y conjuntos de habilidades pueden conducir a un mejor rendimiento si pueden sincronizar.
1.3 Dividir las tareas en cuestión será más fácil y reducirá la sobrecarga de delegar una tarea determinada a los miembros de otro equipo que tengan esa habilidad específica.

Nuevamente, todo depende del proyecto (s). Analice su operación correctamente y forme los equipos en consecuencia.

Probablemente tendrás otras personas además de programadores, ¿verdad? ¿quizás diseñadores, probadores, gerentes / propietarios de productos UX? La pregunta mucho más importante es cómo los estructura a ellos y a los programadores. Y yo (y muchas personas) creo que la mejor manera es formar equipos interfuncionales. Es decir, forme unos pequeños equipos que tengan unos pocos programadores, más quizás un probador, un propietario del producto y un diseñador de UI / UX. (a veces es una persona, a veces dos personas).

En cuanto a la contratación / división de programadores en términos de habilidades, obviamente desea contratar programadores calificados, pero es realmente importante (quizás más importante) que contrate a buenas personas que sean buenas para aprender, comunicarse, compartir información, comprender la visión del producto y estrategia, etc. Todas esas habilidades son SUPER importantes y difíciles de aprender (más difícil que programar, creo). Especialmente la capacidad de enseñar, compartir y aprender. Si tienes personas con esas habilidades, tus programadores se llevarán rápidamente a un alto nivel, especialmente si formas Guilds (busca el modelo de Spotify Tribes vs Guilds si quieres saber más).

Leon Tranter | Incertidumbre extrema: práctica ágil para TI empresarial

Creo que la regla de Google de nunca tener un equipo que no pueda ser alimentado por 2 pizzas trabajando en una función es una gran regla para vivir. Agile también ha demostrado que los equipos de números impares tienen más éxito. Entonces limitaría un equipo a 7 o 9 para una función. Con eso en mente, querrás considerar lo que estás creando. ¿Es UI pesado? ¿Es más codificación de back-end? es igual? .

Tomemos un equipo de 7, por ejemplo, iría con:

1 Propietario del producto (también puede actuar como gerente de proyecto de scrum master)
1 Diseñador de UX / UI (quién puede codificar)
3 desarrolladores (dependiendo del tipo de proyecto que podrías intercambiar por un diseñador)
2 ingenieros de control de calidad (puede cambiar un control de calidad por un desarrollador si tiene buenos marcos de automatización y pruebas unitarias)

Para un equipo de 9 iría con:

1 propietario del producto
1 Scrum Master / Project Manager (podría salirse con la suya sin Scrum Master y sustituir a un Dev Lead experimentado con experiencia en proyectos que puede codificar parte del tiempo siempre que pueda practicar Scrum bien)
2 diseñadores de UX / UI (que pueden codificar)
3 desarrolladores
2 ingenieros de control de calidad (mantendría al menos 2 controles de calidad en este equipo ya que la cantidad de código requerirá más ancho de banda de control de calidad)

Ahora, en función de cuán pesada sea su función en el front-end, puede agregar o restar diseñadores según sea necesario y aumentar con los desarrolladores de back-end.

Otra opción es ir con ingenieros multipropósito que pueden abarcar el front-end y el back-end, estas “estrellas de rock” son difíciles de encontrar y pueden carecer de habilidades en un área u otra, no asuma que pueden codificar y por la pila

Me gusta considerar la regla de las 10.000 horas para evaluar el estado de la estrella de rock. ¿Han codificado en su disciplina por 10,000 horas? Digamos que tienes un Python Dev que tiene 10,000 horas de experiencia pero solo 2,000 horas de javascript y CSS, probablemente puedan hackear una interfaz de usuario frontal, pero no será tan “limpio” como un Diseñador con 10,000 horas de experiencia .

Finalmente, si tiene un equipo distribuido (no en la oficina juntos) considere un PM / Scrum Master enfocado a tiempo completo. Hay mucha más coordinación y facilitación cuando un equipo no se sienta junto. No asuma que un PO puede hacerlo todo si el equipo no está unido.

La mejor organización para un grupo de programadores es dos.

En los detalles de su pregunta, sugiere un equipo de diez, si me da un equipo de diez, tomaría tres programadores, cambiaría un programador adicional por un probador de software y otro por un analista de requisitos. Si pudiera encontrar un gerente de proyecto que realmente administrara el proyecto y no las personas que cambiaría por uno de esos. Veamos, qué me queda, parece cinco (no muy optimista sobre ese PM), puede recuperar los otros cinco (pero quiero su dinero).

Entonces, para sacar esto del camino, ninguno de mis dos programadores querría ser este tipo:

Si uno de los diez fuera ese tipo, no haría mi corte de cinco, no solo por los pantalones.

Hay un término que he usado para siempre de la enfermedad del programador, es un diagnóstico de alto ego junto con baja autoestima. Cuanto más alto es el ego, más baja es la autoestima. No necesito a alguien cuyo ego sea más grande que la habitación y sea tan frágil como los huevos, y tiendo a pensar que el modelo Rock Star se ajusta a ese modo.

Ahora, comencé diciendo que solo necesito dos programadores, pero luego tomé tres. El tercero no funcionará en el proyecto. Esa persona debe ser altamente respetada por los otros dos (preferible) o muy irrespetada. Creo que llegaré a por qué eventualmente.

Los dos desarrolladores deben ser bastante buenos, casi geniales. Pero quizás lo más importante es que deben estar bien combinados. Deben tender a estar de acuerdo, pero no siempre están de acuerdo. Necesitan poder comunicarse, a veces sin hablar en absoluto. Mutuamente necesitan poder tomar decisiones. También deben poder tomar decisiones de forma independiente y también respetar las decisiones del otro. Necesitan poder pelear, herir sus sentimientos, pelear un poco más, enojarse y hacer pucheros. Luego, deben superarlo y volver al trabajo. Deben dar y obtener el beneficio de la duda.

Lo más importante que necesitan es confianza. Estas dos personas van a pasar mucho tiempo juntas en trincheras. Tienen la vida del otro en sus manos, necesitan a alguien con quien puedan contar.

Quisiera que el analista de requisitos sea el equivalente de una estrella de rock. No me importa qué tipo de imbécil es esta persona, los dos desarrolladores siempre los anularán si están equivocados. Pero lo que necesito, quizás más que nada, es que esta persona esté al tanto de lo que se necesita y todo eso cuando cambie. Necesitan entender el sistema por fuera, así como los desarrolladores lo entenderán por dentro.

El probador de software también debe ser excelente. No sé si hay probadores de estrellas de rock, lo dudo, las pruebas no son impulsadas por el ego, excepto tal vez en el deseo de avergonzar a los desarrolladores. La relación de trabajo con los dos desarrolladores debe ser fantástica. Todos deben respetar a todos, con una posible excepción, en mi proyecto, pero el evaluador debe ser respetado, tienen la tarea más ingrata.

En mi mundo, el probador tiene la última palabra. Un requisito no se hace hasta que dicen que se hizo o acuerdan que no se hará / no se puede hacer como se concibió originalmente. Lo mismo con cualquier error.

El tercer desarrollador tiene un solo propósito: romper los lazos con los otros dos. Cuando se llega a un punto muerto, y lo será, deben poder dirigirse al tercer desarrollador, explicar el problema y obtener una decisión. Como dije antes, ayuda si esta persona es muy respetada. Sin embargo, en caso de apuro, podría pasar con alguien a quien no respeta porque podría usar la opinión de esta persona como lo que no debe hacer. Esta persona no es un juez o un árbitro y realmente solo sirve para que los dos desarrolladores principales abran sus mentes más allá de su posición actual.

Con estas cinco personas (realmente no creo que exista PM), con las limitaciones dadas de la pregunta, podría mover el mundo, podría construir cualquier cosa. Esto no es una hipérbole, lo digo en serio, pero solo puedo creerlo porque la pregunta es muy defectuosa.

Los defectos

Realmente no mencionas cuánto dinero tengo. Tienes una vaga restricción de que tengo un presupuesto suficiente para diez desarrolladores. Ahorré dinero en cinco de esos tipos para poder usar el dinero extra para comprar herramientas. Gastaría generosamente para darle a mi equipo lo que necesiten para hacer el trabajo. También les pagaría mucho más que la tasa del mercado porque quiero mantenerlos durante toda la duración.

No mencionas cuánto tiempo tengo. La mayor parte del tiempo es en realidad dinero y ambos son un recurso finito. Si tengo para siempre puedo hacer cualquier cosa.

No mencionas cuán grande es el proyecto. Como tengo una cantidad infinita de tiempo, realmente no importa.

Dado un tiempo / presupuesto infinito, podría llevar a mis cinco personas y construir cualquier cosa, sin importar cuán complejo sea. Llegaríamos a eso eventualmente. Podríamos tomarnos nuestro tiempo y hacerlo muy, muy bien. Pero sospecho que nos aburriríamos mucho así que, al final, realmente no funcionaría.

Ahora que me he invalidado, déjame decirte cuál creo que es el núcleo de mi respuesta. El éxito en un desarrollo de software depende mucho más de las relaciones de las personas involucradas que de sus talentos individuales. No se trata necesariamente de quererse, sino de respeto. Pero querernos hace que sea más divertido. A menudo digo que no me importa si eres un imbécil mientras seas mi tipo de imbécil.

Me das mi equipo de cinco imbéciles y tomas cinco estrellas de rock y te patearé el trasero por completo. Su software será mucho más genial que el mío, pero el mío realmente funcionará y resolverá el problema de manera uniforme. La suya lo resolverá de cinco maneras diferentes, si es que lo hace. No puedo imaginar mantener a las personas juntas sin implosión, pero si pudieras, creo que el desastre resultante sería inviable.

Así que elijo personas que pueden trabajar bien juntas frente a personas que tienen más talento (suponiendo que no pueda tener ambas). Ninguno de ellos puede apestar. Eso está implícito porque no puedes respetar a alguien que apesta. Pero todos sus defectos encajan perfectamente. Somos un equipo y podemos elevarnos unos a otros más de lo que un individuo puede llegar. Podemos llegar a las estrellas.

Podrías extrapolar que si mi equipo de cinco personas es perfecto que el proyecto más grande, entonces todo lo que necesitas hacer es multiplicar esos equipos. Pero no creo que esta sea una proporción áurea. Creo que un probador para dos desarrolladores con frecuencia va a ser demasiados probadores. Algunos me dirían que estoy equivocado y que debería ser 1: 1, pero no es tan simple. El número de evaluadores para mí a menudo depende de la complejidad de la interfaz de usuario, porque así es en gran medida cómo lo prueban.

Necesitas incluso menos BA’s, podrías llegar fácilmente a muchos de ellos y no importa cuán buenos sean, sería un desastre. Cuantas más personas tenga desempeñando estos roles, comenzará a necesitar personas para administrarlos y apoyarlos. Líderes técnicos, arquitectos, administradores de sistemas, diseñadores, dba’s y quién sabe qué más. El equipo se vuelve lo suficientemente grande como para que alguien tenga que agregar las actividades.

Pero si el principal impulso subyacente para todas esas personas, sin importar cuántas, sea la confianza y el respeto, realmente creo que se puede construir cualquier cosa.

Estoy de acuerdo con John Administrar un equipo distribuido requiere más trabajo y necesitas a alguien enfocado y dedicado. El producto puede convertirse en un desastre e incluso fallar, si no tuviera a esa persona.