Estoy trabajando para una empresa de consultoría de TI. Mi empleador me emplea para trabajar para su cliente en una posición de líder de equipo.
En mi equipo hay un miembro del equipo ("A") que me reporta. Trabaja para un empleador diferente. El cliente subcontrató el desarrollo de la interfaz específica al empleador de A y A está liderando el desarrollo y la entrega de esa interfaz que se utiliza como interfaz de usuario web para la comunicación del servicio web. El cliente ha posicionado el papel principal para toda la aplicación web. A está liderando a otro miembro que trabaja desde el extranjero (India).
Se le asignó trabajo hace dos semanas y no hay progreso sustancial de su equipo en ese trabajo. Solo nos queda una semana más para completar la pieza, de lo contrario, esta pieza se convertirá en un cuello de botella para otros equipos y causará retrasos en la entrega de mi parte.
Cuando se asignó, como él también es un líder, le di la dirección y luego lo dejé. En la primera semana, sin embargo, no hubo progreso. Mi gerente me alertó sobre esta falta de progreso y ya habló sobre los retrasos y las razones de su parte y me pidió que me enfocara especialmente en este líder y su equipo. Me doy cuenta de que mi gerente no confía en él y siente que este tipo no está haciendo su trabajo correctamente y no está contribuyendo.
En la segunda semana, observé de cerca a A y su trabajo. A continuación están mis observaciones.
Al final de la segunda semana, comencé a tener la misma sensación de que él no estaba contribuyendo mucho y simplemente delegando trabajo a su miembro del equipo en el extranjero y luego enviándome los resultados. He discutido esto con mi gerente. Mi gerente me sugirió que lo manejara de cerca.
¿Cómo puedo hacer esto con gracia sin dar lugar a sentimientos negativos en el equipo?
Parece claro que su equipo necesita una mejor metodología de desarrollo. Sin embargo, es poco probable que la microgestión le proporcione los resultados que desea. Las personas inteligentes (que generalmente son los desarrolladores) odian ser microadministrados y pueden pelear contigo en cada paso del camino.
Sugeriría tomar prestada una página (o dos) de Scrum/prácticas de desarrollo ágil. En particular, hay al menos un par de cosas que parecen ayudar en su situación:
Comience a realizar reuniones diarias de pie con su equipo. Manténgalos relativamente temprano (por ejemplo, a las 9:30 a. m. si la gente suele llegar alrededor de las 9:00) y manténgalos rápidos y enfocados en el tema. Cada miembro del equipo puede decir 1) en qué trabajaron/lograron durante el día anterior, 2) en qué trabajarán hoy y 3) si hay algún obstáculo que les impida realizar sus tareas. Esto no debería tomar más de 10 a 15 minutos cada día, y llevar a cabo estas reuniones le permitirá ver que el progreso se está retrasando antes de que haya transcurrido una semana completa. Y le darán más visibilidad sobre exactamente por qué se está retrasando el progreso.
Haga que todas las partes interesadas/"cerdos" asistan a todas las reuniones relacionadas con el negocio/requisitos. No es suficiente apropiado traer solo al líder del equipo; él no es el único con un interés creado en el proyecto. Y no solo por los problemas que ha resaltado, sino porque cuantos más desarrolladores traiga a estas discusiones, es más probable que 1) obtenga estimaciones precisas sobre el alcance de cada requisito y 2) detecte cualquier problema o trampa en los requisitos antes de que se conviertan en problemas graves. Por supuesto, también resuelve el problema del líder del equipo que no transmite los requisitos al equipo.
En general, también pareces estar descargando cosas sobre el líder del equipo que deberías usar herramientas automatizadas y otros procesos para tratar.
Por ejemplo, ¿por qué es él responsable de revisar personalmente todos los entregables (por lo que supongo que quiere decir "código fuente")? ¿Por qué no hacer que su sistema de control de versiones envíe un correo electrónico de revisión de código automatizado cada vez que se envíe un cambio a todo el equipo y hacer que todo el equipo sea responsable de la revisión y la calidad del código?
¿Y por qué no hay una cartera de proyectos u otra construcción a la que puedan acceder todos los miembros del equipo y que contenga los casos de uso relevantes en un formato claro y fácil de entender? Espera que el líder del equipo entienda, recuerde y comunique todo esto, además de todo lo demás que está tratando de hacer (y si tuviera un depósito central para esta información, tendría una refutación fácil para el equipo). comentario del cliente potencial "¿qué escenarios comerciales?"). Así que realmente solo tienes que culparte a ti mismo si las cosas comienzan a quedarse en el camino. Un cerebro humano es una de las peores soluciones para el problema de almacenar grandes cantidades de información, con precisión, durante mucho tiempo.
¿Y por qué el equipo no tiene una definición clara de "hecho" que incluya "no se realiza ninguna tarea hasta que cualquier código relacionado esté cubierto por la unidad/web/integración/cualquier prueba"?
Entonces, lo que creo que tiene es una serie de problemas de proceso, posiblemente exacerbados por algunas malas decisiones de gestión (poner todo en manos del líder del equipo, no incluir a todo el equipo en las reuniones relevantes para el proyecto, etc.). Es poco probable que una gestión más deficiente, en forma de microgestión del líder del equipo, resuelva el problema. En su lugar, arregle los problemas del proceso.
Si usted es un líder de equipo o un gerente y no quiere parecer el malo cuando sea necesario, entonces probablemente esté fuera de lugar como líder de equipo o gerente. Repasemos lo que está en juego: si no hace su trabajo, que es transferir el conocimiento a su subordinado en tiempo y forma, y asegurarse de que las tareas asignadas se completen por todos los medios necesarios, un plazo clave está a punto de cumplirse. destrozado: no es bueno para su organización, y tendrá un alto perfil en la organización, será el chivo expiatorio: no es bueno para usted.
Su gerente le asignó la tarea de supervisar a su colega, lo que en este caso significa que su colega entrega los entregables de una manera aceptable para usted. Es su prerrogativa rechazar aquellos de sus entregables que no estén en condiciones aceptables y escalar el problema de su falta de cooperación a su gerente. Le sugiero que haga un uso agresivo de esta prerrogativa, porque cualquier trabajo que él no haga terminará en su regazo. Sin tiempo de sobra.
Aclare a su colega lo que se supone que debe saber. Si no lo sabe, déjele absolutamente claro que lo que sabe o no sabe sobre lo que se supone que debe saber es su problema, no el suyo. Que no te importa cómo y cuándo lo aprende mientras lo sepa, y lo sepa y use lo que sabe en el momento oportuno.
Aclare a su colega lo que se supone que debe hacer. Si se supone que debe probar contra los escenarios comerciales, entonces eso es lo que se supone que debe hacer. Déjale en claro que rechazar la responsabilidad hacia ti NO es una opción.
La gestión es una combinación de suelto y apretado. Quieres estar suelto con las cosas que no importan tanto. Quieres ser estricto con las cosas que importan, y realmente estricto con las cosas que realmente importan. Lo que realmente importa es que la ventana de tiempo se esté cerrando rápidamente y que su colega entregue lo que se supone que debe entregar antes de que se cierre la ventana de tiempo. Lamento decirlo, pero tienes que romper ese marco de referencia cómodo/conveniente en el que está operando y encender una hoguera debajo de su trasero.
Comentario de seguimiento de @HLGEM "Dado que este tipo trabaja para un empleador diferente, me aseguraría de que su jefe en su empleador esté copiado en los correos electrónicos que discuten problemas de rendimiento".
aroth
aroth
babú
estrellasplusplus
babú
Remojar