Soy un líder de equipo con más de 5 desarrolladores. Tengo un desarrollador (llamémoslo A ) que es un buen programador, que escribe un código limpio y fácil de entender. Sin embargo, es algo difícil de manejar y, a veces, me pregunto si realmente tiene un bajo rendimiento o no.

1. Nuestra compañía requiere que los desarrolladores indiquen el progreso del trabajo en el rastreador de errores que utilizamos, no tanto para monitorear a los programadores sino para mantener a las partes interesadas informadas del progreso. La cuestión es que A solo actualiza el progreso de una tarea cuando se realiza (tal vez 3 semanas después de que se trabajó por primera vez) y esto hace que todos se pregunten qué está sucediendo a mediados de la semana de desarrollo. No cambiaría su hábito a pesar de los repetidos sondeos. (Está bien, los desarrolladores odian el papeleo, yo también)
2. Recientemente, de 2 a 3 meses de licencia con bastante frecuencia debido a varios eventos: o está enfermo o tiene que asistir a muchos eventos personales, etc. (Está bien, suceden cosas malas en una cadena. Es solo una coincidencia)
3. Definimos sprints o hojas de ruta para cada mes. Y al comienzo del sprint, discutiremos la cantidad de trabajo que cada uno de los desarrolladores tiene que hacer en un sprint y los desarrolladores pueden establecer la cantidad de tiempo que necesitan para cada tarea . Por lo general, no podrá completarlos todos. (Está bien, los desarrolladores regularmente pierden fechas límite no debido a su culpa).
4. Estoy basado en Singapur. No estoy seguro si eso importa. Sí, se sabe que los asiáticos son reticentes, pero ¿eso importa?

Si solo ocurren uno o dos de los eventos anteriores, no sentiré que A tiene un rendimiento inferior, pero todos suceden juntos. Así que tengo la sensación de que A tiene un rendimiento inferior y tal vez ... Dios no lo quiera, aflojando.

Esto es solo un sentimiento basado en mis años de experiencia como programador. Pero podría estar equivocado.

Es notoriamente difícil medir el trabajo de un programador, dado que no todas las dos tareas son iguales, y carece de un objetivo estándar para medir el compromiso de un programador con su empresa. Es francamente imposible saber si el programador está haciendo su trabajo o está aflojando. Todo lo que puede hacer es confiar en ellos: sí, confiar y darles autonomía es la mejor manera para que los programadores trabajen, lo sé, así que no comience una conferencia sobre por qué necesita confiar en sus programadores, gracias a todos mucho , pero si abusan de tu confianza, ¿puedes saberlo?

Salir:

Tengo una conversación directa con él sobre mi percepción sobre su desempeño. Estaba indignado cuando le sugerí que tenía la sensación de que no estaba actuando a su mejor nivel. Sintió que este era un sentimiento completamente injusto. Entonces respondí que este era mi sentimiento y no sabía si mi sentimiento era correcto o no. No quiso nada de esto y terminó la discusión de inmediato.

Antes de irse dijo que "trataría de dar más a la compañía" en un tono muy frío. Me sorprendió su reacción. Estoy seguro de que lo ofendí de alguna manera. Sin embargo, no estoy muy seguro de si eso era lo correcto para que yo fuera tan franco con él.

Mi pregunta es: ¿cómo puede saber si sus programadores tienen un rendimiento bajo? ¿Seguramente hay líderes de equipo de experiencia que saben mejor que yo sobre esto? 

Notas adicionales:

1. Odio la microgestión. Entonces, todo lo que tenemos para nuestro proceso de software es Sprint (donde las tareas se priorizan y asignan, y al final del mes, una revisión de la cantidad de trabajo realizado). Los desarrolladores requerirían actualizar las tareas a medida que avanzan todos los días.
2. No hay reunión de pie, ni nada por el estilo. Principalmente porque tenemos la libertad de trabajar desde casa y todos apreciamos esta libertad.
3. Aunque yo soy quien establece la fecha límite, los desarrolladores proporcionarán la estimación para cada tarea y yo decidiré, en base a la estimación, las tareas que van en un sprint particular. Si no pueden terminar las tareas al final del sprint, los empujaré al siguiente. Entonces, en teoría, uno solo puede hacer 1 o 2 tareas durante todo el sprint y luego empujar las 99 tareas restantes al siguiente sprint y aún así estará bien siempre que lo justifique, en forma de actualizaciones diarias del progreso del trabajo

Este debería ser un problema sorprendentemente fácil de resolver.

Tener una segunda reunión con él. Dígale que acepta que probablemente sea su percepción de la realidad la que tiene la culpa. Luego califique eso con "sin embargo, si ese es el caso, entonces debemos trabajar juntos para mejorar mi percepción". Finalmente, desafíelo a resolver ese problema, para que no se sienta microgestionado.

Esto exactamente me sucedió hace mucho tiempo. Para mí, el problema es que no me gusta la posibilidad de que alguien piense que estoy buscando crédito adicional por simplemente hacer mi trabajo. Y eso fue lo suficientemente justo, pero debe haber un ciclo de retroalimentación regular entre cualquier miembro del personal y su gerente de línea.

Si no lo hay, entonces tienes estos problemas.

Regular, planificado, 1: 1 es una gran idea. Y, como la gente ha señalado, las standups no necesitan ser ortogonales para trabajar desde casa. Pero deben incluir las tres preguntas: ¿Qué hiciste ayer? ¿Qué planeas hacer hoy? Y el que la mayoría de la gente olvida ... ¿Qué (si acaso) te retiene?

Dicho esto, debes tratar de desalentar situaciones en las que los miembros del equipo nunca trabajan juntos. He trabajado en esa situación antes y generó desconfianza dentro del equipo y fuera de él. Tenga un día normal en el que todos vengan a la oficina. Tenga una reunión regular donde las personas puedan expresar algunas ideas sobre cómo mejorar los procesos o lo que sea.

No lo convierta en un evento de informes en línea. Haz que sea una oportunidad para hablar. Te sorprenderá lo que aprendas. Si es posible, convierta eso en un evento social, tome un par de copas en el tiempo de trabajo como ejercicio de unión.

Aquí hay muchos consejos excelentes, y no quiero quitarles nada, así que publico esto como una respuesta separada.

Primero, es evidente para mí (y aparentemente para otros) que no ha descubierto la raíz del problema . Estás mirando un síntoma y tratando de curarlo. Debe descubrir qué está causando tanta fricción entre usted y este desarrollador. Tal vez estás siendo demasiado autoritario (mi Product Owner recientemente se describió a sí misma como teniendo "Poder Infinito" sobre un proyecto y eso fue ofensivo para mí, a pesar de que se rió cuando lo dijo). Quizás esté teniendo problemas familiares graves (explicaría todo el tiempo sin trabajo). Aquí hay un problema raíz, y hasta que no lo encuentre, no se solucionará.

¡Buena atrapada!

Si su desempeño podría ser mejor, es genial que hayas determinado eso. Sin embargo, recuerde que si su mal desempeño sigue siendo un buen desempeño en comparación, entonces debe pisar con cuidado para evitar perder un buen desarrollador. Es difícil encontrar buenos desarrolladores, y los buenos desarrolladores requieren un conjunto de cosas muy específico. Quizás eche un vistazo a la prueba de Joel para ver si se satisfacen sus necesidades.

Encuentra la fuente del problema

Si no está contento con algo relacionado con el trabajo que está haciendo, entonces solo puede solucionarlo determinando la fuente del problema. Déjame ser claro, dijiste que tu programador escribió un buen código. Eso significa que le encanta programar. Es más que evidente que está frustrado en el trabajo (según su descripción de la reunión), y probablemente tenga razón en que su desempeño está por debajo de donde debería estar, pero no asuma . Recuerde que muchos programadores simplemente no tienen habilidades sociales.

No eres perfecto tampoco

Recuerda que a veces vas a tener conflictos de personalidad, especialmente con introvertidos . Si esto resulta ser un conflicto de personalidad, considere qué tan lejos está dispuesto a llegar para obtener un aumento en el rendimiento (ver 1)

Todo eso dicho

Escribí una publicación de blog sobre Managing Programmers. Creo que deberías leerlo.

http://deltreey.blogspot.com/2012/07/managing-programmers.html

No puedo enfatizar lo suficiente la última parte de esa publicación.

Si sus desarrolladores son buenos, quieren codificar.

Su programador, incluso si está aflojando, no quiere estar aflojando. Debe encontrar la raíz de este problema, y ​​puede resultar ser algo que simplemente no se puede solucionar y debe dejarlo ir, pero sea lo que sea, no puede tomar una decisión informada sin determinarlo.

Cuando sienta que alguien es "algo difícil de manejar" como usted describe, para comprender mejor cómo se desempeña uno y si hay problemas (objetivos o subjetivos) que afectan la productividad de los miembros del equipo de desarrollo, considere establecer una práctica de 1: 1 regular con su miembros del equipo, como se presenta en un excelente artículo The Update, The Vent y The Disaster :

... No estoy sugiriendo que cada 1: 1 sea un asunto tortuoso para descubrir desastres emergentes profundamente ocultos, pero sí desea crear un lugar semanal donde la insatisfacción pueda aparecer en silencio. Un 1: 1 es su oportunidad de realizar un mantenimiento preventivo semanal al tiempo que comprende la salud de su equipo.

... El sonido que rodea el régimen exitoso de 1: 1 es el silencio. Toda la escucha, las preguntas y la discusión que ocurren durante un 1: 1 es mantenimiento preventivo gerencial. Verá cuándo el interés en un proyecto comienza a disminuir y tomar medidas antes de que se convierta en insatisfacción laboral. Escucharás sobre la tensión entre dos empleados y moderarás una discusión antes de que se convierta en un grito en una reunión. Su recompensa por una cultura de saludable 1: 1 es una clara falta de drama .

_{Un punto muy fuerte del artículo mencionado es que es autónomo , en el sentido de que además de explicar los beneficios, también proporciona un conjunto de recomendaciones prácticas que básicamente le permiten a uno comenzar a practicar 1: 1 regular sin buscar otras fuentes (aunque busca información adicional no hará daño, ya sabes).}

Obviamente, hay un problema de comunicación importante aquí. Puede que esté haciendo un trabajo fantástico, pero si tienes la sensación de que no sabes lo que está haciendo, entonces eso es un problema. Y si no sabes lo que está haciendo, entonces sus compañeros de trabajo probablemente tampoco. Esto puede causar problemas cuando registra su código de dos semanas. Especialmente si había alguien trabajando en un área similar.

Siempre puede sugerir que se registre / proporcione actualizaciones más regularmente para minimizar este tipo de conflictos. Esto podría permitirle expresar su solicitud en términos de ayudar al equipo en lugar de "No sé lo que está haciendo".

Sé que las standups tienen mucho odio, pero en realidad no tiene que celebrarse en la misma habitación. Una llamada rápida o una actualización grupal de Skype una vez al día es muy rápida y mantiene a todos en la misma página.

Actualmente estoy trabajando desde la India con un equipo en Irlanda y no puedo imaginar no estar en comunicación con cada uno de ellos a diario y sé aproximadamente a qué se dedican o puedo averiguarlo rápidamente.

Inútil

Las actualizaciones diarias de estado no tienen sentido. Hacer que la gente informe "hoy estoy 2.5% completo", "hoy estoy 3.74% completo" es ridículo.

No proporciona ningún valor a las partes interesadas y molesta a las personas que realizan el trabajo.

Déjelos a su trabajo, sin ser molestados.

Infundado

¿Sobre qué base supone que el desarrollador A está 'con bajo rendimiento'? Si su trabajo se realiza a tiempo, eso debería ser lo suficientemente bueno.

Dices que odias la microgestión, pero lo que has descrito es exactamente eso.

Nuestra compañía requiere que los desarrolladores indiquen el progreso del trabajo en el rastreador de errores que utilizamos, no tanto para monitorear a los programadores sino para mantener a las partes interesadas informadas del progreso. ... Los desarrolladores requerirían actualizar las tareas a medida que avanzan todos los días.

Esto no tiene sentido (ver arriba) sin sentido. Su equipo no está volcando hamburguesas, están creando soluciones técnicas. El progreso no es lineal, ni se mide fácilmente ni se estima. Incluso si lo fuera, tales mediciones o estimaciones diarias no tienen valor.

Peligroso

Vuelva a examinar la base de su 'sensación' de que el desarrollador A está 'con un rendimiento inferior'. ¿Crees que él / ella podría hacerlo mejor, pero sobre la base de qué evidencia?

Infeliz! = Bajo rendimiento

Continúe como se describe, y en algún momento, el desarrollador A probablemente decidirá que él / ella es poco apreciado, ha dado suficiente a la compañía y encontrará otra compañía. Exprimir el último 0.01% del esfuerzo de los empleados es mucho menos importante que retenerlos a largo plazo.

Los desarrolladores pueden odiar el esfuerzo de documentar lo que hacen y actualizar los estados, pero eso es parte de ser un desarrollador profesional. Te sugiero que intentes señalarle que sus actualizaciones tardías de tu registro de problemas están causando una percepción negativa innecesaria de su trabajo. Si no ve que su falta de comunicación es un problema de rendimiento, bueno, usted es el líder de su equipo; dile que lo es.

En cuanto a la estimación, ese es un problema clásico. Recomiendo leer "Estimación de software: desmitificar el arte negro" de Steve McConnell. En este caso, da la impresión de que la mayoría de sus desarrolladores subestiman. Esto es, curiosamente, normal y rara vez se aborda. Sugeriría que tiene un problema con el proceso de estimación en sí, en lugar de este individuo.

Intente "cerrar el ciclo" de estimación-medida-revisión y mejore. Luego, si sus desarrolladores llegan a tiempo más regularmente y este individuo no lo es, puede considerar qué hacer con él.

Finalmente, tenga la reunión de pie. Incluso si es por mensaje instantáneo. Todo lo que quiere es que todos sepan "lo que hice, lo que estoy haciendo hoy, cualquier problema". Y si hay problemas, desconéctelos para discutirlos más tarde. Eso es lo que he hecho antes, y fue exitoso para ese equipo.

Lo primero, ¿por qué tus carreras son tan largas? Los sprints nunca deben exceder las dos semanas. Creo que la mayoría de tu problema yace ahí. Te recomendaría que acortes el tiempo de sprint a modo de prueba y luego vuelvas a analizar tu pregunta.

¿Qué pasa con el código de entrada? ¿Comprueba su código todo el tiempo? Personalmente, creo que los programadores no son realmente gerentes de administración y cuanto más intentes administrar, más se sentirán frustrados. De hecho, odio hacer esas tareas de actualización y probablemente es por eso que PM's y Leads están ahí. Pero al mismo tiempo, proporciono un estado durante las reuniones de scrum o cada vez que nos reunimos. Ahora, cuando asigna una tarea, ¿se comprometen con una línea de tiempo o es usted quien les asigna la línea de tiempo?

Por lo tanto, la única forma en que podría saber si alguien se está desempeñando mal es mapeando la línea de tiempo comprometida al% del trabajo realizado. Ahora, por supuesto, si alguien dice que le tomará dos días escribir un método que sume dos números, sabrá que hay un problema, por lo que la línea de tiempo debería ser algo realista y acordado por ambas partes.

Tómelo de esta manera: si puede escribir un fragmento de código en una hora, dele una hora + un poco de búfer. Si él te lo entrega en ese tiempo, creo que ustedes están bien. Si no lo está, entonces pregúntele y luego depende de usted decidir si está proporcionando una explicación razonable o no.

Una cosa que puede hacer es integrar algo como XPlanner con la herramienta de versiones.

No creo que la profesión de programación sea inherentemente diferente de otras profesiones cuando se trata de identificar a alguien que está aflojando. Puede que tenga que ir con su intestino.

Personalmente, creo que es extraño que A se niegue a proporcionar actualizaciones durante semanas a la vez. Soy un programador que trabaja desde casa, y hay un contrato implícito entre mi empleador y yo que necesito para proporcionar actualizaciones diarias sobre mi progreso. Estas no son actualizaciones "oficiales", es solo un breve correo electrónico o mensajería instantánea que le permite saber qué está pasando con el software que me pagan para crear. La actualización tarda menos de un minuto o dos en escribirse y nos ofrece un cierre a los dos. Para las correcciones de errores, marco el ticket como resuelto en nuestro rastreador de errores al final del día. Estos no son procedimientos difíciles para mí, aunque disfruto de un ambiente de trabajo relajado con muy poco papeleo.

Incluso las actualizaciones casuales serían apreciadas viniendo de él, estoy seguro. Suenas muy, muy indulgente en tu publicación. Si sospechas que se está aflojando por un período prolongado de tiempo, no necesitas otra excusa para abordarlo con él.

Las paradas diarias, incluso a través de Skype o en una sala de chat, son la solución, pero no si lo tratas como una actualización para las partes interesadas. Cuando una vez al día todo el equipo simplemente se registra para decir en qué han estado trabajando, en qué desafíos se enfrentan y qué planean hacer a continuación, obtienen varias victorias:

• Ya sea que esté perdiendo el tiempo por buenas o malas razones, que algo está tomando demasiado tiempo será más transparente, alentando a sus desarrolladores a pedir ayuda cuando la necesiten y no exagerar en investigaciones que probablemente no tuvieron que suceder. o resolver un problema para el desafío cuando las aportaciones del resto del equipo los ayudarían a eliminarlo mucho más rápido.

• Usted, como gerente, puede ver dónde las personas se encuentran con obstáculos más frecuentemente, lo que lo ayuda a estimar mejor y posiblemente resolver problemas fundamentales que están desperdiciando tiempo / dinero.

• En mi opinión, realmente ayuda al equipo a aprender a comprometerse mejor con las estimaciones cuando pueden ver cuánto tiempo le lleva a todo el mundo hacer incluso cosas relativamente sencillas a veces.

• A menudo se le recordarán cosas que deben comunicarse en términos de volver a priorizar cuando los miembros de su equipo le digan qué planean hacer a continuación.

Así que olvídate del '% de completado'. Simplemente haga el proceso para hacer que todos sean honestos consigo mismos tanto como con todos los demás, haciendo estimaciones mejores / más confiables a medida que adquieren más experiencia en ello, y dando a las personas un poco más de motivación para tener un progreso para informar sin que se convierta en una mente -Numerable ejercicio de poner un número en algo que realmente no puedes.

Parece que la alta gerencia entiende que los plazos no siempre se cumplen. Hacer standups diarios te dará más munición en ese frente porque tendrás ideas mucho más específicas sobre por qué no están siendo golpeados.

Y no los hagas a primera vista. Siempre un error de la OMI. Las personas necesitan tiempo para hundir sus dientes en el problema antes de que puedan informar de manera más confiable sobre cuáles son todos los problemas, en mi opinión.

Las posiciones rápidas que se centran más en la comunicación que en la rendición de cuentas, y simplemente en establecer objetivos, más que nada son lo que hace que el trabajo ágil funcione en mi opinión. El resto podría tomarlo o dejarlo, especialmente Scrum, que he llegado a ver como aceite de serpiente para ejecutivos / partes interesadas.

Bajo rendimiento?

La intensidad disminuye y fluye durante la carrera de una persona. Si vale más de lo que cuesta, hable con él e intente facilitar su trabajo. O bien, comience a buscar un reemplazo.

Comunicación

No confíes en las reuniones semanales. La mayoría de las personas no van a hacer una lluvia de ideas completa. Programe más 1: 1s. Pregúnteles cómo van las cosas, qué puede hacer mejor y qué siente que pueden hacer mejor. A veces, no habrá nada de qué hablar, pero está bien. Al tener más 1: 1, aumenta la probabilidad de que recuerden mencionar algo.

Tener un medio de comunicación más persistente.

Puede obtener más información de las personas si no lo hace sentir como una tarea extra. Si todos son remotos, pídales que usen un programa de chat con capacidades de registro como Hipchat o IRC. Tener un medio de comunicación más persistente anima a las personas a hablar más. Dirija con el ejemplo y hable con frecuencia, para alentar a otros a hacer lo mismo. Al menos una vez al día, haga que la gente diga dónde están con sus proyectos. A veces, solo mirando el chat, puede tener una idea de cómo están progresando las cosas.

Fuente de control

Haga que todos revisen su código diariamente. Si está usando git, pídales que ingresen a su propia sucursal en el repositorio de la compañía. Al mirar los commits, puedes saber cómo les va.

Separar los medios de los extremos.

¿Los interesados ​​quieren ser actualizados? Trate con las partes interesadas usted mismo. Parte de su trabajo como gerente es ser el paraguas de mierda, para que sus codificadores puedan concentrarse en su trabajo. Mire a través de los registros de chat y las confirmaciones, luego escriba un resumen sobre cómo van las cosas.

Estas son mis sugerencias:

1. Innovación: Imaginación y creatividad utilizadas para reducir costos y mejorar la situación actual.

2. Corporación: disposición para ayudar a otros a lograr sus objetivos

3. Iniciativa: Intentar trabajos y tareas no rutinarias.

4. Asistencia: Ausencias o tardanzas, debajo de los estándares.

5. Alerta: capacidad de comprender rápidamente nueva información y situaciones

6. Precisión y calidad: revisiones de código, entrega a tiempo, tasa de emisión).