Epígrafe:
El esposo, mirando a los niños mugrientos, le dice a su esposa: Bueno, ¿qué, lavamos estos o nuevos?Bajo el corte de la discusión de nuestro líder de equipo, así como Igor Marnat, director de desarrollo de productos RAS, sobre las características de la motivación del programador.
El secreto del éxito en la creación de productos de software geniales es bien conocido: tome un equipo de programadores geniales, dele una idea genial al equipo y no interfiera con el trabajo del equipo. Los desarrolladores geniales son raros y buscados. Algunos reclutadores incluso dicen que tienen la impresión de que dar a luz a un programador genial es más fácil que contratarlo en el mercado. Además de las dificultades con la contratación, como tal, la experiencia de cada desarrollador específico, su conocimiento de un producto existente y la historia de su desarrollo a menudo son insustituibles o se reponen duramente. Por lo tanto, si tiene suerte y ya tiene un excelente equipo de programadores, es importante trabajar en su motivación. Contratar, capacitar a nuevos desarrolladores, formar un equipo con ellos es casi tan difícil y tan largo como dar a luz y criar hijos.
Considere los principales factores que motivan a los programadores (equipos de programadores), utilizando la pirámide de Maslow para mayor claridad y estructuración de la presentación. Si de repente no has oído hablar de la pirámide de Maslow, esta no es una teoría indiscutible, pero muy popular y visual del psicólogo estadounidense Abraham Harold Maslow, quien propuso una teoría de la motivación de la personalidad basada en una jerarquía de necesidades humanas (ver imagen a continuación).
Maslow organizó las necesidades del individuo en un orden jerárquico, desde las necesidades fisiológicas hasta la necesidad de desbloquear el potencial y la autorrealización. Una suposición clave en la teoría de Maslow es: "Una persona no puede experimentar las necesidades de un nivel superior hasta que se satisfagan sus necesidades de un nivel inferior". Por ejemplo, una persona no puede ser impulsada por la necesidad de conocimiento o necesidades estéticas, si esta persona no durmió ni comió durante tres días.
Antes de profundizar en los detalles, detengámonos en el hecho obvio: el equipo está formado por personas, todas las personas son diferentes, cada una tiene su propia estructura de motivación. Además del hecho de que cada persona está impulsada por diferentes intereses, cada persona también se encuentra en diferentes condiciones de vida. Alguien está al comienzo de una carrera y está pensando en cómo construirla, alguien se va a casar y alguien quiere aprender una nueva área temática. Lo que es importante para uno no tiene importancia para el otro, y mañana todo volverá a cambiar. Para comprender correctamente este contexto, hay un medio simple: debe pensarlo y trabajar con él. Lo más importante es la comunicación.
Asegúrese de hablar con su equipo sobre algo que no sea trabajo, construir una relación informal.
Entonces, ahora veamos la pirámide de Maslow y consideremos sus niveles aplicados para administrar un equipo de programadores.
I: Necesidades fisiológicas, biológicas:Hablando de motivación, muchos, en primer lugar, a menudo piensan en el salario. En este caso, quiero decir con salario la parte constante del paquete de compensación, que no depende de los resultados. Esto no se aplica a las bonificaciones, bonificaciones y promociones de la empresa. Atribuiría el salario al nivel de "necesidades fisiológicas" en nuestro caso. Bonificaciones, bonificaciones según los resultados del trabajo, las opciones y las acciones de la empresa; todo esto me referiría a otros niveles.
En mi opinión, por extraño que parezca, el salario puede ser más un factor
desmotivador que motivador. La peculiaridad de trabajar con programadores es que son todas personas, en primer lugar, muy inteligentes (una característica de la profesión) y, en segundo lugar, profundas y / o ampliamente educadas. Por lo general, los programadores, además de su profesión, están profundamente versados en una o más de las áreas temáticas para las que crean productos. Además, los buenos programadores están interesados y conocen bien el historial de programación, algoritmos, estándares, etc. Lo mismo se aplica a su área temática. Para las personas de este nivel, el salario generalmente no es el principal factor de motivación.
Al mismo tiempo, la falta de un salario justo para los programadores en su comprensión desmotiva y desmotiva fuertemente. Tener un salario justo es la norma. El salario es mucho más alto que la norma (mercado); además, curiosamente, el factor es bastante desmotivador. Un colega me contó una vez acerca de un equipo de programadores en una de las grandes compañías animadas de Estados Unidos, que, por varias razones, recibían salarios del nivel de dos a tres veces el mercado. Como dijo, nunca había visto programadores más hartos, perezosos y desmotivados en su vida. El hecho de que un aumento salarial pueda motivar a corto plazo, pero después de unos meses, un nuevo salario se convierte en la norma y deja de motivar. En general, diría que para los programadores al comienzo de una carrera, el factor salarial es más importante, ya que crecen profesionalmente y se desarrollan; su importancia disminuye y otros factores comienzan a prevalecer.
El segundo punto importante es la presencia de un equilibrio justo en el nivel de salarios en el equipo. Si el equipo considera que la contribución de uno de los participantes es notablemente menor, pero el nivel de compensación no es diferente, esto desmotivará a todo el equipo. A veces, los gerentes tienen la tentación de inundar el fuego con dinero, para mantener a una persona quemada o desmotivada, elevando su salario por encima de la norma. Esto generalmente solo crea problemas a largo plazo: la motivación de la persona misma no crecerá especialmente, o crecerá en un par de meses, pero la motivación del resto del equipo disminuirá. En tales situaciones, vale la pena buscar otros enfoques, a menos que, por supuesto, este sea un especialista único que deba mantenerse a toda costa, incluso por un corto tiempo.
II La necesidad de seguridad, comodidad, constancia de las condiciones de vida:
Hace 70 años, la presencia de una estufa en un automóvil podría ser un factor motivador al elegir un automóvil, luego estaba por encima de la norma, era una señal de lujo. Ahora, incluso la ausencia de un aire acondicionado no tiene sentido, y su presencia no será un factor de motivación al elegir un automóvil. Hace 10-15 años, una oficina conveniente, buena plancha, delicioso café, ejercicio, un horario flexible, etc. podrían ser buenos factores de motivación, pero ahora es más bien la norma que un buen programador trabaje. Al mismo tiempo, su ausencia, nuevamente, desmotivará.
Un factor desmotivador importante es la falta de capacidad de concentración, un ambiente de trabajo ruidoso. El trabajo de un programador requiere silencio y concentración. Si el espacio de la oficina no brinda la oportunidad de proporcionar a los desarrolladores un lugar de trabajo aislado, es necesario al menos garantizar una colaboración cómoda entre colegas que no interfieran entre sí. Es mejor unir camaradas enérgicos y ruidosos entre sí, haciendo posible que aquellos que lo necesitan se concentren.
El costo del tiempo del programador ahora es notablemente más alto que el costo del hierro en el que trabaja. Dos o tres monitores, computadoras potentes, un lugar de trabajo conveniente para cada desarrollador, deberían ser la norma en cualquier empresa. Este tema está bien divulgado en uno de los artículos de Joel Spolsky "
La prueba de Joel: 12 pasos para mejorar el código".El componente físico de la comodidad es el más básico y simple, ahora hablemos del resto.
En muchas empresas, la norma para que los programadores trabajen es un horario de trabajo flexible y la falta de código de vestimenta. Esto es bueno y correcto si las características del equipo lo permiten (por ejemplo, no hay reuniones con clientes, políticos o banqueros).
Un punto importante es la presencia de una ventana de tiempo específica, cuando todo el equipo trabaja en conjunto localmente, para que las personas puedan comunicarse y resolver problemas en persona. El programador, de hecho, no deja el trabajo incluso después del trabajo. Por lo general, los momentos de trabajo se desplazan en su mente, independientemente de su presencia en la oficina, y las buenas decisiones a menudo salen de él. Dada la necesidad de ser bueno (que nos ocupamos más adelante), el control mezquino es perjudicial. No solo desmotiva, sino que también reduce el rendimiento. Como muestra la práctica, en ausencia de control, es probable que un equipo motivado trabaje más de lo necesario. Con control, los desarrolladores pueden sentarse en el teclado de nueve a seis, pero creo que el resultado será peor. Como dicen, una persona puede llevar un caballo a un lugar de riego, pero incluso cien no lo harán beber si no lo desea.
En la descripción de este nivel de necesidades, también se menciona la ausencia de ansiedad y miedo, la ausencia de caos, la necesidad de estructura y orden. Estos también son puntos extremadamente importantes que afectan en gran medida la atmósfera del equipo.
En primer lugar, la ausencia de caos, estructura y orden: el equipo debe comprender quién es responsable de qué, cómo se asignan los roles, qué hacer, quién, cuándo, qué requisitos están en el corazón del producto, cuáles son las expectativas de los jefes y el cliente ... La mayor parte de esto debería se describa formalmente, todo se debe discutir periódicamente. Sin discusión y uso periódico, las descripciones no funcionan. Es una buena práctica revisarlos y actualizarlos periódicamente después del análisis post mortem después del lanzamiento.
En segundo lugar, un ambiente tranquilo y agradable. Todos pasamos la mayor parte de nuestro tiempo en el trabajo, y queremos hacerlo sin estrés, conflicto o miedo. El equipo de desarrollo ya suele trabajar bajo la presión del cronograma y los clientes. Nadie necesita estrés adicional de colegas y superiores. El ambiente en el equipo, en general, el hecho de que un grupo de desarrollo puede ser llamado y ser un "equipo" es la responsabilidad directa e importante del gerente, una de las tareas más importantes a mediano y largo plazo. Por lo tanto, es importante que el gerente trabaje, en particular, con conflictos en el equipo, para no dejar que su desarrollo se desplace. El manejo de conflictos es un tema separado que merece un estudio separado.
Hay dos formas principales de influir en el estado emocional de un equipo, el comportamiento de los colegas (si alguien agrega en los comentarios, estará bien). El primero es su propio comportamiento. Un ejemplo personal es muy importante para el gerente y el equipo. Como dicen, lo que es pop, tal es la parroquia. Compórtate como esperas que se comporten tus colegas. El segundo es la promoción del comportamiento correcto y, por así decirlo, la des-promoción del mal. Comuníquese con las personas, hágales comentarios, hay muchas maneras de hacerlo. En general, la retroalimentación es un tema para otra discusión, es una parte importante e importante de trabajar con motivación.
Otro comentario sobre la atmósfera, que puede parecer inusual, pero en la práctica es importante. La mayoría de las veces, hay menos chicas en el equipo de desarrollo que hombres. A menudo los equipos son completamente masculinos. En tales condiciones, también bajo carga, a veces el vocabulario obsceno comienza a usarse en el equipo. La práctica muestra que esto afecta negativamente a la atmósfera, la comunicación gradualmente se vuelve grosera. Debe evitar usarlo usted mismo y no alentar su uso en un equipo.
Los equipos de desarrollo a menudo se denominan I + D (investigación y desarrollo), y la investigación es una parte importante del trabajo. Esta es la parte que generalmente es difícil de programar y planificar, de lo contrario no sería una investigación. Es importante que el equipo tenga derecho a cometer un error, a tomar la iniciativa, a probar diferentes opciones que pueden terminar con éxito o no. Los errores son una parte normal del trabajo, no se pueden evitar, pero puedes estudiarlos, analizarlos, aprender de ellos para el futuro y seguir adelante. El principio 5 por qué, que se originó en Toyota, ayuda a llegar a la raíz del problema. Castigar los errores es una excelente manera de crear una atmósfera de miedo e inseguridad. La única excepción es cuando, de acuerdo con los resultados del análisis, resulta que el error es causado por una actitud poco profesional hacia el trabajo, en este caso, puede ser necesario tomar decisiones de personal.
El ambiente en el equipo está muy influenciado por sus expectativas, el estado emocional antes de que comience la conversación. Antes de comenzar una discusión difícil, es importante algún tipo de informe, o simplemente una conversación emocional, su actitud, actitud hacia la persona con la que va a hablar. Siempre pienso por defecto y actúo sobre la base de lo que una persona sinceramente trató de hacer lo mejor. Si ve que este no es el caso, debe averiguar con calma y profundidad el contexto y comprender lo que hizo bien, por qué pensó que era lo correcto y dónde divergen nuestras expectativas. Por lo general, resulta que realmente no divergen, solo su visión del contexto es más completa o fresca, y usted no sabía algo. O, por el contrario, no sabía algo. Esto es especialmente importante en un equipo distribuido, cuando las personas tienen menos probabilidades de comunicarse en persona, usan el correo y la mensajería instantánea. Esto es aún más crítico en un equipo formado por programadores de diferentes países y distribuidos entre diferentes zonas horarias. Aquí, las diferencias culturales comienzan a jugar un papel importante.
En una situación difícil, moverse sobre la marcha es simple, muy simple, pero luego es difícil retroceder y el sedimento permanece durante mucho tiempo. Daré un ejemplo simple de la experiencia reciente. Uno de los gerentes del equipo necesitaba con urgencia comentarios sobre el problema de un cliente de un gerente de un equipo adyacente de otro país. Llamó a un colega en el mensajero, esperó 15 minutos, volvió a sonar, luego, 15 minutos más tarde, entró en una gran conversación en la que había otros gerentes y se encontró con un colega, con la frase: "ya que no te dignas a responderme, tal vez , y la pregunta no es tan urgente? Como resultado, resultó que nuestro mensajero corporativo era un poco aburrido, y el colega no vio la pregunta en absoluto. Tuve que disculparme. En general, es mejor comenzar por lo bueno. Siempre es posible cometer un error y atropellarlo más tarde, no hay problemas con esto (aunque no debe hacer esto). En general, durante más de 20 años de trabajo en nuestra industria, conocí a un colega realmente malicioso solo una (!) Vez. Afortunadamente, nos separamos bastante rápido. La suposición de que los colegas quieren lo mejor, según lo mejor de su visión del contexto, es correcta en la gran mayoría de los casos.
Su tarea como gerente es garantizar la sincronización de los contextos, una comprensión común de las expectativas, requisitos y plazos adoptados por el equipo de estándares. Puede parecer insignificantes, pero la atmósfera en el equipo está construida precisamente a partir de tales insignificancias. Desde el punto de vista de un equipo distribuido, una de las tareas importantes es garantizar la comunicación personal periódica de los miembros del equipo. A menudo escuché de los programadores que, por ejemplo, después de que los ingenieros del equipo de soporte vinieron a ellos y trabajaron juntos en persona, felizmente se quedaron en el trabajo para ayudar personalmente en un caso difícil a Pasha, quien recientemente los visitó, aunque antes Pasha era solo un ícono en el mensajero, y nadie se demoraría por el ícono.
Por cierto, hablé sobre el equipo de soporte y recordé un ejemplo canónico para mí. De alguna manera, uno de los clientes en Estados Unidos tuvo un problema con el producto, uno de los ingenieros del equipo de soporte que trabajó en su implementación (enviado desde Rusia) permaneció después del trabajo para ayudar, pero el problema no se resolvió y no se resolvió. En general, se demoró y se quedó allí sentado casi hasta la mañana. En este momento, los gerentes de clientes intensificaron el problema, identificaron su criticidad para ellos y dejaron el trabajo por la noche. El proceso de escalada ya estaba ganando impulso en otra zona horaria, los gerentes de soporte en Rusia comenzaron a tratar de ayudar, debido a ciertas dificultades para comunicarse con la oficina del cliente (VPN, problemas de comunicación, dificultades con las llamadas entre países, ...) no sabían que el tipo ya estaba sentado. en la oficina y resuelve el problema, y trató de encontrarlo. Encontrado solo en la mañana (estadounidense), cuando el problema ya estaba prácticamente resuelto por él, y el producto se ganó. Comenzaron a correr hacia la cantera, qué demonios, el cliente tiene tal escalada, nada funciona, dónde te lleva, no podemos encontrarte, etc. No hace falta decir que, como resultado de tal comportamiento, el tipo estaba muy desmotivado. Organizar un equipo distribuido es un gran tema separado, pero hay dos cosas a tener en cuenta. En primer lugar, la comunicación, la atmósfera es muy importante, el éxito del trabajo depende de ello. En segundo lugar, esto no funciona por sí solo, debe tratarse por separado y en profundidad.
Otro punto importante relacionado con este nivel de necesidades es el salario nuevamente. No el tamaño del salario, como tal, sino la existencia de un cierto orden de cambio. La empresa debe tener un enfoque para determinar los requisitos para puestos en diferentes niveles. Cada desarrollador debe poder discutir las expectativas de su trabajo con la empresa, para comprender cómo él y cuándo sus esfuerzos pueden afectar su salario. Reuniones periódicas con el gerente, certificaciones semestrales o anuales sirven para este propósito. Este, nuevamente, es uno de esos momentos cuya presencia no motiva explícitamente, pero su ausencia motiva fuertemente.
De la necesidad de orden y la disponibilidad de reglas, se sigue la necesidad de cumplir con estas reglas, de seguir las reglas adoptadas por el equipo, tanto formales como informales. En general, la llamaría la necesidad de "ser buena". La presencia de esta necesidad confirma que la microgestión no es necesaria, sino más bien perjudicial. Es suficiente proporcionar a una persona todo lo necesario para el trabajo, darle conocimiento del contexto, las prioridades y proporcionar libertad de acción y toma de decisiones a su nivel. , , .
, — , . . . , , . , , . — , , , . “
Google — Site Reliability Engineering ”, , , , , .
Continuará ...