¿Cómo miden las empresas tecnológicas la productividad de los empleados?

Es difícil pero no imposible.

Creo que pocas respuestas dadas definitivamente tienen sentido y esos parámetros pueden ser ajustados fácilmente por los empleados, por eso es difícil.

Lo que entendí por mi experiencia es que uno no debe microgestionar a los empleados, que decir parámetros medibles debe ser tal que todos sepan claramente por qué y cómo se mide. Para cualquier empresa de TI, supongo que algunos parámetros como los siguientes tienen sentido

1. Calidad del código: ahora muchos pueden debatir sobre esto de cómo uno puede medirlo, lo mantenemos simple, usamos herramientas automatizadas como sonar junto con tuberías, después de cada confirmación nuestro servidor genera puntaje / calificación en diferentes factores como seguridad, errores / vulnerabilidad, duplicación de código, mantenibilidad, complejidad, etc., esto se publica por correo electrónico y falta de tiempo tan pronto como alguien se compromete, para que todos sepan sobre su calificación. También hacemos un seguimiento de su puntaje y lo usamos para medir su rendimiento, ya sea que esté mejorando o no. Sonar es una gran herramienta y ampliamente aceptada por muchas grandes empresas. Aunque la revisión lógica del código podría no ser posible usando el sonar, al menos el 90% de las cosas pueden ser cubiertas.
2. Comentarios continuos: esto es nuevamente lo que aprendimos de nuestra experiencia, ahora estamos trabajando en la creación de nuestro propio bot slack junto con el sitio web / panel de administración donde los empleados o gerentes pueden registrar los comentarios de cualquier empleado en alguna categoría, por ejemplo, si la construcción se retrasó un día entonces el gerente puede registrar una retroalimentación contra el equipo o la persona en cuestión que la construcción se retrasó un día y puede poner esto en la categoría llamada “entrega de tiempo”, incluso uno puede registrar retroalimentaciones positivas también. Esto hará un seguimiento de todos los comentarios en un solo lugar y puede verificarse en el momento de su evaluación o evaluación del rendimiento. La revisión por pares y 360 también se puede hacer usando el mismo sistema. También creemos que se deben medir los comentarios de los clientes después de cada entrega y que pueden desempeñar un papel más importante para mejorar aún más.
3. Metas medibles: supongo que cada empresa o gerente tiene que hablar con su equipo y establecer metas mutuamente que sean útiles para la empresa y su crecimiento individual. Sé que los empleados le darán muchas razones para no tener tiempo y todas las demás respuestas tontas, pero si realmente quieren competir con el trabajo, entonces necesitan seguir innovando y aprendiendo cosas nuevas. Los objetivos pueden ser como aprender nuevas tecnologías, marcos, hacer hackatones, etc. Todo depende de la posición de ese empleado y de lo que le falta. Estas metas tienen que ser medibles, nadie solo mantiene la meta que dice “Trataré de hablar inglés con fluidez”, esto es realmente difícil de medir, esto se puede medir fácilmente si lo ponemos como “Aprenderé inglés y manejaré toda la comunicación del cliente en un proyecto ”, esto se puede medir fácilmente en función de los comentarios del cliente. Otros objetivos podrían ser contribuir a una biblioteca de código abierto, hacer hackathon, etc.

De esta forma, los empleados también obtendrán la transparencia que la empresa desea y también mejorarán la calidad de su código, en función de los comentarios, uno puede cambiar rápidamente lo que sea que estén haciendo mal, también objetivos como hackthon pueden aumentar su confianza. Ya hemos comenzado a trabajar en ello, creo que definitivamente ayudará hasta cierto punto y traerá más transparencia en las expectativas cuando llegue el momento de la evaluación, todos estarán en la misma página en términos de rendimiento y saben qué aumento pueden obtener y por qué (Ehichbis importante).

No puedo evitar preguntarme sobre el motivo detrás del seguimiento de la productividad individual. Pero, independientemente del motivo, recuerde que al elegir una métrica, obtiene lo que mide.

• Si mide horas, las personas registrarán las horas. Si las horas son lo que agrega valor a la empresa, entonces haga un seguimiento de las horas.
• Si mide errores, las personas crearán errores. Si los errores agregan valor a la empresa, realice un seguimiento de los errores.
• Si mide líneas de código, obtendrá mucho código. Si más código significa más valor para la empresa, entonces rastree las líneas de código.
• Si mide los registros de origen, tendrá más registros. Si más registros aportan valor a la empresa, realice un seguimiento de los registros.
• Si realiza un seguimiento de las funciones, obtendrá más funciones. Si más características agregan valor a la empresa, realice un seguimiento de las características.

He cambiado un poco esto desde mi primera publicación porque, después del hecho, podría pensar en ejemplos en los que cada una de estas métricas podría agregar valor a la empresa, aunque no puedo pensar en un ejemplo en el que necesariamente agreguen valor a la cliente.

• Más horas podrían ser mejores si está facturando por hora, por ejemplo. Bueno para la empresa? Probablemente (al menos a corto plazo). Bueno para el cliente? Tal vez tal vez no.
• Encontrar y corregir errores probablemente sea bueno para la empresa, pero ¿no deberían encontrarse y repararse los errores antes de incluirlos en el código? ¿No deberían estar implementados los procesos y las prácticas de diseño para que sea más difícil crear errores en primer lugar? Tal vez, pero esa métrica no fomenta eso.
• Las líneas de código proporcionan un número agradable, generalmente creciente, para informar para mostrar la actividad, pero ¿realmente muestra progreso? Lo mismo para características y registros. ¿Más siempre es mejor? (Generalmente, no, en caso de que te lo estés preguntando).

La conclusión es que los procesos de ingeniería y desarrollo de software no se parecen a los procesos de producción de fábrica y no deben rastrearse como tales, al menos no a nivel de unidades / persona. Por lo general, hay demasiadas fuentes de variación en el proceso para que dicha contabilidad sea precisa, significativa o coherente. Incluso si asume que todos los ingenieros son igualmente talentosos y motivados, ¿todos los problemas son igualmente difíciles de resolver? ¿Todas las soluciones tienen el mismo alcance o complejidad para implementar? ¿Son todos los factores ambientales iguales (por ejemplo, recursos informáticos, recursos de especificación, criterios de aceptación, requisitos de tiempo)? ¿Se conocen todos los requisitos antes de comenzar a buscar y desarrollar una solución? Cualquiera de estos sesgaría una métrica por persona y, en mi experiencia, todos han estado presentes en diversos grados en proyectos de desarrollo de software.

También existe la forma, cuando el software de seguimiento del tiempo rastrea el tiempo automáticamente (todas las aplicaciones utilizadas, los sitios web visitados, junto con el tiempo dedicado a cada una), y clasifica todos los recursos utilizados en tres grupos: productivos, neutrales e improductivos. Como resultado, recibirá un informe automático sobre la productividad de sus empleados.

Software de seguimiento de tiempo, aplicación de seguimiento de tiempo, Mac, PC, iPhone, Android

También puede ver este video, si desea no solo medir la productividad, sino también aumentarla:

No estoy seguro de cómo las grandes empresas tecnológicas miden la productividad. Pero en la empresa de TI con la que trabajé, lo hacen por asignación de recursos humanos o del líder del proyecto a sus colegas. Si uno de los programadores no puede manejar el trabajo que otros podrían, entonces hay algo mal.

No prestamos demasiada atención a la cantidad de tiempo que el programador pasó en una tarea determinada. Debido a que ya tenemos la expectativa de que tomará más tiempo de lo normal debido a que contratamos graduados recién graduados que acaban de terminar la universidad, su velocidad de trabajo aumentará con el tiempo a medida que aumenten su experiencia.