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 un poco difícil de manejar y, a veces, me pregunto si realmente tiene un bajo rendimiento o no.
- Nuestra empresa requiere que los desarrolladores indiquen el progreso del trabajo en el rastreador de errores que utilizamos, no tanto como para monitorear a los programadores sino para mantener a los interesados informados del progreso. La cuestión es que A solo actualiza el progreso de una tarea cuando se realiza (quizás 3 semanas después de que se trabaje por primera vez) y esto hace que todos se pregunten qué está pasando en la mitad 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)
- Los últimos 2 o 3 meses que estuvo de permiso con frecuencia debido a varios eventos, ya sea que esté enfermo, o tienen que asistir a muchos eventos personales, etc. (Está bien, suceden cosas malas en una cadena. Es solo una coincidencia )
- Definimos sprints o planes de trabajo 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 . Normalmente no podrá completarlas todas. (Está bien, a los desarrolladores les faltan fechas límite no debido a su culpa).
- Estoy basado en Singapur. No estoy seguro si eso importa. Sí, se sabe que los asiáticos son reticentes, pero ¿eso importa?
Si solo ocurre uno o dos de los eventos anteriores, no sentiré que A tiene un bajo rendimiento, pero todos ocurren juntos. Así que tengo la sensación de que A tiene un bajo rendimiento y tal vez ... Dios no lo quiera ... aflojándose.
Este 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 aflojándose. Todo lo que puede hacer es confiar en ellos: sí, confiar y darles autonomía es la mejor manera de que los programadores trabajen, lo sé, así que no empiece una conferencia sobre por qué necesita confiar en sus programadores. muchas gracias , pero si abusan de tu confianza, ¿puedes saberlo?
Resultado:
He hablado directamente con él sobre mi percepción sobre su desempeño. Estaba indignado cuando 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 ese era mi sentimiento y que no sabía si mi sentimiento era correcto o no. Él no quiso nada de esto y terminó la discusión inmediatamente.
Antes de irse, dijo que "intentaría 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 seguro de si eso era lo correcto para ser tan franco con él.
Mi pregunta es: ¿Cómo puede saber si los programadores tienen un bajo rendimiento? Seguramente hay líderes de equipos de experiencia que saben mejor que yo sobre esto.
Notas adicionales:
- Odio la microgestión. Así que 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 necesitarían actualizar las tareas a medida que avanzan todos los días.
- No hay una reunión de pie, ni nada por el estilo. Principalmente porque tenemos la libertad de trabajar desde casa y todos apreciamos esta libertad.
- Aunque soy yo quien establece el plazo, pero los desarrolladores proporcionarán la estimación para cada tarea y decidiré, en función de la estimación, las tareas que entran en un sprint en particular. Si no pueden terminar las tareas al final del sprint, las empujaré a la siguiente. Por lo tanto, teóricamente, solo se pueden hacer 1 o 2 tareas durante todo el sprint y luego pasar las 99 tareas restantes al próximo sprint y aún así estará bien siempre que lo justifique: en forma de actualizaciones diarias del progreso del trabajo