Mi equipo de 4 desarrolladores experimentados trabaja en una gran aplicación modular de Windows (aproximadamente 200 KLoC). Me he centrado en la base de código central desde el comienzo del proyecto (hace 3 años) y gradualmente cambié a una posición de desarrollador semi-líder, aunque no soy el gerente del equipo.
Nuestra iteración actual es una actualización de la interfaz de usuario de alta prioridad solicitada por la administración superior, que involucra aproximadamente 15 cambios en la base de código central. Cuando el gerente me preguntó, calculé que cada uno de los 15 cambios tomaría menos de cuatro horas en completarse , un total de menos de 7 días hábiles. Luego me ofrecí para realizar el trabajo. En cambio, el gerente decidió repartir las 15 tareas a los cuatro desarrolladores.
En los tres días desde que comenzamos a trabajar, he observado dos cosas:
Los otros miembros del equipo sin experiencia completaron aproximadamente 1 o menos tarea cada uno.
La Ley de Brook en acción: pasé aproximadamente la mitad de mi tiempo brindándoles asistencia (intentando entrenarlos en el uso de los componentes). Como resultado, solo terminé 2 tareas yo mismo, en lugar de las 5 o 6 esperadas.
Me acerqué a mi gerente con la preocupación de que llegamos tarde y nuevamente sugerí que completara las tareas restantes. Mi solicitud fue amablemente rechazada, y las razones indicadas para dividir la carga de manera uniforme fueron dobles:
- Limite el factor camión / autobús : aumentar a otros desarrolladores en estas habilidades ahora, para que en el futuro cualquier trabajo se pueda realizar a cualquiera, no solo a mí.
- Para eliminar un "cuello de botella" (yo) y hacer el trabajo más rápido.
Para ser claros, no tengo problemas con: a) invertir el tiempo enseñando, b) personas que tocan mi código, o c) seguridad laboral. De hecho, le sugiero regularmente al líder del equipo que entrene a otros desarrolladores en ciertos aspectos de la base de código central para reducir el riesgo.
En esta iteración también tenemos una gran colección de correcciones de errores de alta prioridad dirigidas, por lo que parece que se podría hacer más progreso si la carga de trabajo se redistribuyera.
En Mythical-Man-Month, Brooks 'sugiere un " Equipo Quirúrgico " donde cada equipo se compone de un líder + sub-líder (el gerente y yo), y algunos roles menores. Siento como si naturalmente estuviéramos cayendo en esta organización, pero mi gerente está trabajando en contra de ella. Siento que el factor del bus ya está solucionado (el administrador está bien versado en el código central), y que el cuello de botella en realidad no existe (involucrar a más desarrolladores no hará que el trabajo vaya más rápido). Creo que, a este respecto, un equipo quirúrgico es algo bueno.
Estos son mis sentimientos, pero no soy un gerente experimentado, ni hemos tenido que lidiar con el factor del autobús (tocar madera). ¿Brooks tenía razón? ¿Has trabajado en un "equipo quirúrgico" donde el factor del autobús entró en juego? ¿Existen mejores técnicas para gestionar la experiencia de distribución?
Preguntas similares:
fuente
Respuestas:
En realidad, diría que está siguiendo el modelo de "equipo quirúrgico". ¡Suerte!
Parte del punto de dicho modelo es que los miembros del equipo inferior tienen un rol de asistente. Cuando el equipo no está realizando una cirugía cardíaca, entonces está bien moverse más despacio y darles la oportunidad de practicar algunas de sus habilidades, o de entrenar en responsabilidades.
El trabajo del cirujano es examinar y administrar su equipo buscando puntos débiles y resolviéndolos, además de ser el principal desarrollador. No puede hacer que un no cirujano (gerente de negocios) haga esto, porque no entienden las habilidades requeridas, algo así como un aprendiz de un maestro artesano.
Entonces, el gerente está aprovechando esta oportunidad para trabajar en uno de sus otros objetivos. Si durante el transcurso de la misma, se revela algún defecto en el equipo, puede solucionarlo antes de que se convierta en un problema. Digamos, contratando a otro desarrollador.
O, los juniors pueden cometer un error. Este es el momento perfecto para que lo hagan, ya que tienen a alguien vigilando por encima del hombro. Oscar Wilde dijo
Si estos jóvenes nunca tienen la oportunidad de cometer errores, nunca mejorarán. No solo robará a su equipo de futuros desarrolladores experimentados, sino que, en cierto sentido, les robará una oportunidad que deberían haber tenido.
fuente
Nuestra empresa solía funcionar como usted sugiere. Solo tuvimos dos personas que entendieron una parte crítica del código. Cada vez que surge una tarea en esa parte del código, en lugar de pasar algunas semanas poniendo a alguien más al día, la tarea se les asignará porque pueden completarla en un par de días. Esto realmente funcionó bastante bien por un tiempo.
Lo que sucedió es que finalmente su plato se llenó tanto que a pesar de que podrían terminar una tarea en 2 días, les llevaría semanas pasar a la parte superior de su lista. Los gerentes tendrían feroces batallas verbales sobre cuya tarea era más urgente. Las tareas dependientes urgentes quedarían sin hacer.
Finalmente, los gerentes se cansaron de esperar y comenzaron a capacitar a sus propios equipos. Sí, fue mucho más lento por un tiempo, pero ahora nuestro rendimiento es mucho mejor.
Es posible que ahora esté en esa primera fase donde puede manejar el trabajo, pero no tiene forma de predecir cuándo pasará a la segunda fase. Aquí hay una pista: siempre ocurre en el momento más inconveniente posible. Su gerente tiene razón al recibir el golpe cuando todavía tiene algo de espacio para respirar.
Sí, es frustrante ver a alguien luchar con algo que usted podría hacer mucho más rápida y fácilmente. Intenta criar a un niño de dos años en algún momento. Lo haces porque ayuda a todo el equipo a mejorar. El trabajo de su gerente es preocuparse por el horario. Si está preocupado por los errores de alta prioridad que se deshacen, desafíese a sí mismo para ver qué tan rápido puede solucionarlos.
fuente
Puede que ahora no seas un cuello de botella, pero eventualmente lo serás si continúas haciendo todo el trabajo tú mismo. Su gerente se da cuenta de que es lo suficientemente importante para que aprenda a delegar para arriesgarse a que su proyecto llegue tarde: confíe en él. Una vez que aprenda a dejar ir, sus juniors comenzarán a aprender y producirán mucho más bajo su guía.
fuente
Está aplicando una restricción que puede no estar presente o ser tan significativa en el grado que cree que es. Específicamente, le preocupa el tiempo hasta la finalización. Su gerente, por otro lado, no parece preocupado por las limitaciones de tiempo percibidas.
Si toma el tiempo de entrega de su pregunta, rápidamente comenzará a preguntarse por qué está haciendo la pregunta en primer lugar.
Eso no quiere decir que el tiempo siempre esté disponible, y usted indicó que esta es una solicitud de alta prioridad de la alta dirección. Pero no está al tanto de todas las conversaciones que su jefe ha tenido con ellos. Es posible que haya negociado por más tiempo para que usted pase ese tiempo entrenando a los otros miembros del equipo.
Y si bien cree que el factor del bus ya se ha abordado, su jefe puede estar atenta a la próxima solicitud que se presentará en el futuro y que no encajará fácilmente en 7 días de trabajo por parte de uno de sus desarrolladores estrella. Es mucho más seguro entrenar al equipo en una iteración más pequeña donde la magnitud objetiva del riesgo es mucho menor.
He sido un cuello de botella crítico antes; y sinceramente, no es un lugar agradable para estar. En mi caso, el vicepresidente de TI y yo hablamos y se nos ocurrió un plan para solucionar el problema de forma permanente. Me dolió, pero me dolió mucho menos que si hubiera sido transportado en camión.
Es fácil entrar en la mentalidad de todo lo que necesita ser eliminado lo más rápido posible. Un buen gerente detecta las raras oportunidades en las que un pequeño retraso (para capacitación / educación cruzada) puede pagar dividendos significativos más adelante.
fuente