Epígrafe
El marido, mirando a los niños sucios, le dice a su mujer: bueno, ¿los lavamos o damos a luz otros nuevos?
Debajo del corte se encuentra la segunda parte de un artículo de nuestro líder de equipo, así como del director de desarrollo de productos de RAS, Igor Marnat, sobre las peculiaridades de motivar a los programadores. La primera parte del artículo se puede encontrar aquí:
En la primera parte del artículo, toqué los dos niveles inferiores de la pirámide de Maslow: necesidades fisiológicas, necesidades de seguridad, comodidad y constancia y pasé al siguiente tercer nivel, a saber:
III - Necesidad de pertenencia y amor.
Sabía que la mafia italiana se llamaba “Cosa Nostra”, pero quedé muy impresionado cuando descubrí cómo se traduce “Cosa Nostra”. "Cosa Nostra" traducida del italiano significa "Nuestro negocio". La elección del nombre es muy acertada para la motivación (dejemos de lado la ocupación, en este caso sólo nos interesa la motivación). Por lo general, una persona quiere ser parte de un equipo, hacer algo grande y común en nuestro negocio.
Se concede gran importancia a satisfacer la necesidad de pertenencia y amor en el ejército, la marina y cualquier gran formación paramilitar. Y, como vemos, en la mafia. Esto es comprensible, porque es necesario obligar a personas que tienen poco en común, que inicialmente no forman un equipo de personas con ideas afines, que se reúnen mediante reclutamiento (no voluntariamente), que tienen diferentes niveles de educación, diferentes valores personales. , dedicar literalmente su vida, a riesgo de muerte, a alguna causa común, confiar su vida a un compañero de armas.
Esta es una motivación muy fuerte, para la mayoría de las personas es sumamente importante sentir que pertenecen a algo más grande, saber que eres parte de una familia, un país, un equipo. En el ejército, los uniformes, diversos rituales, desfiles, marchas, pancartas, etc., sirven para estos fines. Aproximadamente los mismos factores son importantes para cualquier equipo. Son importantes los símbolos, la marca corporativa y los colores corporativos, la parafernalia y los souvenirs.
Es importante que los acontecimientos importantes tengan su propia encarnación visible con la que puedan asociarse. Hoy en día es más bien habitual que una empresa tenga su propia mercancía, chaquetas, camisetas, etc. Pero también es importante destacar el equipo dentro de la empresa. A menudo lanzamos camisetas basadas en los resultados de un lanzamiento, que se entregan a todos los involucrados en el lanzamiento. Algunos eventos, celebraciones conjuntas o actividades con todo el equipo son otro factor importante de motivación.
Además de los atributos externos, otros factores influyen en el sentimiento de pertenencia a un equipo.
En primer lugar, la presencia de un objetivo común, que todos comprendan y compartan una valoración de su importancia. Los programadores generalmente quieren entender que están haciendo algo interesante y que lo están haciendo juntos, como un equipo.
En segundo lugar, el equipo debe tener un espacio de comunicación en el que esté presente todo el equipo y que le pertenezca únicamente a él (por ejemplo, un chat en el messenger, sincronizaciones periódicas del equipo). Además de las cuestiones laborales, la comunicación informal, a veces la discusión de eventos externos, la iluminación, todo esto crea un sentido de comunidad y equipo.
En tercer lugar, destacaría la introducción de buenas prácticas de ingeniería dentro del equipo, el deseo de elevar los estándares respecto a los aceptados en la empresa. Implementar los mejores enfoques aceptados en la industria, primero en el equipo y luego en la empresa en su conjunto, le da al equipo la oportunidad de sentir que de alguna manera está por delante de los demás, liderando el camino, esto crea un sentido de pertenencia. a un equipo genial.
El sentido de pertenencia también se ve influenciado por la participación del equipo en la planificación y gestión. Cuando los miembros del equipo participan en la discusión de los objetivos del proyecto, los planes de trabajo, los estándares del equipo y las prácticas de ingeniería, y entrevistan a nuevos empleados, desarrollan un sentido de participación, propiedad compartida e influencia en el trabajo. Las personas están mucho más dispuestas a llevar a cabo decisiones tomadas y expresadas por ellas mismas que las propuestas por otros, incluso si están prácticamente en sintonía.
Cumpleaños, aniversarios, acontecimientos importantes en la vida de los compañeros: una pizza conjunta, un pequeño obsequio del equipo dan un cálido sentimiento de implicación y gratitud. En algunas empresas es costumbre entregar pequeños carteles conmemorativos por 5, 10, 15 años de trabajo en la empresa. Por un lado, no creo que esto me motive tanto para conseguir nuevos logros. Pero, evidentemente, casi todo el mundo se alegrará de no haberse olvidado de él. Este es uno de esos casos en los que la ausencia de un hecho desmotiva más que su presencia motiva. De acuerdo, puede ser una lástima que LinkedIn te lo recuerde por la mañana y te felicite por tu décimo aniversario en tu lugar de trabajo, pero ni un solo colega de la empresa te felicitó ni se acordó de ti.
Por supuesto, un punto importante es el cambio en la composición del equipo. Está claro que incluso si la llegada o salida de alguien del equipo se anuncia con anticipación (por ejemplo, en un boletín de la empresa o del equipo, o en una reunión del equipo), esto no motiva particularmente a nadie a lograr nuevos logros. Pero si un buen día ves a una persona nueva a tu lado, o no ves a la anterior, puede ser una sorpresa, y si te vas, absolutamente desagradable. La gente no debería desaparecer silenciosamente. Especialmente en un equipo distribuido. Especialmente si tu trabajo depende de un colega de otra oficina que de repente se levantó y desapareció. Definitivamente vale la pena informar al equipo por separado con anticipación sobre esos momentos.
Un factor importante, que en inglés se llama propiedad (la traducción literal de “posesión” no refleja plenamente su significado). Este no es un sentimiento de propiedad, sino más bien un sentimiento de responsabilidad por tu proyecto, ese sentimiento cuando te asocias emocionalmente con el producto y el producto contigo mismo. Esto corresponde aproximadamente a la oración del Marine en la película “La chaqueta metálica”: “Este es mi rifle. Hay muchos rifles de este tipo, pero éste es el mío. Mi rifle es mi mejor amigo. Ella es mi vida. Debo aprender a poseerlo de la misma manera que soy dueño de mi vida. Sin mí mi rifle es inútil. Soy inútil sin mi rifle. Debo disparar mi rifle directamente. Tengo que disparar con mayor precisión que el enemigo que intenta matarme. Tengo que dispararle antes de que él me dispare. Que así sea… ".
Cuando una persona trabaja en un producto durante mucho tiempo, tiene la oportunidad de asumir la responsabilidad total de su creación y desarrollo, de ver cómo algo funcional surge de "la nada", cómo lo usa la gente, surge este poderoso sentimiento. Los equipos de producto que trabajan juntos durante mucho tiempo en un proyecto suelen estar más motivados y cohesionados que los equipos que se reúnen durante un corto período de tiempo y trabajan en modo de línea de montaje, cambiando de un proyecto a otro, sin responsabilidad total sobre todo el producto. , de principio a fin.
IV. Necesidad de reconocimiento
Una palabra amable también agrada al gato. A todos les motiva el reconocimiento de la importancia del trabajo realizado y su valoración positiva. Hable con los programadores, bríndeles comentarios periódicos, celebre el trabajo bien hecho. Si tienes un equipo grande y distribuido, las reuniones periódicas (las llamadas uno a uno) son perfectas para esto; si el equipo es muy pequeño y trabaja en conjunto localmente, esta oportunidad se suele brindar sin reuniones especiales en el calendario (aunque sí periódicas). a uno es todo (todavía es necesario, sólo que puedes hacerlo con menos frecuencia). Este tema está bien tratado en los podcasts para gerentes en manager-tools.com.
Sin embargo, vale la pena tener en cuenta las diferencias culturales. Algunos enfoques familiares para los colegas estadounidenses no siempre funcionarán con los rusos. El nivel de cortesía adoptado en la comunicación diaria en los equipos de los países occidentales inicialmente parece excesivo a los programadores de Rusia. Cierta franqueza característica de los colegas rusos puede ser percibida como descortesía por sus colegas de otros países. Esto es muy importante en la comunicación en un equipo interétnico, se ha escrito mucho sobre este tema, el líder de dicho equipo debe recordarlo.
Las demostraciones de funciones, donde los programadores muestran las funciones desarrolladas durante un sprint, son una buena práctica para satisfacer esta necesidad. Además de ser una excelente oportunidad para despejar canales de comunicación entre equipos, presentar nuevas funciones a los gerentes de producto y evaluadores, también es una buena oportunidad para que los desarrolladores muestren los resultados de su trabajo e indiquen su autoría. Bueno, y pulir tus habilidades para hablar en público, por supuesto, lo cual nunca es perjudicial.
Sería bueno celebrar la importante contribución de colegas especialmente distinguidos con certificados, carteles conmemorativos (al menos una palabra amable) en las reuniones conjuntas del equipo. La gente suele valorar mucho estos certificados y carteles conmemorativos, los lleva consigo cuando se muda y, en general, los cuida de todas las formas posibles.
Para marcar una contribución más significativa y a largo plazo al trabajo del equipo, la experiencia y los conocimientos acumulados, a menudo se utiliza un sistema de calificaciones (nuevamente, se puede establecer una analogía con el sistema de rangos militares en el ejército, que, además para garantizar la subordinación, también sirve para este propósito). A menudo, los desarrolladores jóvenes trabajan el doble de duro para conseguir nuevas estrellas en sus hombros (es decir, pasar de desarrollador junior a desarrollador de tiempo completo, etc.).
Conocer las expectativas de su gente es fundamental. Algunos están más motivados por una calificación alta, la oportunidad de ser llamados, digamos, arquitecto, mientras que otros, por el contrario, son indiferentes a las calificaciones y títulos y considerarán un aumento de salario como una señal de reconocimiento por parte de la empresa. . Comunicarse con las personas para comprender lo que quieren y cuáles son sus expectativas.
Una demostración de reconocimiento, un mayor nivel de confianza por parte del equipo, se puede dar dando más libertad de acción o implicación en nuevas áreas de trabajo. Por ejemplo, después de adquirir cierta experiencia y lograr ciertos resultados, un programador, además de implementar sus funciones de acuerdo con la especificación, puede trabajar en la arquitectura de cosas nuevas. O involúcrese en nuevas áreas que pueden no estar directamente relacionadas con el desarrollo: automatización de pruebas, implementación de mejores prácticas de ingeniería, ayuda con la gestión de lanzamientos, charlas en conferencias, etc.
V. La necesidad de cognición y autorrealización.
Muchos programadores se centran en diferentes tipos de actividades de programación en diferentes etapas de sus vidas. A algunas personas les gusta hacer aprendizaje automático, desarrollar nuevos modelos de datos, leer mucha literatura científica para trabajar y crear algo nuevo desde cero. Otro está más cerca de depurar y soportar una aplicación existente, en la que es necesario profundizar en el código existente, estudiar registros, seguimientos de pila y captchas de red durante días y semanas, y casi no escribir código nuevo.
Ambos procesos requieren un gran esfuerzo intelectual, pero su resultado práctico es diferente. Se cree que los programadores son reacios a apoyar las soluciones existentes; más bien están motivados para desarrollar otras nuevas. Hay una pizca de sabiduría en esto. Por otro lado, el equipo más motivado y unido con el que he trabajado se dedicó a dar soporte a un producto existente, buscando y corrigiendo errores después de que el equipo de soporte se comunicara con ellos. Los muchachos literalmente vivían para este trabajo y estaban listos para salir los sábados y domingos. Una vez abordamos con entusiasmo otro problema urgente y complejo, ya sea la tarde del 31 de diciembre o la tarde del 1 de enero.
Varios factores influyeron en esta alta motivación. En primer lugar, era una empresa con un gran nombre en la industria, el equipo se asoció con ella (ver “La necesidad de afiliación”). En segundo lugar, eran la última frontera, no había nadie detrás de ellos, no había ningún equipo de producto en ese momento. Entre ellos y los clientes había dos niveles de soporte, pero si el problema los alcanzaba, no había ningún lugar al que retirarse, nadie estaba detrás de ellos, toda la corporación estaba sobre ellos (cuatro jóvenes programadores). En tercer lugar, esta gran empresa tenía clientes muy importantes (gobiernos de países, empresas automotrices y de aviación, etc.) e instalaciones de gran escala en varios países. Como resultado, siempre se resolvieron problemas complejos e interesantes, problemas simples con el apoyo de niveles anteriores. En cuarto lugar, la motivación del equipo estuvo muy influenciada por el nivel profesional del equipo de soporte con el que interactuaron (había ingenieros muy experimentados y técnicamente capacitados), y siempre tuvimos confianza en la calidad de los datos que prepararon, el análisis que llevaron a cabo. , etc. En quinto lugar, y creo que este es el punto más importante: el equipo era muy joven, todos los muchachos estaban al comienzo de sus carreras. Estaban interesados en estudiar un producto grande y complejo, resolver problemas serios que eran nuevos para ellos en un entorno nuevo, buscaban igualar profesionalmente el nivel de los equipos, problemas y clientes que los rodeaban. El proyecto resultó ser una escuela excelente, luego todos hicieron una buena carrera en la empresa y se convirtieron en líderes técnicos y gerentes senior, uno de los muchachos ahora es gerente técnico en Amazon Web Services, el otro finalmente se mudó a Google, y todos Muchos de ellos todavía recuerdan este proyecto con calidez.
Si este equipo estuviera formado por programadores con 15-20 años de experiencia a sus espaldas, la motivación sería diferente. La edad y la experiencia no son, por supuesto, factores 100% determinantes, todo depende de la estructura de la motivación. En este caso particular, el deseo de conocimiento y crecimiento de los jóvenes programadores dio excelentes resultados.
En general, como ya hemos mencionado varias veces, debes conocer las expectativas de tus programadores, entender a cuál de ellos le gustaría ampliar o cambiar su campo de actividad y tener en cuenta estas expectativas.
Más allá de la pirámide de Maslow: visibilidad de resultados, gamificación y competencia, sin tonterías
Hay tres puntos más importantes con respecto a la motivación de los programadores que definitivamente deben mencionarse, pero incluirlos en el modelo de necesidades de Maslow sería demasiado artificial.
El primero es la visibilidad y proximidad del resultado.
El desarrollo de software suele ser un maratón. Los resultados de los esfuerzos de I+D se hacen visibles después de meses, a veces años. Es difícil llegar a una meta que está mucho más allá del horizonte, la cantidad de trabajo es aterradora, la meta está lejos, no es clara ni visible, “la noche es oscura y llena de horrores”. Es mejor dividir el camino en partes, hacer un camino hasta el árbol más cercano que sea visible, accesible, los contornos sean claros y no esté lejos de nosotros, e ir a esta meta cercana. Queremos hacer un esfuerzo de varios días o semanas, obtener y evaluar el resultado y luego seguir adelante. Por lo tanto, vale la pena dividir el trabajo en partes pequeñas (los sprints ágiles sirven bien para este propósito). Hemos completado parte del trabajo - lo hemos grabado, exhalado, discutido, castigado a los culpables, recompensado a los inocentes - podemos comenzar el siguiente ciclo.
Esta motivación es hasta cierto punto similar a la que experimentan los jugadores al completar juegos de ordenador: periódicamente reciben medallas, puntos y bonificaciones a medida que completan cada nivel; esto se puede llamar "motivación de la dopamina".
Al mismo tiempo, la visibilidad del resultado es literalmente importante. Una característica cerrada en la lista debería volverse verde. Si el código se escribe, se prueba y se publica, pero no hay cambios en el estado visual visible para el programador, se sentirá incompleto y no habrá sensación de finalización. En uno de los equipos de nuestro sistema de control de versiones, cada parche pasó por tres etapas sucesivas: se ensambló la compilación y se aprobaron las pruebas, el parche pasó la revisión del código y se fusionó el parche. Cada etapa estaba marcada visualmente con una marca verde o una cruz roja. Una vez que uno de los desarrolladores se quejó de que la revisión del código tomaba demasiado tiempo, sus colegas tuvieron que acelerar y los parches estuvieron colgados durante varios días. Le pregunté: ¿qué cambia esto realmente para él? Después de todo, cuando se escribe el código, se ensambla la compilación y se pasan las pruebas, no necesita prestar atención al parche enviado si no hay comentarios. Los propios compañeros lo revisarán y aprobarán (si, nuevamente, no hay comentarios). Él respondió: "Igor, quiero obtener mis tres garrapatas verdes lo antes posible".
El segundo punto es la gamificación y la competencia.
Al desarrollar uno de los productos, nuestro equipo de ingeniería tenía como objetivo ocupar una posición destacada en la comunidad de uno de los productos de código abierto, para ingresar al top 3. En ese momento, no había una forma objetiva de evaluar la visibilidad de alguien en la comunidad; cada una de las grandes empresas participantes podía afirmar (y afirmaba periódicamente) que era el contribuyente número uno, pero no había una forma real de comparar las contribuciones de los participantes. entre sí, para evaluar su dinámica en el tiempo. En consecuencia, no había forma de fijar una meta para el equipo que pudiera medirse en algunos loros, evaluar el grado de su consecución, etc. Para solucionar este problema, nuestro equipo ha desarrollado una herramienta para medir y visualizar la contribución de empresas y contribuyentes individuales. . Desde el punto de vista motivacional, resultó ser simplemente una bomba. No fueron sólo los ingenieros y los equipos los que monitorearon constantemente su progreso y el de sus colegas y competidores. La alta dirección de nuestra empresa y todos los principales competidores también comenzaron su día con stackalytics. Todo se volvió muy transparente y visual, todos podían monitorear cuidadosamente su progreso, compararlo con sus colegas, etc. Se ha vuelto conveniente y fácil para ingenieros, gerentes y equipos establecer objetivos.
Un punto importante que surge al implementar cualquier sistema de métricas cuantitativas es que tan pronto como los implementas, el sistema automáticamente se esfuerza por priorizar el logro de estas métricas cuantitativas, en detrimento de las cualitativas. Por ejemplo, la cantidad de revisiones de código completadas se utiliza como una de las métricas. Obviamente, la revisión del código se puede realizar de diferentes maneras, puede dedicar varias horas a una revisión exhaustiva y verificar un parche complejo con pruebas de verificación, ejecutarlo en su banco, verificar la documentación y obtener más una revisión en su karma, o Haz clic a ciegas en un par de docenas de parches en un par de minutos, dale +1 a cada uno y obtén más veinte en karma. Hubo casos cómicos en los que los ingenieros hicieron clic en parches tan rápido que dieron +1 a los parches automáticos del sistema CI. Como bromeamos más tarde, "ve, ve, jenkins". En el caso de las confirmaciones, también hubo muchas personas que revisaron el código con herramientas de formato de código, editaron comentarios, cambiaron puntos a comas y, por lo tanto, aumentaron su karma. Lidiar con esto es bastante sencillo: utilizamos el sentido común y, además de las métricas cuantitativas, también utilizamos las esenciales y cualitativas. El grado de uso de los resultados del trabajo del equipo, la cantidad de contribuyentes externos, el nivel de cobertura de las pruebas, la estabilidad de los módulos y de todo el producto, los resultados de las pruebas de escala y rendimiento, la cantidad de ingenieros que recibieron el hombro del revisor central. correas, el hecho de que los proyectos fueron aceptados en la comunidad de proyectos centrales, el cumplimiento de los criterios de las diferentes etapas del proceso de ingeniería: todos estos y muchos otros factores deben evaluarse junto con métricas cuantitativas simples.
Y finalmente, el tercer punto: nada de tonterías.
Los desarrolladores son personas muy inteligentes y extremadamente lógicas en su línea de trabajo. Pasan entre 8 y 10 horas al día construyendo cadenas lógicas largas y complejas, por lo que ven vulnerabilidades en ellas sobre la marcha. Al hacer algo, ellos, como todos los demás, quieren entender por qué lo hacen, qué cambiará para mejor. Es extremadamente importante que las metas que establezcas para tu equipo sean honestas y realistas. Intentar vender una mala idea a un equipo de programación es una mala idea. Una idea es mala si uno mismo no cree en ella o, en casos extremos, no tiene el estado interno de desacuerdo y compromiso (no estoy de acuerdo, pero lo haré). Una vez implementamos un sistema de motivación en una empresa, uno de cuyos elementos era un sistema electrónico de retroalimentación. Invirtieron mucho dinero, llevaron gente a Estados Unidos para capacitarse, en general, invirtieron al máximo. Una vez, en una conversación después del entrenamiento, uno de los gerentes dijo a sus subordinados: “La idea no es mala, parece que funcionará. Yo no te daré retroalimentación electrónica, pero tú se la das a tu gente y se la exiges”. Eso es todo, no se pudo implementar nada más. La idea, por supuesto, quedó en nada.
Fuente: habr.com