Insignias para los miembros del equipo del proyecto para la motivación

Si este es un proyecto en el que actualmente se les paga a las personas por trabajar: ¡ABSOLUTAMENTE NO!

En primer lugar, los objetivos del proyecto deben ser claros y obvios, y en un proyecto de software, esos objetivos ya pueden ser complicados. Obtenga diseños completos a tiempo, complete el código a tiempo con la menor cantidad de defectos posible, incorpore comentarios de revisiones de código, corrija las pruebas unitarias que rompió al trabajar en esta nueva característica, complete nuevas pruebas unitarias a tiempo, obtenga notas doc/doc hecho a tiempo.

Ahora, además de eso, ¿quieres agregar un montón de objetivos "borrosos" que mencionas en el n. ° 3? ¿"Objetivar"? Si propones una insignia para eso, antes de terminar tu primer sprint te vas a arrepentir de haber tenido esa idea. La gente va a argumentar que su objetivación es mejor que la objetivación de otra persona. Todo tipo de tiempo se perderá en esto. Y en el peor de los casos: las personas comenzarán a volverse personales porque a alguien no le gustó su objetivación. Metas como "organización" y "estandarización" son igualmente confusas.

Ya tienes suficientes objetivos. Deje en paz a sus desarrolladores para lograrlos. No desea que las personas pasen tiempo persiguiendo insignias (por lo que su organización no recibe crédito). Quieres que traten de lograr objetivos reales.

StackExchange puede usar estas insignias porque no nos pagan por esto. Y si no se hace, solo StackExchange sale perdiendo (aunque ciertamente las comunidades se benefician de este conjunto de conocimientos y personas). StackExchange también tiene un proceso automatizado para otorgar insignias. ¿Cómo van a automatizar la entrega de la insignia de "diseño"? no puedes Así que vas a tener que pasar mucho tiempo haciéndolo manualmente.

Los desarrolladores son conocidos por jugar con cualquier sistema que les pongas delante. El juego de sistemas a menudo conduce a desperdiciar energía mientras se pierde por completo el punto (objetivos reales). Tus metas actuales son lo suficientemente importantes y difíciles. Mantenga a su gente enfocada en ellos.

Ya hay muchas teorías y estudios sobre la motivación. Se han estudiado los motivadores extrínsecos, como insignias, premios y dinero, y creo que los resultados muestran que, en el mejor de los casos, son marginales, no hacen nada o tal vez incluso reducen la motivación. Los motivadores más fuertes son intrínsecos y son el dominio, el propósito y la autonomía.

Sigue la ciencia....

¿Es una buena idea?

En cuanto a casi todo: todo depende de tu equipo.

Algunos pueden ser muy receptivos, otros absolutamente no. Si estamos hablando de un equipo interno, creo que funcionaría más fácilmente con personas que ya confían en ti y que tienen algo de sentido del humor, ya que tendrán que lidiar con algo que parece poco corporativo y, por lo tanto, en primera vista, tal vez "poco profesional" para algunos. Personalmente tuve este problema cuando traté de agregar algunos otros artefactos divertidos pero serios de "mejora social", y retrocedí cuando me di cuenta de que el equipo no era receptivo y lo consideró más como un juego que quería jugar en lugar de realmente útil . práctica de PM.

¿Otros lo hacen?

Bueno, no exactamente insignias , pero en la misma línea, y sin duda más impresionantes;) echa un vistazo, por ejemplo, a la Ceremonia de Espadas y Escudos en Blizzard.

Métrica

• codificación: esto no es una métrica (¿qué estás midiendo exactamente?).
• compromiso: esta es una mala métrica, cantidad no significa calidad, y suele ser lo contrario en el software.
• completar las tareas a tiempo: posiblemente, pero también en el alcance, y de tal manera que la finalización no se haya realizado de una manera tan terrible que generará errores más adelante ...
• …

En realidad, me detendré aquí. Esto ya ha sido abordado .

Debe notar que todo el sistema de insignias y reputación de SE se basa en una comunidad de seres humanos que evalúan cosas . La única automatización que se lleva a cabo es contar puntajes y asociar insignias a ese puntaje.

Para los probadores, debería ser un poco más fácil. La cantidad de errores detectados, posiblemente ponderados por gravedad, podría ser una métrica fácil. También podría considerar el tiempo anterior al informe como otra métrica.

Consideraciones filosóficas

Dicho sistema es simplemente un modelo de reputación y, por lo tanto, una forma de simplificar la atribución de la confianza humana . Sin embargo, para que un sistema de este tipo funcione, tiene que corresponder con precisión a eventos que otros humanos reconocerían como impresionantes, o al menos buenos de alguna manera.

Y me temo que aquí es exactamente donde llegarás al límite de la automatización. Según esta misma definición, las métricas computables automáticamente no pueden calcular qué tan bueno es el trabajo creativo. Las computadoras son muy buenas para calcular cosas, no realmente para evaluar el trabajo creativo. Y la codificación es un trabajo creativo.

Por lo tanto, no creo que un sistema de este tipo sea realmente sostenible para solicitar contribuciones, ya que generaría dudas rápidamente sobre la métrica utilizada. Lo más probable es que otros programadores ignoren todo lo que no sea una evaluación humana, eliminando la intención misma de mejorar la reputación . Incluso podría tener el efecto contrario, dependiendo de las métricas utilizadas ( "¿colaborador de oro? eh, este tipo probablemente hizo 30 confirmaciones de mierda..." ).

Entonces, concluyamos. Agregar un sistema de insignias es una ventaja genial que simplifica dicha evaluación al agregar pasos discretos a un espectro continuo de evaluación, pero para que tenga algún significado, debe asegurarse de que la forma en que se atribuyen sea consensuada. Para esto, creo que la única métrica válida es la evaluación por pares . Esto es difícil de obtener de manera confiable en cualquier cosa que no sea proyectos con una comunidad sólida.

Por lo tanto, le aconsejo que lo piense dos veces antes de probar este sistema de recompensas, ya que podría ignorarse con bastante facilidad, lo que haría que desperdiciara esfuerzos y quedara como un tonto, o incluso una reacción violenta si un subconjunto de la población lo compra pero no otro, segmentando su comunidad. equipo.

Mirando esto desde el punto de vista de un programador, hay algunas cosas que se pueden hacer y algunas cosas potencialmente malas están al acecho.

Primero las cosas malas: no desea fomentar las malas prácticas. El que me llamó la atención fue "número de confirmaciones". De hecho, enviar todo como una sola confirmación es malo, pero es igualmente malo enviar una confirmación por archivo (o una confirmación para cambiar el comentario, otra confirmación para cambiar el código). Idealmente, las confirmaciones se realizan con una agrupación lógica: si es una confirmación, es una, si es 20, son veinte. Pero tratar de encontrar un número 'ideal' de confirmaciones es una locura.

Del mismo modo, he visto que los objetivos para el informe de errores fallan. Si uno recompensa (o requiere) una cierta cantidad de errores, en lugar de "este error ocurre bajo este conjunto de circunstancias", encontrará "este error ocurre bajo este conjunto de circunstancias en la página A", "este error ocurre bajo este conjunto de circunstancias". circunstancias en la página B", ... "este error ocurre bajo este conjunto de circunstancias en la página Z". Y hay docenas de errores más reportados que no ayudan a nadie (ha perdido tiempo el tiempo del reportero, y la persona que tiene que priorizar los errores adicionales, y la persona que tiene que arreglarlos, y la persona que tiene que cerrar a ellos).

Medir líneas de código escritas también es una métrica defectuosa. Considere a Bill Atkison escribiendo -2000 líneas de código

Cuando el equipo de Lisa estaba presionando para finalizar su software en 1982, los gerentes de proyecto comenzaron a exigir a los programadores que enviaran formularios semanales que informaran sobre la cantidad de líneas de código que habían escrito. Bill Atkinson pensó que eso era una tontería. Para la semana en la que había reescrito las rutinas de cálculo de regiones de QuickDraw para que fueran seis veces más rápidas y 2000 líneas más cortas, puso "-2000" en el formulario. Después de algunas semanas más, los gerentes dejaron de pedirle que completara el formulario y él cumplió con gusto. (de Computer History en QuickDraw )

Para una posible solución, mire el complemento del juego de integración continua de Jenkins donde el servidor de compilación examina la información de análisis estático de una compilación y otorga (o resta) puntos para una serie de cosas (estilo de código, prácticas de codificación, pruebas unitarias, advertencias del compilador). Tenga en cuenta que todas estas cosas son programáticas y no implican interacción humana ni juicio.

Dicho esto, es interesante ver cómo obtengo una puntuación en la pestaña del juego de CI de compilación local. Pero no lo "juego". Me esfuerzo por escribir un buen código porque quiero que sea un buen código, no porque obtenga puntos o una insignia.

Compartiría la idea con su equipo y les preguntaría su opinión.

Puedes hacerlo por diversos medios:

• pídale a su equipo que comparta ideas sobre cómo gamificar el trabajo; propone tu idea entonces

• pregúntale a tu equipo directamente qué piensan sobre tu idea

• pida permiso para hacer un experimento de 30 días para ver cómo funciona
• ...

El hecho es que ninguno de nosotros ha probado esto antes. Sobre todo en tu equipo. Todo es adivinar. Pero si su equipo está abierto a probar cosas nuevas, hágalo y sea el primero en probar la idea en el trabajo y compartir sus ideas.

No conozco la teoría de gestión de esto, pero sería extremadamente cauteloso al introducir insignias de la manera que usted describe. Cuando reúno un equipo para entregar un producto, quiero que todos logren el mejor resultado general del equipo, sea lo que sea que eso signifique, en lugar de competir como individuos y potencialmente socavar o no ayudarse mutuamente.

La única forma en que podría ver un esquema como este funcionando sería que el resto del equipo otorgara insignias a las personas, no mediante el logro de objetivos arbitrarios que no tienen un valor claro. Tal vez tendría algún mérito tener una insignia de "Útil", o un premio de "gran contribución", o un certificado de "solucionador de problemas", pero no lo conviertas en una competencia. Los equipos se unen: los jugadores pueden competir para ser parte del equipo, pero una vez que están dentro, deben trabajar para los demás.

¡Ten cuidado! Hay una fina línea subjetiva entre motivar y manipular. Si su equipo decide que esto es lo último, es posible que no vuelva a recuperar su confianza.

¿Estás seguro de que, de hecho, no estás intentando manipularlos? Parece que no crees que harán un buen trabajo sin más motivación. Pero que darles recompensas imaginarias les proporcionará esa motivación. Basado en métricas de la calidad del proyecto que planea generar. Lo que implica que crees que puedes medir la calidad del proyecto mejor que tu equipo (de lo contrario, ¿por qué intentar cambiar su comportamiento si saben mejor que tú cuál debería ser su comportamiento?).

Lo siento, pero si yo fuera usted, esperaría que mi equipo no haya encontrado esta pregunta.

Las razones dadas en otras respuestas de que esta es una mala idea son en su mayoría ciertas, sin embargo, creo que se están perdiendo el panorama general. El problema número uno con este enfoque es que estás tratando al equipo como un grupo de personas, y no como un equipo. ¿Quieres dar elogios al equipo? Impresionante. Pero nunca debes dividir intencionalmente a tu equipo de esa manera.

Sigo sintiendo que cualquier sistema de juego aleja el foco del desarrollo e introduce un fuerte individualismo dentro de la organización . La gamificación se introdujo en las aplicaciones con el fin de utilizar el juego para mantener a los clientes. Regresan a su servicio en parte debido a la experiencia de juego.

Tomemos Diablo 3 por ejemplo. Obtener insignias no te acercará al objetivo final, y para obtener algunas de ellas, los jugadores pueden realizar muchas actividades innecesarias, y sigue siendo una tarea individual. Volviendo al desarrollo de software: ¿qué evitará la aparición de comentarios, confirmaciones, refactorizaciones y funciones innecesarias?

Puede tener recompensas por actividades comunes para resolver el problema de logros en solitario, pero esas son realmente difíciles de rastrear, y seguramente necesitará un guardabosques. O dos.

No soy partidario de utilizar este tipo de cosas para motivar a la gente y sacar adelante los proyectos. Sin embargo, la gamificación puede mejorar ciertas partes como el intercambio de conocimientos (p. ej., el ejemplo de FedEx ) y la educación (p. ej ., codeschool ).

Un ejemplo personal. Traté de motivar a las personas a ser más ágiles usando el Agile Trophy en 2010. Se lo entregué al colega que hizo la contribución más valiosa a nuestra forma ágil de trabajar durante la semana. La ceremonia fue divertida, lo hicimos durante la reunión semanal de todo el personal, la persona que recibió el trofeo estaba orgullosa, pero no todos jugaron. En parte porque no les importaba mi estúpido trofeo, o no les gustaban las reglas, o les resultaba difícil conseguirlo (no entregué el trofeo por un buen comentario durante una reunión diaria). La idea murió bastante rápido, no hizo avanzar los proyectos, y casi nadie lo recuerda, pero fue divertido :-)

A diferencia de Kent, creo que esta es una idea interesante que podría funcionar. La advertencia es que deberá integrar esta herramienta con otras prácticas de recursos humanos. Esto podría generar bonificaciones, promociones, etc., etc. Por ejemplo, un desarrollador puede tener metas para lograr X insignias de bronce por proyecto en promedio durante un año, esas metas deben cumplirse para obtener una bonificación de A%, pero si obtén tu X bronce por promedio de proyecto y obtén Y plata y tu bono sube.

Creo que la conclusión es que se necesita un plan sólido e integrado para implementar esto con estándares muy claros y la aceptación de los gerentes corporativos. Usar una población de incentivos desconectados es una receta para la confusión y el desastre.

Es una idea interesante, y pude ver lo que parecía buena al principio. Pero lo desaconsejaría. En parte porque creo que se basa en una base fundamentalmente defectuosa. Sé que para mí, las insignias no proporcionan ninguna motivación. Son simplemente un subproducto de continuar tratando de responder preguntas de una manera que otros encuentren útil. Mi ranking me motiva, ya que significa que estoy aportando valor.

El segundo tema es que la idea parece, pues lo siento, pero un poco 'escuela primaria'. Estás (presumiblemente) hablando de un equipo de adultos y profesionales aquí. Cuestiono la necesidad de motivar de esta manera. Es casi lo contrario de los juegos que mencionó Kent: ¿estás jugando con el equipo para motivarlos? ¿Es eso realmente necesario?

No, entiendo por qué podría ir en esta dirección, pero si siente que es realmente necesario, entonces creo que tiene un problema mayor. Necesita ver 'por qué' siente que motivar de esta manera es necesario y abordar ese problema. ¿Por qué su equipo necesita una motivación adicional para hacer su trabajo fuera de la situación existente?

El proceso de desarrollo de software es un trabajo en equipo y medir la productividad de las personas a través de algunas metas objetivas podría ir en contra de la dinámica/vinculación del equipo. Sugiero que si desea recompensar a las personas, haga que sea una actividad anual basada en las contribuciones al proyecto que marcó una diferencia significativa.

100 registros con código inútil no es algo que desee recompensar, pero se debe otorgar 1 registro en el que se mejoró el rendimiento del software.

Tuvimos ejercicio para medir la productividad de las personas y luego dar aumentos salariales utilizando este número de productividad y fue contraproducente para nosotros. La gente dejó de cooperar entre sí porque ayudar a los demás aumentaría su productividad.