¿Son útiles los objetivos SMART para los programadores? [cerrado]

Varias organizaciones que conozco usan objetivos SMART para sus programadores. SMART es un acrónimo de específico, medible, alcanzable, relevante y con límite de tiempo. Son bastante comunes en las grandes corporaciones.

Mi propia experiencia previa con objetivos SMART no ha sido tan positiva. ¿Han encontrado otros programadores una manera efectiva de medir el desempeño? ¿Cuáles son algunos ejemplos de buenos objetivos SMART para programadores (si existen)?

En una palabra

No

Primero: mis proyectos nunca han permanecido lo suficientemente estables como para poder establecer los objetivos SMART con algún significado. El tiempo transcurre entre el momento en que mis roles cambian en un proyecto y el momento en que se realizan las revisiones de rendimiento están demasiado sincronizados.

Segundo: medir el desempeño individual es una excelente manera de crear una mentalidad de "no es mi trabajo" y una competencia negativa entre los individuos y / o los diferentes sub equipos de una organización. Es muy fácil jugar el sistema y asegurarte de que te estás cuidando a ti mismo y realmente no estás ayudando a todo el equipo. Deberíamos alentar a las personas a ser jugadores de equipo, pero nuestras organizaciones hacen exactamente lo contrario.

La mayoría de estos tipos de sistemas son antitéticos al trabajo en equipo. Mary Poppendieck ha hecho un trabajo mucho mejor articulando esto de lo que puedo hacer en LeanEssays: Team Compensation .

Sue recibió una llamada de Janice en recursos humanos. "Sue", dijo, "¡Gran trabajo que hizo tu equipo! Y gracias por completar todos esos formularios de entrada de evaluación. Pero realmente, no se puede dar a todos una calificación máxima. Su calificación promedio debe ser "cumple con las expectativas". Solo puede tener una o dos personas que 'superaron con creces las expectativas' ... ”

... Uno de los mejores líderes de opinión del siglo XX, W Edwards Deming, escribió que el daño no medible se crea al clasificar a las personas, los sistemas de méritos y el pago de incentivos. Deming creía que cada negocio es un sistema y el desempeño de las personas es en gran parte el resultado de la forma en que opera el sistema. En su opinión, el sistema causa el 80% de los problemas en un negocio, y el sistema es responsabilidad de la gerencia. Escribió que usar exhortaciones e incentivos para que las personas resuelvan problemas de gestión simplemente no funciona. Deming se opuso a la clasificación porque destruye el orgullo en la mano de obra y el mérito aumenta porque abordan los síntomas, en lugar de las causas, de los problemas.

... echemos un vistazo más profundo a la evaluación de los empleados y los sistemas de recompensas, y exploremos lo que hace que se vuelvan disfuncionales ...

Hemos utilizado objetivos SMART en la gran corporación donde trabajo. No tienen sentido en su mayor parte.

Los objetivos provienen de la alta dirección y son elevados y abstractos. Relacionarlos con proyectos y desarrollos concretos suele ser una broma. La mayoría de los proyectos que entran en el grupo provienen del negocio y deben satisfacer una necesidad comercial específica. Entonces codifica el proyecto, lo pone en producción y hace un trabajo increíble como de costumbre. ¿Cómo se relaciona eso con un objetivo que alguien de la alta dirección ideó?

Nos va mucho mejor como grupo cuando tenemos nuestros propios objetivos. A veces incluyen capacitación sobre un tema específico o la implementación de un nuevo cambio de proceso, algo que en realidad puede estar relacionado con lo que hacemos. Todavía no están realmente relacionados con el funcionamiento diario de la codificación, ya que son al menos cosas que ayudan a avanzar al grupo en el entorno corporativo.

EDITAR

Como Mnementh ha señalado correctamente, mi respuesta se basa en que los objetivos SMART no son, bueno, SMART. Agregaría a mi respuesta que si usted es un gerente de programadores y desea implementar metas SMART, asegúrese de que sean SMART. Use el ejemplo de mis mangagers como una forma de NO implementar objetivos INTELIGENTES. Si no administra a los programadores y alguien le dice que ahora va a comenzar a usar objetivos SMART y terminan como los nuestros, entonces comprenda que hay personas en la alta gerencia a quienes les gustan las palabras de moda y poder verificar ellos de una lista de cosas que han implementado.

Hay mucha investigación para demostrar que los programadores harán un excelente trabajo en cualquier criterio que se les presente, a costa de otros posibles objetivos.

Esto significa que lo harán bien en el logro de objetivos específicos y medibles, y menos en cualquier cosa que no esté específicamente listada. Eso significa que debes ser extremadamente cuidadoso al establecer metas.

No desea establecer líneas de código como objetivo. Créeme. Establecer errores solucionados conduce a escribir código con errores para empezar. Solicitar correcciones de errores en el código existente dará como resultado definiciones muy liberales de "error" (y tal vez "corrección"). (Además, la parte "alcanzable" depende de cuán defectuoso sea el código). Solicitar la integridad de las características en un momento determinado, bueno ...

Lo que quiere que hagan sus programadores es escribir cosas útiles en un período de tiempo razonable con buena calidad de código, y mejorarlo y modificarlo mientras se mantiene la calidad del código. Nunca he visto metas específicas y medibles que serían un buen criterio para mí.

Realizamos este ejercicio todos los años. El problema es que los desarrolladores aquí tienden a tener muy poca autonomía sobre lo que hacen (tareas determinadas por el gerente de producto). Somos afortunados de que, al menos en papel, tengamos tiempo dedicado a alcanzar nuestros objetivos. Siendo realistas, obtenemos mucho menos que eso, sin embargo.

Dentro de ese marco, he descubierto que establecer objetivos de autodesarrollo funciona muy bien. Por ejemplo, dos de mis objetivos del año pasado fueron:

1. Para leer Patrones de diseño y escribir proyectos de juguetes para aprender y demostrar cada patrón para el próximo año. Esto terminó tomando 2 años, pero la mejora en mi codificación ha sido notable.
2. Para estudiar las características del lenguaje .NET 3.5 y hacer una presentación a mis compañeros de trabajo cada trimestre. Esto terminó siendo una presentación en LINQ que mis compañeros de trabajo apreciaron en varios grados entre apáticos y ligeramente interesados. Sin embargo, aprendí mucho, y después de demostrar mi conocimiento de C #, me trasladaron a trabajar en un nuevo proyecto bastante bueno.

Entonces, sí, me he beneficiado y me he divertido al hacerlo.

Honestamente, en nuestra compañía, creo que la falta de buenos objetivos SMART para desarrolladores tiene más que ver con la aversión instintiva a las palabras corporativas.

Sí, si está configurado correctamente.

Si se establece correctamente, los objetivos pueden mejorar tanto al equipo como a las personas individuales. También deben estar alineados con el trabajo y diseñados para el individuo.

He estado en lugares donde todo un equipo de DBA tiene los mismos objetivos insípidos, así como críticas de alto nivel como "cumplir con los KPI globales y regionales según lo determine el comité de KPI". Que nadie sabe, por supuesto ...

Por otra parte, he estado en lugares donde el gerente establece objetivos individuales con pensamiento por adelantado.

Editar:

He leído el artículo de Mary Poppendieck y no se trata de SMART. "La percepción de imposibilidad" falla "Alcanzable", por ejemplo.

Deben establecerse objetivos para el individuo, para compartir sus fortalezas, ayudar a rectificar las debilidades, contribuir al equipo. La medida es para el individuo.

No debe haber comparación de x vs y.

Sin embargo, los objetivos para x e y deben ser proporcionales a su rango o posición dentro de un sistema: uno no establece los mismos objetivos para los seniors y juniors. Eso no es justo.

Se necesita algún punto de referencia para establecer bonificaciones o payrises desde un pozo limitado: ¿deberíamos contar líneas de código en su lugar? ¿Revisiones hechas por colegas?

Y muéstrame alternativas válidas que no requieran que cambie mi ética corporativa global. No critico a SMART: sí critico a los malos gerentes ...

Como marco de rendimiento, SMART es tan efectivo como cuán estrechamente están alineados sus objetivos con los de sus gerentes. A veces, sus objetivos SMART tienen que BAJAR primero, es decir. hazlos:

• Realizable
• Comprensible
• Manejable
• Beneficioso

Por extraño que pueda parecer.

El establecimiento de objetivos de tipo SMART puede ser útil en un contexto de programación, pero debe hacerse de manera inteligente o, como se señaló en otras respuestas, es probable que sea una pérdida de tiempo (o peor).

Para obtener objetivos útiles, es útil acordar qué significará el acrónimo SMART: una búsqueda rápida en Google encontró varias definiciones :

• S: parece tener consenso en Específico (aunque hay cierto desacuerdo sobre lo que eso significa)
• M: Significativo y motivacional son alternativas a las medidas más comunes
• R: parece representar más a menudo alcanzable, pero también he visto Acordado
• R: dependiendo de dónde mire, puede encontrar realistas, relevantes, centrados en los resultados
• T siempre parece hacer referencia al tiempo, aunque el énfasis varía

Entonces, primero, ambos lados de la negociación de fijación de objetivos deberían estar trabajando desde una comprensión común del proceso.

A continuación, se deben explicar y comprender los objetivos generales de la organización, división, grupo, equipo (o cualquier jerarquía relevante). En ese punto, debería ser posible para el individuo (la OMI, las metas deben establecerse a nivel individual para que valga la pena) poder acordar un pequeño número de objetivos que deberían informar las actividades de esa persona en el futuro.

Si termina allí, sigue siendo una pérdida de tiempo para todos. Los objetivos deben revisarse y ajustarse regularmente: cuando se logren, se debe considerar la posible necesidad de establecer nuevos objetivos, cuando no se logren, se deben identificar los motivos y se deben prescribir medidas correctivas cuando sea necesario.

Todos los interesados ​​deben ser conscientes de que este tipo de ejercicio no vale la pena si no se toma en serio, o tal vez más algorítmicamente, el valor a extraer es proporcional al esfuerzo realizado.

Puede ser instructivo ver lo que las personas piensan que podrían ser útiles / valiosos objetivos SMART. He hecho una pregunta aquí ...

El problema con los objetivos SMART es que tienen que elegir lo que se puede medir. Dado que lo que es medible y lo importante para el éxito de la organización a menudo no es lo mismo (y prácticamente nunca lo están en la programación), los objetivos SMART siempre fallan en las evaluaciones de desempeño en mi experiencia. Y a veces las cosas parecen medibles, pero no están exentas de demasiado esfuerzo (al igual que el objetivo SMART, tuve una sola vez para responder todos los correos electrónicos en 4 horas. Realmente, ¿quién quiere tratar de revisar los miles de correos electrónicos que recibo al año? era informativo o necesitaba una respuesta y luego mira mis correos electrónicos enviados para ver si respondí y luego escucha las grabaciones de todas las llamadas telefónicas para ver si respondí, revisa mi registro de MI para ver si respondí, etc. Y ¿Qué pasa con ese correo electrónico que me enviaron el sábado por la noche a la medianoche ...)

Para todas las personas que respondieron NO, sus Objetivos probablemente NO fueron lo suficientemente INTELIGENTES.

Los he usado y los encuentro increíblemente útiles. Es posible que desee probar algo que nos funcione:

1. Establecer objetivos trimestrales.
2. Establecer objetivos medibles.
3. Establecer solo una meta para el individuo
4. Haga que el individuo acepte el objetivo, si dice que el objetivo es un reajuste demasiado ambicioso hasta el momento en que ambos estén de acuerdo.
5. Al final del trimestre, obtenga un valor booleano. Objetivo alcanzado = verdadero o falso.

Esto es extremadamente poderoso, crea responsabilidad para el Desarrollador. Las personas que quieren encontrar excusas se vuelven locas después de aproximadamente 6 meses.

PD: Puedo entender a las personas que votan por la respuesta, pero por favor deja un comentario relevante al menos, aprenderé algo que no sé :-)

SMART es un acrónimo para recordar algunos criterios para mejores objetivos. Entonces, introducir SMART significa que su administración debe mejorar siguiendo este principio. Sin SMART, la gestión establecería objetivos de todos modos, pero probablemente sería demasiado difícil.

Por lo tanto, para los programadores no debería haber cambios, la administración tiene que cambiar su estilo para implementar SMART. Y si lo hacen bien, su trabajo como programador puede ser más fácil, porque la dirección del proyecto es más clara, se establecen plazos y así sucesivamente.

Si la gerencia no lo hace bien, no cambiará mucho.