Gestión de un equipo de programadores: ¿cómo y cómo motivarlos correctamente? Parte dos

Epígrafe:
El esposo, mirando a los niños mugrientos, le dice a su esposa: Bueno, ¿qué, lavamos estos o nuevos?

Bajo el corte, la segunda parte del artículo del líder de nuestro equipo, así como el director de desarrollo de productos RAS - Igor Marnat sobre las características de la motivación del programador. La primera parte del artículo se puede encontrar aquí: habr.com/en/company/parallels/blog/452598




En la primera parte del artículo, mencioné 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 - La necesidad de afiliación y amor



Sabía que la mafia italiana se llama "Cosa Nostra", pero quedé muy impresionado cuando aprendí a traducir "Cosa Nostra". "Cosa Nostra" en traducción del italiano - "Nuestro negocio". La elección del nombre es muy exitosa para la motivación (dejemos de lado la ocupación, en este caso solo nos interesa la motivación). Una persona generalmente quiere ser parte de un equipo, hacer algo grande y común, nuestro negocio.

Se le da gran importancia a satisfacer la necesidad de pertenencia y amor en el ejército, en la marina, en cualquier gran formación militarizada. Y, como vemos, en la mafia. Esto es comprensible, porque necesita forzar a las personas que tienen poco en común, que inicialmente no forman un equipo de personas de ideas afines, reunidas en una apelación (no voluntariamente), tienen diferentes niveles de educación, diferentes valores personales, literalmente dedican sus vidas, con riesgo mortal, a alguna causa común. , confía la vida a un compañero de armas.

Esta es una motivación muy fuerte, para la mayoría de las personas es extremadamente importante tener ganas de pertenecer a algo más, saber que eres parte de una familia, un país o un equipo. En el ejército, estos objetivos son la forma, varios rituales, desfiles, marchas, pancartas, etc. Los mismos factores son importantes para cualquier equipo. Los símbolos, una marca corporativa y colores corporativos, atributos y recuerdos son importantes.

Es importante que los eventos significativos tengan una forma de realización visible con la que puedan estar asociados. Ahora para que la empresa tenga sus propios atributos, chaquetas, camisetas, etc., más bien la norma. Pero también es importante destacar un equipo dentro de la empresa. A menudo emitimos camisetas en función de los resultados del lanzamiento, que se emiten a todos los involucrados en este lanzamiento. Cualquier evento, celebración conjunta o evento de todo el equipo es otro factor de motivación importante.

Además de los atributos externos, algunos factores más influyen en el sentimiento de pertenencia a un equipo.
Primero, la existencia de una meta común que todos entienden es compartida por una evaluación de su importancia. Los programadores generalmente quieren entender lo que hacen algo genial, y lo hacen juntos, en equipo.
En segundo lugar, un equipo debe tener un espacio de comunicación en el que haya un equipo completo y que solo le pertenezca (por ejemplo, un chat en el messenger, sincronizaciones periódicas del equipo). Además de los problemas de trabajo, la comunicación informal, a veces discutiendo eventos externos, una luz apagada, todo esto forma 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 en comparación con los adoptados por la empresa. La implementación de los mejores enfoques adoptados en la industria, primero en el equipo y luego en la empresa en general, le da al equipo la oportunidad de sentir que está por delante de los demás de alguna manera, va a la cabeza, esto crea un sentimiento de pertenencia a un equipo genial.

La propiedad del equipo en la planificación y gestión también afecta el sentido de propiedad. Cuando los miembros del equipo participan en la discusión de los objetivos del proyecto, el plan de trabajo, los estándares y las prácticas de ingeniería del equipo, entrevistando a nuevos empleados, tienen un sentimiento de participación, copropiedad, influencia en el trabajo. Las personas están mucho más dispuestas a llevar a cabo decisiones tomadas y expresadas por sí mismas que las propuestas por otros, incluso si son prácticamente consonantes.

Cumpleaños, aniversarios, eventos importantes en la vida de los colegas: una pizza conjunta, un pequeño regalo del equipo dan una cálida sensación de participación y aprecio. En algunas empresas, es costumbre dar pequeños carteles conmemorativos por 5, 10, 15 años de trabajo en la empresa. Por un lado, no creo que sea tan motivador para nuevos logros. Pero, obviamente, casi todos estarán contentos de no haberse olvidado de él. Este es uno de esos casos donde la ausencia de un hecho motiva más que su presencia motiva. De acuerdo, puede ser una lástima que por la mañana el linkedin te haya recordado y felicitado por tu décimo aniversario en el lugar de trabajo, y ningún colega de la empresa lo haya felicitado o recordado.

Por supuesto, un punto significativo es el cambio en la composición del equipo. Está claro que incluso si la llegada o salida de alguien del equipo se anuncia de antemano (por ejemplo, en una lista de correo de una empresa o equipo, o en una reunión de equipo), esto no motiva particularmente a nadie a hacer nuevos logros. Pero si un día ves a una nueva persona a tu lado, o no ves a una vieja, esto puede ser una sorpresa, y si te vas, es realmente desagradable. La gente no debe desaparecer en silencio. Especialmente en un equipo distribuido. Especialmente si su trabajo depende de un colega de otra oficina que de repente recogió y desapareció repentinamente. Tales momentos claramente valen una comunicación separada dentro del equipo por adelantado.

Un factor importante, que se llama propiedad en inglés (la traducción literal de "propiedad" no refleja completamente su significado). Este no es un sentimiento de propiedad, sino más bien un sentido de responsabilidad por su proyecto, un sentimiento cuando se asocia emocionalmente con el producto y el producto consigo mismo. Esto corresponde aproximadamente a la oración del marine de la película "Full Metal Shell": " Este es mi rifle. Hay muchos de estos rifles, pero este es el mío. Mi rifle es mi mejor amigo. Ella es mi vida Debo aprender a ser dueño de la forma en que soy dueño de mi vida. Mi rifle es inútil sin mí. Soy inútil sin mi rifle. Tengo que disparar mi rifle adecuadamente. Tengo que disparar con mayor precisión que el enemigo que intenta matarme. Tengo que dispararle antes de que me dispare. Que así sea ... ".

Cuando una persona trabaja en un producto durante mucho tiempo, tiene la oportunidad de asumir la plena responsabilidad de su creación y desarrollo, para ver cómo una cosa de trabajo surge de "nada", cómo la gente lo usa, surge este sentimiento poderoso. Los equipos de productos que trabajan juntos durante mucho tiempo en un proyecto generalmente están más motivados y unidos que los equipos reunidos por un corto tiempo y trabajando en modo de línea de ensamblaje con el cambio de un proyecto a otro sin la responsabilidad total del producto completo, de principio a fin.

IV. Necesidad de reconocimiento

Buena palabra y amable con el gato. Todos están motivados por el reconocimiento de la importancia de su trabajo, su evaluación positiva. Habla con los programadores, dales retroalimentación periódica, marca un trabajo bien hecho. Si tiene un equipo grande y distribuido, las reuniones periódicas (lo que se llama uno a uno) son excelentes para esto, si el equipo es muy pequeño y trabaja en conjunto a nivel local, esta característica generalmente se proporciona sin reuniones especiales en el calendario (aunque el periódico uno a uno es todo igualmente necesario, puede gastarlo con menos frecuencia). Este tema está bien cubierto en podcasts de administrador en manager-tools.com.

Al mismo tiempo, vale la pena tener en cuenta las diferencias culturales. Algunos enfoques familiares para los colegas estadounidenses no siempre funcionarán con los rusos. Al principio, el nivel de cortesía aceptado en la comunicación diaria en equipos en países occidentales parece ser excesivo para los programadores de Rusia. Alguna sencillez característica de los colegas rusos puede ser percibida como grosera por sus colegas de otros países. Esto es muy importante en la comunicación en un equipo internacional, se ha escrito mucho sobre este tema, el gerente de dicho equipo definitivamente debe recordar esto.

La demostración de características en las que los programadores muestran características desarrolladas para correr es una buena práctica para darse cuenta de esta necesidad. Además del hecho de que esta es una gran oportunidad para despejar los canales de comunicación entre los equipos, para presentar a los gerentes de producto y probadores con nuevas características, también es una buena oportunidad para que los desarrolladores muestren los resultados de su trabajo, para indicar su autoría. Bueno, y pulir las habilidades de hablar en público, por supuesto, que no siempre es perjudicial.

Sería una buena idea notar la notable contribución de colegas particularmente distinguidos con cartas, recuerdos (al menos con una palabra amable) en las fiestas conjuntas del equipo. Las personas generalmente aprecian tales letras y carteles conmemorativos, los llevan consigo cuando se mueven y, en general, los cuidan de todas las formas posibles.

Para marcar una contribución más significativa a largo plazo al trabajo del equipo, la experiencia acumulada y la experiencia, a menudo utilizan un sistema de clasificación (de nuevo, puede establecer una analogía con el sistema de rango militar en el ejército, que, además de garantizar la subordinación, también sirve para este propósito). A menudo, los desarrolladores jóvenes inyectan venganza para obtener nuevas estrellas en las correas de los hombros (es decir, pasar del desarrollador junior al desarrollador a tiempo completo, etc.).

Es imprescindible conocer las expectativas de su gente. Alguien está bastante motivado por un alto grado, la capacidad de ser llamado, por ejemplo, un arquitecto, mientras que alguien, por el contrario, es indiferente a los grados y títulos y considerará un aumento en el salario como un signo de reconocimiento por parte de la empresa. Comuníquese con las personas para comprender lo que quieren, cuáles son sus expectativas.

Una demostración de reconocimiento, una manifestación de un mayor nivel de confianza por parte del equipo puede servir para proporcionar una mayor libertad de acción o participación en nuevas áreas de trabajo. Por ejemplo, con la acumulación de cierta experiencia, el logro de ciertos resultados, el programador, además de implementar sus características de acuerdo con la especificación, puede trabajar en la arquitectura de cosas nuevas. O participe en el trabajo en nuevas áreas que pueden no estar directamente relacionadas con el desarrollo: automatización de pruebas, implementación de las mejores prácticas de ingeniería, asistencia en la gestión de lanzamientos, conferencias en conferencias, etc.

V. La necesidad de conocimiento y autorrealización.

Muchos programadores están orientados en diferentes etapas de sus vidas a diferentes tipos de actividades en la programación. A alguien le gusta participar en el aprendizaje automático, desarrollar nuevos modelos de datos, mientras lee mucha literatura científica para el trabajo, creando nuevos desde cero. La depuración y el soporte de una aplicación existente está más cerca de otra, en la que necesita profundizar en el código existente, estudiar registros, apilar pistas y captchas de red durante días y semanas, y apenas escribir código nuevo.

Ambos procesos requieren grandes esfuerzos intelectuales, pero la salida práctica es diferente. Se cree que los programadores son reacios a respaldar las soluciones existentes, es más probable que estén motivados para desarrollar otras nuevas. Hay un grano saludable en él. Por otro lado, el equipo más motivado y más unido con el que he trabajado fue específicamente apoyar el producto existente, encontrar y corregir errores después de contactar al equipo de soporte. Los chicos literalmente vivieron este trabajo, estaban listos para ir los sábados y domingos. En una ocasión tratamos voluntariamente otro problema urgente y complejo, ya sea en la tarde del 31 de diciembre o en la tarde del 1 de enero.

Esta alta motivación fue influenciada por varios factores. En primer lugar, era una empresa con un gran nombre en la industria, el equipo se asoció a ella (ver "Necesidad de afiliación"). En segundo lugar, eran la última frontera, no había nadie detrás de ellos, el equipo de producto ya se había ido en ese momento. Entre ellos y los clientes había dos niveles de apoyo, pero si el problema los alcanzaba, no había dónde retirarse, detrás de nadie, toda la corporación está en ellos (cuatro programadores jóvenes). En tercer lugar, esta gran empresa tenía grandes clientes (gobiernos nacionales, empresas de automóviles y aviación, etc.) e instalaciones a gran escala en varios países. Como resultado, siempre problemas complejos e interesantes, los problemas simples se resolvieron apoyando los niveles anteriores. Cuarto, 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 geniales), y siempre estábamos seguros de la calidad de los datos que prepararon, el análisis que realizaron, etc. Quinto, y creo que este es el momento más importante: el equipo era muy joven, todos los muchachos estaban al comienzo de su carrera. Fue interesante para ellos estudiar un producto grande y complejo, resolver problemas nuevos y serios para ellos en un nuevo entorno para ellos, buscaron conocer profesionalmente el nivel de los equipos, problemas y clientes de los alrededores. El proyecto resultó ser una excelente escuela, todos hicieron una buena carrera en la empresa y se convirtieron en líderes técnicos y gerentes senior, uno de los chicos ahora es gerente técnico en Amazon Web Services, el otro se mudó a Google con el tiempo, y todos aún recuerdan este proyecto con calidez. .

Si este equipo estuviera formado por programadores con 15-20 años de experiencia, la motivación sería diferente. La edad y la experiencia no son, por supuesto, factores determinantes al 100%, 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 un excelente resultado.

En general, como hemos mencionado repetidamente, debe conocer las expectativas de sus programadores, comprender cuáles de ellos desearían expandir o cambiar el alcance de las actividades y tener en cuenta estas expectativas.

Fuera de la pirámide de Maslow: visibilidad, gamificación y competencia, sin tonterías

Hay otros tres puntos importantes con respecto a la motivación de los programadores que deberían mencionarse, pero atraerlos al modelo de necesidades de Maslow sería demasiado artificial.

El primero es la visibilidad y la proximidad del resultado.

El desarrollo de software suele ser un maratón. Los resultados de los esfuerzos en I + D se hacen visibles después de meses, a veces años. Es difícil llegar a una meta que está más allá del horizonte, la cantidad de trabajo es aterradora, la meta está lejos, no está clara y no es visible, "la noche es oscura y está llena de horrores". Es mejor dividir el camino en partes, allanar el camino hacia el árbol más cercano, que es visible, alcanzable, la forma es clara y no está lejos de nosotros, y ve a este objetivo cercano. Queremos hacer un esfuerzo de unos días o semanas, obtener y evaluar el resultado y luego seguir adelante. Por lo tanto, el trabajo debe dividirse en partes pequeñas (los sprints en ágil sirven bien para este propósito). Hicieron parte del trabajo: grabaron, exhalaron, discutieron, castigaron a los culpables, otorgaron a los no invitados: puede comenzar el siguiente ciclo.

Esta motivación es, en cierta medida, similar a la que experimentan los jugadores cuando juegan juegos de computadora: reciben periódicamente medallas, puntos, bonos al pasar cada nivel, esto se puede llamar "motivación de dopamina".

Además, la visibilidad del resultado es literalmente importante. Una característica cerrada en la lista debería volverse verde. Si el código está escrito, probado, contaminado, pero no hay cambios en el estado visual visible para el programador, se sentirá incompleto, 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: la compilación se ensambló y las pruebas pasaron, el parche pasó el código de revisión y el parche se agotó. Cada etapa se marcó visualmente con una marca verde o una cruz roja. Una vez, uno de los desarrolladores se quejó de que el código de revisión dura demasiado, los colegas deben acelerar, los parches se cuelgan durante varios días. Le pregunté qué, en esencia, está cambiando para él. Después de todo, cuando se escribe el código, se ensambla la compilación y se pasan las pruebas, no es necesario prestar atención al parche enviado si no hay comentarios. Los colegas harán la revisión ellos mismos y los mantendrán bajos (si, de nuevo, no hay comentarios). Él respondió: "Igor, quiero obtener mis tres marcas verdes tan pronto como sea posible".

El segundo punto es la gamificación y la competencia.

Al desarrollar uno de los productos, nuestro equipo de ingeniería tenía el objetivo de tomar una posición destacada en la comunidad de uno de los productos de código abierto, ingresando en el 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 declarar (y declarar periódicamente) que era el contribuyente número uno, pero no había una forma real de comparar la contribución de los participantes entre sí, para evaluar su dinámica en tiempo En consecuencia, no había forma de establecer una meta para el equipo, que podría medirse en algunos loros, evaluar el grado de logro, etc. Para resolver este problema, nuestro equipo ha desarrollado una herramienta para medir y visualizar la contribución de empresas y contribuyentes individuales www.stackalytics.com . En términos de motivación, resultó ser solo una bomba. No solo los ingenieros y los equipos monitorearon constantemente su progreso y el progreso 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 claro, todos podían monitorear cuidadosamente su progreso, compararlo con sus colegas, etc. Se ha vuelto conveniente y fácil establecer objetivos para ingenieros, gerentes y equipos.

Un punto importante que surge al introducir cualquier sistema de métricas cuantitativas es que tan pronto como las haya implementado, el sistema busca priorizar automáticamente el logro de estas métricas cuantitativas, en detrimento de las cualitativas. , . , -, , , , , , +1 . , , +1 CI . , “go, go, jenkins”. , , , . : , . , , , , scale performance , , core reviewer, core projects , — .

, — No bullshit.

— , . 8-10 , . -, , , , , . , , , . — . , , , , disagree and commit ( , ). - , . , , , . - : « , , . , , ». , . , , .