Tener que establecer objetivos para los desarrolladores, aunque los objetivos no funcionen [cerrado]

En general, se acepta que establecer objetivos mensurables para los desarrolladores de software no funciona , ya que demasiado enfoque en los objetivos puede llevar a comportamientos contrarios a las metas de la organización (la llamada " disfunción de medición ").

Sin embargo, en mi empresa, estamos obligados a establecer objetivos para todo el personal, y Recursos Humanos nos alienta a hacerlos SMART . En el pasado, mis compañeros gerentes de primer nivel (líderes de equipo) y yo hemos probado varios enfoques:

1. Establezca objetivos mensurables que sean adicionales al trabajo normal, como "Capacitar en tecnología X", "Crear documentación para un fragmento de código Y que nadie comprenda", etc. Cuando se trata de la evaluación anual del desempeño, califique a los desarrolladores no según los objetivos escritos, sino más bien según mi opinión sobre el valor inconmensurable de su trabajo normal, ya que eso es lo que realmente le importa a la empresa.
2. Establezca objetivos muy específicos como "días de trabajo realizados según lo registrado por el sistema de gestión de tareas", "número de errores introducidos", "número de producción emitida causada". Esto llevó a estimaciones infladas y una clasificación incorrecta de errores, con el fin de lograr mejores "puntuaciones". Curiosamente, incluso a los desarrolladores que obtuvieron puntuaciones altas en este sistema no les gustó, ya que la confianza intrínseca dentro del equipo se vio dañada y no siempre sintieron que merecían su alta posición.
3. Establezca objetivos vagos que sean variantes de "Haga bien su trabajo normal". Cuando se trata de la evaluación anual, su calificación refleja el desempeño en relación con los objetivos, pero los objetivos en sí mismos no son medibles ni alcanzables, lo cual está mal visto.

Ninguno de estos es ideal. Si ha estado en una situación similar de tener que crear objetivos significativos y medibles para los desarrolladores de software a pesar de la evidencia en contra de su efectividad, ¿qué enfoque ha funcionado mejor para usted?

Encontré preguntas relacionadas que no abordan el mismo punto:

• ¿Cuáles son algunos buenos objetivos de rendimiento para un ingeniero de software?
• Establecer objetivos de rendimiento para desarrolladores
• ¿Cuáles son los indicadores de desempeño adecuados para los programadores?
• ¿Qué es una técnica justa de medición de la productividad para programadores?
• Necesito algunos "Objetivos" profesionales para el próximo año

Actualización (18 de noviembre de 2009): Hay 10 votos a favor para mi pregunta, y las respuestas mejor calificadas solo tienen 4 votos a favor (incluido uno de mí). Creo que esto nos dice algo: tal vez Joel y los demás tienen razón, y que la sabiduría combinada de stackoverflow no puede ofrecer ningún objetivo convincente y mensurable para los desarrolladores que no se podrían jugar sin afectar negativamente el verdadero valor (inconmensurable) de su trabajo. ¡Gracias por intentarlo!

¿Qué enfoque le ha funcionado mejor?

Solo un objetivo: aprobar una inspección de código / revisión por pares, conmigo como revisor, sin que yo encuentre ningún error o tenga ninguna otra crítica, eso me hace pedirle que rehaga algo.

Notas:

• No estaba midiendo la capacidad de los nuevos empleados para terminar rápidamente y no los alenté a hacerlo: quería que la gente aprendiera a terminar bien (porque si no está bien terminado, entonces no está terminado)
• La gente aprendió lo que buscaba en una revisión de código: por lo que es una oportunidad de aprendizaje y una medida de control de calidad, y no solo un objetivo de gestión.
• Mis comentarios tendrían dos categorías:
  1. Esto es un error: debe solucionarlo antes de registrarse
  2. Como sugerencia, hubiera hecho tal y cual
• Después de un tiempo, mis revisiones del código de una persona dejarían de encontrar elementos "obligatorios" (momento en el que ya no necesitaría revisar su trabajo).

Personalmente trato de fijarme dos tipos de objetivos:

• Objetivos centrados en el negocio (por eso, después de todo, nos pagan). Por ejemplo, "completar el proyecto X antes del 1 de junio de 2009"). Estos objetivos a menudo se comparten entre varios miembros del equipo (y ellos son conscientes de ello). El equipo puede superar el objetivo introduciendo el proyecto antes o superando la funcionalidad requerida. Los individuos pueden exceder el objetivo produciendo más funcionalidad, teniendo menos errores en su contra, o entrenando y apoyando a otros miembros del equipo.

• Objetivos de crecimiento personal, por ejemplo, completar un proyecto que involucra una tecnología que el desarrollador quiere agregar a su conjunto de habilidades, comprender mejor el dominio del usuario, adquirir experiencia de liderazgo, etc.

Siento que es importante que:

• Los objetivos son INTELIGENTES
• Los objetivos están alineados con las necesidades del negocio.
• Incluyes el "trabajo normal" en los objetivos, de hecho, ¡estos son los objetivos más importantes!
• El empleado tiene alguna oportunidad de superar los objetivos que establezca.

Por último, me mantendría alejado de las métricas de software como objetivos: son demasiado fáciles de jugar y probablemente no te darán lo que necesitas. Solo usaría una métrica en la que quiero entrenar a alguien para que adopte o elimine un comportamiento en particular.

Todo esto se reduce al hecho de que la "gerencia de primer nivel", y la mayoría de la gerencia, no conoce a sus empleados. En lugar de ser parte de la planificación y el desarrollo del día a día, aparecen cosas como SMART. Si los gerentes pasaran más tiempo con los chicos que hacen el trabajo real, nada de esto sería necesario.

Personalmente, prefiero trabajar en un entorno ágil donde es obvio quién de los desarrolladores se desempeña en términos de productividad y conciencia de calidad. Un enfoque verdaderamente ágil requiere que no solo los desarrolladores, sino también los diseñadores, probadores, clientes y gerentes de producto estén incluidos en el proceso. Esto, naturalmente, conduce a mejores conocimientos desde el punto de vista de los gerentes.

Objetivos medibles que he visto hasta ahora:

• Aprobar un examen certificado
• Investiga la tecnología X y realiza una presentación al respecto.
• Número de cambios de ruptura de compilación cometidos
• Número de artículos wiki escritos sobre la gestión del conocimiento interno

¿Qué tal preguntarles directamente a sus desarrolladores si tienen algunas ideas para el desarrollo personal que luego podrían usarse para objetivos?

Tener que establecer objetivos para los desarrolladores, aunque no funcionen

Si sus desarrolladores no funcionan, ¿quizás algunos objetivos son justo lo que necesitan para darles algún incentivo? ;-)

"Asegúrese de que al menos un n% de su código sea probado por una prueba unitaria adecuada" Utilice una herramienta de cobertura para probarlo y haga que otra persona revise la calidad de la prueba.

Creo que tener objetivos muy específicos por adelantado, es decir, SMART (quizás trabajemos en el mismo lugar en realidad), parece una buena idea en la práctica, pero no es muy práctico para la mayoría de los equipos.

El problema realmente es que nuestros objetivos incrementales cambian. El negocio cambia y, como desarrolladores, debemos reaccionar y reaccionar adecuadamente y en un plazo razonable.

Considere establecer metas que se relacionen con el propósito de su equipo o grupo en la organización. Su equipo no estaría financiado si no tuviera un propósito: un propósito macro. Tenga metas colectivas que existan en todo su equipo y que se alineen con el negocio. Dele responsabilidad a la gente y haga que la gente rinda cuentas. Celebre sus éxitos y fracasos (si no fallamos a veces, es probable que no lo intentemos y eso es lo que quiere de la gente). HTH

Tenemos una serie de métricas que se recopilan a medida que los programadores trabajan, tales como:

• Número de SLOC cambiado / agregado
• Número de errores / errores inyectados en varias etapas del proceso (durante la revisión por pares, revisión posterior por pares, publicación posterior)
• Solicitudes de cambio cumplidas / rechazadas
• Documentos formales (descripciones de la versión del software, documentos de diseño, etc.)

Todos estos son tangibles que encuentro útiles en presentaciones para la gestión y el aseguramiento de la calidad del software. Pero nunca los he encontrado terriblemente útiles en evaluaciones reales del desempeño de las personas, que es lo que señalan varios de los enlaces que enumeró. He descubierto que los puntos de Joel aquí son válidos: las métricas nunca promueven una buena atmósfera de equipo.

Desafortunadamente, todos vivimos en un mundo donde otros requieren métricas (administración, control de calidad, contratistas externos, etc.). Descubrí que se requiere un acto de equilibrio, proporcionando esas métricas, pero también proporcionando evidencia de intangibles, siendo intangible lo que cada programador ha logrado que no necesariamente se rastrea. Por ejemplo, tuve un programador que pasó una gran cantidad de tiempo investigando el código heredado que nadie más quería tocar. Aunque sus métricas fueron bajas durante ese período de tiempo, ese esfuerzo fue invaluable.

La única forma que he encontrado para incluir tales cosas ha sido impulsar la creación de una categoría intangible adicional y darle el mismo peso que las otras métricas. Por lo general, esto es suficiente para cambiar la balanza de un programador en particular.

Uno de los problemas parece ser que, como división / departamento, las organizaciones de TI no tienen objetivos estratégicos medibles. Si lo hicieran, sería más fácil establecer metas para las personas.

Por ejemplo, si hubiera una iniciativa departamental para reducir la cantidad de tickets de problemas generados, entonces, podría establecer objetivos individuales basados ​​en el número de tickets relacionados con el software que cuidan.

Dado que el desarrollo de software es en gran medida una colaboración, tendría más sentido establecer metas a nivel de equipo y, luego, calificar a las personas según su contribución al equipo.

Un objetivo que me gusta es:

Solicite N revisiones positivas de su participación en un proyecto del cliente del proyecto.

Esto ayuda, ya que siempre es bueno tener comentarios positivos por escrito de los clientes (internos o externos). No es difícil de conseguir, es relevante y es una marca fácil, pero no sin sentido en la lista.

Determinar cómo alinear el desarrollo personal con los proyectos que se están realizando es un punto clave en esto, creo. Hacer que los desarrolladores se analicen a sí mismos para encontrar debilidades junto con dar retroalimentación sobre otros puede ser una forma de encontrar lo que se puede mejorar y luego encontrar una manera de medirlo. Por ejemplo, puedo encontrar que rara vez documente elementos completados y, por lo tanto, mis objetivos para el año puedo afirmar que quiero mejorar esto y que la cantidad de documentación que produzco puede ser una medida de eso. Puede funcionar o puede ser contraproducente dependiendo de cómo lo sigo realmente. Por un lado, puede haber preocupaciones válidas de que esto sea cómo mejoro mi trabajo y hago lo que puede verse como la manera correcta, mientras que una visión pasiva agresiva o infantil sería producir una montaña de documentación si no lo es.

La definición de un desarrollador eficaz es otro elemento de esto. ¿Es la persona que mejor corrige los errores? ¿Lo nuevo funciona más rápido? ¿El nuevo trabajo se completa con pruebas y documentación aunque no se haga rápidamente? ¿Qué está llamando efectivo ya que la respuesta estándar "depende" debería aclararse aquí.