evaluation - significado - objetivos smart ejemplos de un producto

Tener que establecer objetivos para los desarrolladores, aunque los objetivos no funcionen (11)

En general, se acepta que establecer objetivos medibles para los desarrolladores de software no funciona , ya que centrarse demasiado en los objetivos puede llevar a un comportamiento contrario a los objetivos 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 los recursos humanos los alientan a hacerlos SMART . En el pasado, mis compañeros gerentes de primer nivel (líderes del equipo) y yo hemos intentado una serie de enfoques:

Establezca objetivos mensurables que sean adicionales al trabajo normal, como "Capacitar en tecnología X", "Crear documentación para el fragmento de código Y que nadie entienda", etc. Cuando se trata de la evaluación anual de desempeño, los desarrolladores de la tarifa no están en los objetivos escritos, sino en mi opinión sobre el valor inconmensurable de su trabajo normal, ya que eso es realmente lo que le importa a la empresa.
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", "cantidad de producción emitida causada". Esto condujo a estimaciones infladas y una clasificación incorrecta de errores, con el fin de lograr mejores "puntajes". Curiosamente, incluso a los desarrolladores con una puntuación alta en este sistema no les gustó, ya que la confianza intrínseca dentro del equipo estaba dañada y no siempre sintieron que merecían su alta posición.
Establezca objetivos vagos que sean variantes en "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 mismos no son mensurables ni alcanzables, lo cual es desaconsejable.

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

Preguntas relacionadas que encontré que no abordan el mismo punto:

Actualización (18 de noviembre de 2009): hay 10 votos positivos para mi pregunta, y las respuestas mejor calificadas solo tienen 4 votos positivos (incluido uno para mí). Creo que esto nos dice algo: tal vez que Joel y los demás tienen razón, y que la sabiduría combinada de stackoverflow no puede dar lugar a objetivos convincentes y medibles para los desarrolladores que no puedan ser jugados sin afectar negativamente el valor real (no mensurable) de su trabajo. ¡Gracias por intentarlo!

¿Qué enfoque ha funcionado mejor para ti?

Solo un objetivo: pasar una inspección de código / revisión por pares, conmigo como el revisor, sin que yo encuentre ningún error ni tenga ninguna otra crítica, eso me pide que vuelva a hacer algo.

Notas:

No estaba midiendo la capacidad de los nuevos empleados para terminar rápidamente, y no los alenté: quería que las personas aprendieran a terminar bien (porque si no se termina bien, entonces no está terminado)
La gente aprendió lo que buscaba en una revisión del código: 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. Este es un error: debe solucionarlo antes de registrarse
2. Como sugerencia, habría hecho tal y tal
Después de un tiempo, mis revisiones del código de una persona dejarían de encontrar elementos "imprescindibles" (en ese momento ya no necesitaría revisar su trabajo).

Tener que establecer objetivos para los desarrolladores, aunque no funcionen

Si sus desarrolladores no funcionan, ¿tal vez algunos objetivos son lo que necesitan para incentivarlos? ;-)

"Asegúrese de que al menos el n% de su código se evalúa mediante una prueba de unidad adecuada" Use una herramienta de cobertura para probarlo y pida a otra persona que revise la calidad de la prueba.

Creo que tener objetivos muy específicos por adelantado, es decir, INTELIGENTE (tal vez 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 es que nuestros objetivos incrementales cambian. El negocio cambia y, como desarrolladores, tenemos que reaccionar y reaccionar adecuadamente y en un marco de tiempo razonable.

Considere establecer metas que se vinculen con el propósito de su equipo o grupo en la organización. Su equipo no recibiría fondos si no cumplía un objetivo: un objetivo macro. Tener objetivos colectivos que existen en todo su equipo y que se alinean con el negocio. Otorgue responsabilidad a las personas y responsabilice a la gente. Celebre sus éxitos y fracasos (si no fallamos en ocasiones, es probable que no lo intentemos y eso es lo que quiere de las personas). HTH

Determinar cómo alinear el desarrollo personal con los proyectos que se realizan es un punto clave en esto, creo. Hacer que los desarrolladores se analicen a sí mismos para encontrar debilidades junto con dar retroalimentación a los demás puede ser una forma de encontrar lo que se puede mejorar y luego encontrar una manera de medirlo. Por ejemplo, es posible que encuentre que rara vez documente los artículos completados, y así mis objetivos para el año puedo afirmar que deseo 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 así sea como mejoro mi trabajo y hago lo que se puede ver como la forma correcta, mientras que una visión pasiva agresiva o infantil sería producir una montaña de documentación si no es tan buena en los términos de calidad se pueden mejorar el próximo año ya que este puede ser otro punto a considerar: ¿Cuál se supone que es la motivación para mejorar todo lo posible en un año en comparación con el espaciamiento?

Definir un desarrollador efectivo es otro elemento para esto. ¿Es la persona que soluciona los errores mejor? ¿El nuevo trabajo es más rápido? ¿El nuevo trabajo se completa con pruebas y documentación, aunque no se hace rápido? Lo que está llamando eficaz ya que la respuesta estándar "depende" debe aclararse aquí.

Objetivos mensurables que he visto hasta ahora:

Pasar un examen de certificado
Investigue la tecnología X y realice una presentación al respecto
Cantidad de cambios de compilación comprometidos
Número de artículos de la wiki escritos sobre la gestión interna del conocimiento

¿Qué le parece preguntar a sus desarrolladores directamente si tienen algunas ideas para el desarrollo personal que luego podrían ser utilizadas para los objetivos?

Personalmente trato de establecer dos tipos de objetivos:

Objetivos enfocados en el negocio (es por eso que nos pagan después de todo). Por ejemplo, "complete el proyecto X antes del 1 de junio de 2009"). Estos objetivos a menudo se comparten entre varios miembros del equipo (y son conscientes de esto). El equipo puede superar el objetivo al adelantar el proyecto o exceder la funcionalidad requerida. Las personas pueden superar el objetivo produciendo más funcionalidades, 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 involucre una tecnología que el desarrollador quiera agregar a su conjunto de habilidades, comprender mejor el dominio del usuario, obtener experiencia de liderazgo, etc.

Siento que es importante que:

Los objetivos son SMART
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 estableció

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

Tenemos una cantidad de métricas que se recopilan a medida que los programadores trabajan, como por ejemplo:

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 a la publicación por pares, publicación posterior)
Solicitudes de cambio cumplidas / rechazadas
Documentos formales (descripciones de versiones de software, documentos de diseño, etc.)

Todos estos son elementos tangibles que me parecen útiles en las presentaciones de gestión y garantía de calidad del software. Pero nunca los encontré terriblemente útiles en las evaluaciones reales del rendimiento de las personas, que es lo que señalan varios de los enlaces que enumeró. Descubrí que los puntos de Joel aquí son válidos: las métricas nunca promueven una buena atmósfera de equipo.

Lamentablemente, todos vivimos en un mundo en el que los demás requieren métricas (gestión, aseguramiento de la calidad, contratistas externos, etc.). Descubrí que se requiere un acto de equilibrio, proporcionar esas métricas, pero también proporcionar evidencia de intangibles, siendo lo intangible lo que cada programador ha logrado y 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 inestimable.

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. Usualmente esto es suficiente para balancear el equilibrio de un programador en particular.

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

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

Un objetivo que me gusta es:

Solicite N comentarios positivos de su participación en un proyecto del cliente del proyecto.

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

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

Por ejemplo, si hubiera una iniciativa departamental para reducir la cantidad de multas problemáticas planteadas, entonces, podría establecer metas individuales en función de la cantidad de boletos relacionados con el software que cuida.

Dado que el desarrollo de software es muy colaborativo, tendría más sentido establecer objetivos a nivel de equipo y, a continuación, calificar a las personas de acuerdo con su contribución al equipo.