¿La mejor manera de evaluar el desempeño de los ingenieros de software?

verificar SVN diariamente para revisar los códigos y evaluar cuántos códigos ha comprometido cada desarrollador es una buena manera. ¿Es justo y se utiliza en la industria?

La métrica propuesta es absolutamente injusta, lamentablemente se usa en algunas organizaciones y, en mi opinión personal, es una receta para el desastre.

HasaniK y Jakub ya han identificado algunas razones muy válidas de por qué es injusto. Sin embargo, hay algunas consideraciones muy serias que se deben dar a las implicaciones que pueden surgir como resultado de la introducción de esto como una métrica relacionada con el rendimiento.

El uso de LOC (y, de hecho, cualquier otro tipo de métrica lineal, por ejemplo, la corrección de errores) para evaluar la productividad o el rendimiento de los ingenieros es fundamentalmente defectuoso, esencialmente penaliza los comportamientos deseados, como la refactorización. Si desarrollé un punto de función y comprometí 350 LOC para hacerlo, entonces lo reviso, tal vez después de un poco de trabajo colaborativo con un compañero y descubro que se puede hacer en solo 150 LOC, ¿lo voy a hacer? Es poco probable que tenga un impacto en mi productividad o rendimiento percibidos.

Uno de los peores ejemplos que he visto en su lugar fue el uso de LOC y la corrección de errores como métricas de rendimiento, esto esencialmente alentó a los desarrolladores a cometer montones y montones de códigos terriblemente defectuosos y luego corregir sus propios errores. No es exactamente propicio para aumentar la velocidad y la calidad.

En mi opinión, este enfoque puede ser responsable por sí solo de crear una cultura de diseño, código y documentación de baja calidad a medida que los ingenieros se centran cada vez más en la ejecución del código en lugar del diseño sólido y sólido, la colaboración y la innovación. He visto buenos equipos de ingenieros entusiastas y de calidad convertirse en robots sin entusiasmo dedicados únicamente a entregar lo que consideran la medida esperada cada día.

No hace falta decir que dejé la organización mencionada tan pronto como fue humanamente posible y, desde entonces, me he propuesto preguntar en cada entrevista desde entonces qué marco PAR existe, ¿cómo puedo esperar que se mida mi desempeño? Si se menciona a LOC, les agradezco mucho su tiempo y, si me ofrecen la publicación, rechazo cortésmente su amable oferta.

Personalmente, he encontrado que los mejores marcos PAR para desarrolladores son en gran medida subjetivos, el uso de revisiones 360 puede ayudar a garantizar que se cumplan los comportamientos deseados, por ejemplo, comunicación, trabajo en equipo, etc. e identificar oportunidades para mejorar (asegúrese de que las revisiones 360 contienen retroalimentación basada en comportamientos demostrados y no son 'quejas'). La revisión del código y la documentación es un método genuino e imparcial para medir la calidad, la integridad y la precisión de los resultados.

verificar SVN diariamente para revisar los códigos y evaluar cuántos códigos ha comprometido cada desarrollador es una buena manera. ¿Es justo y se usa en la industria?

Definitivamente, esta no es una medida correcta para un PAR para ingenieros de software. Como también ha mencionado Jakub , el diseño lleva tiempo, a veces hay bloqueadores que impiden que el equipo de desarrollo finalice una función y realice una confirmación (p. ej., falta de disponibilidad de los servidores de desarrollo/prueba) y también en un equipo interfuncional, algunos miembros podrían estar ayudando a otro miembro. con su trabajo. La lista podría seguir..

En mi opinión, la siguiente lista es un conjunto básico de objetivos para ingenieros de software de cualquier nivel (Junior/Senior)

1. Integridad , calidad y productividad de los entregables ( código, documentación, resolución de defectos : tenga en cuenta que estos estándares y valores aceptados deben comunicarse antes del comienzo del trabajo)
2. Trabajo en equipo (cuán colaborativos y solidarios son cuando trabajan en equipo)
3. Comunicación (Correcta, Clara, Oportuna)
4. Etiqueta profesional común (puntualidad en las reuniones, cumplimiento de los límites aceptados en las políticas de asistencia/RRHH en la organización, respeto a los demás)

Además de lo anterior , para un ingeniero senior, los siguientes parámetros serán más aplicables, ya que se espera que los ingenieros senior guíen al menos a algunos otros ingenieros junior.

1. Integridad , calidad y productividad de los entregables del equipo (si es posible, si esto puede aplicarse a ingenieros de todos los niveles, en teoría, la integridad, la calidad y la productividad generales deberían mejorar, pero no he tenido la oportunidad de ver esto de primera mano)
2. Contribución al desarrollo de competencias (Formación al equipo, Tech Talks, etc.)

Cómo definir los criterios de medición para cada área resaltada arriba, lo dejaría para el liderazgo técnico respectivo.

definitivamente no es justo. Diferentes tareas requieren un enfoque diferente. Puede pasar más horas simplemente diseñando su solución en lugar de implementarla.

Mi recomendación es:

• Revisiones de código frecuentes.
• Pídale al desarrollador que revise el código para otros y mire la revisión proporcionada.
• Inspeccionar su documentación.
• Observe cómo están disfrutando del trabajo/trabajo en equipo.
• Siéntese uno a uno con frecuencia y haga preguntas sobre el proyecto. Cómo piensa sobre el proyecto. Lados positivo/negativo. Creo que todo es individual y es difícil calificar el desempeño usando herramientas y contando los registros. El enfoque personal debería decirle más.

LOC es solo un factor simple de medir cuando se trata de evaluar el desempeño de las personas que trabajan como Tech Lead/Team Lead o posiciones superiores.

Porque están haciendo más trabajo en comparación con el desarrollo (escritura de código). Por ejemplo:

1. Recopilación de requisitos.
2. Diseño de soluciones.
3. Documentación.
4. Llamadas semanales de actualización de progreso con los clientes.
5. Revise los códigos de personas jóvenes para conocer las mejores prácticas y los estándares de la empresa.
6. Revise el código para verificar que sea de buena calidad (como menciona @Clair para identificar "Si el desarrollador desarrolló un punto de función y comprometió 350 LOC para hacerlo, tal vez después de un trabajo colaborativo con personas mayores podría realizarse en solo 150 LOC").

Al evaluar a estas personas (líder técnico/líder de equipo o puestos superiores), creo que debemos considerar las áreas que señala @timeman789 .

Pero cuando se trata de desarrolladores que tienen objetivos claros y tareas claras con la ayuda de sus superiores, creo que LOC da una parte aceptable para evaluar su desempeño. Pero creo que no debería ser LOC, sino más bien Líneas de código fuente (SLOC) o Líneas de código efectivas (ELOC). Aparte de eso, los FP (Puntos Funcionales) también pueden usarse como contramedida para evaluar estos miembros.

Considerándolo todo, creo que es mejor hacer una investigación y proponer un conjunto diferente de medidas para los diferentes roles de las personas; para evaluar el desempeño de las personas que tiene su equipo o empresa.

Cualquier métrica relacionada con código como LOC, calidad de código (cubo de sonda), errores, etc. es muy mala. O bien, si encuentra algún sistema métrico que funciona en un equipo, no funcionará en un equipo diferente. Además, los desarrolladores siempre quieren piratear/descifrar las métricas de rendimiento (porque será parte de su trabajo: resolver tareas complejas).

Desde la parte tecnológica, solo puedo sugerir principios SÓLIDOS: ¿el equipo realmente escribe un buen código que sea fácil de mantener (80-90% del tiempo los desarrolladores mantienen el código)?

Además, hay un buen enfoque de google:

1. google mide el rendimiento basado en tareas educativas y de autoformación. Cada desarrollador debe elegir qué área mejorará en los próximos 6 meses. Y después de eso, el gerente / líder del equipo verificará en una reunión individual qué progreso se realizó.
2. Calcular la contribución de cada desarrollador en la mejora del proceso tecnológico. Como CI/CD, entrenamiento para un equipo y etc.

https://www.quora.com/¿Cómo-miden-las-empresas-tecnológicas-como-Google-el-rendimiento-de-sus-ingenieros-o-desarrolladores-de-software-son-medidos-por-sus- habilidades-de-codificación-productividad-comentarios-de-los-clientes-etc-qué-tipo-de-personas-probablemente-puedan-ser-ascendidas

Pero aún así, esto depende mucho del tipo de tarea. Si está trabajando como subcontratista, probablemente pueda intentar encontrar algo medible. Si trabaja en una empresa de productos con un producto de larga duración, es mejor medir la mejora a largo plazo de todo un equipo.