Hay 15 personas en mi estudio, la mitad de los cuales son programadores. El estudio se especializa en el desarrollo de tiendas en línea, por lo que los programadores son nuestro principal recurso.
Siempre se requieren tres cosas para los programadores
- Proyectos más rápidos para entregar.
- Manténgase en su propia evaluación de los costos laborales.
- Crecer y desarrollarse
Pero por varias razones, no siempre están listos para esto. En el artículo explicaré cómo motivamos a los programadores a mejorar en las tres áreas, qué dificultades encontraron y qué surgió.
¿Cómo comenzamos a enviar proyectos más rápido?
Hablaremos inmediatamente sobre por qué esto es importante: si un programador presenta un proyecto más rápido, la empresa gana más rápido al inicio y, en última instancia, el programador también gana más rápido. Dado que rápidamente pasa al siguiente proyecto, y el anterior va a apoyo y promoción. Parece que todo es obvio, sin embargo, vimos que los programadores no completan tareas y entregan proyectos tan rápido como pudieron, y decidimos ayudarlos a acelerar
Que motivado
Primera etapa
La primera opción era hacer que el salario del programador fuera la mitad del salario y la mitad de los bonos para el proyecto. Como resultado, la compañía y el desarrollador estarán "en el mismo barco", y el éxito de uno afectará directamente el éxito del segundo. Parece que todo es lógico, solo queda acelerar.
¿Qué se necesita para completar un proyecto más rápido?
Obviamente, necesitas programar más rápido. Como hacerlo Menos distracciones y todo es bueno para hacer de inmediato, para que no tenga que rehacerlo.
Pero aquí nos encontramos con otro problema: los programadores no siempre se distraen por su propia culpa o a voluntad. Por ejemplo, un gerente puede transferir a un programador para resolver problemas de apoyo a sus proyectos anteriores.
Además, entre el desarrollo y la entrega del proyecto hay un proceso de integración largo y problemático. Entonces, el programador recibió bonos por el desarrollo de un proyecto que aún no se entregó. Esto no parecía muy lógico, por lo que continuamos buscando opciones.
Segunda etapa
La segunda decisión fue pagar bonos al momento de la entrega del proyecto, y no al finalizar el proyecto.
Ahora, los programadores han empeorado aún más: no solo las tareas relacionadas influyeron en sus bonos de recepción, sino también, por ejemplo, la velocidad de proporcionar acceso al cliente para integrarse con el pago y la entrega (y a veces es varios meses), y la velocidad de sus especialistas de 1C (para la integración con 1C )
Además, en la etapa de programación, se revelan todos los errores de los pasos anteriores: planificación, diseño, diseño. Y el programador tiene que corregirlos prácticamente por un salario mínimo (y era muy pequeño en el marco de este sistema).
Resulta que el programador permanece sin bonificaciones (y son importantes) sin culpa propia.
Esta alineación era inaceptable y el experimento con bonos para proyectos tuvo que ser reducido.
Aquí, es hora de disculparse con el equipo de desarrollo por tales experimentos. Todavía estoy sorprendido de cómo no escaparon todos entonces.
El resultado del experimento fue la comprensión de que los programadores están bastante motivados para hacer la tarea rápida y bien, si no interfieren. Y no necesitan incentivos adicionales.
Entonces, ¿es necesaria la motivación material en este caso?
Lo necesito Una pequeña bonificación al finalizar el proyecto motiva al programador a no "trabajar mejor" (para nuestra experiencia, no necesita un incentivo), sino a profundizar en los campos relacionados. Por ejemplo, un programador, junto con un gerente de proyecto, estudia los diseños de diseño antes de mostrárselos a un cliente, buscando inconsistencias y áreas problemáticas en ellos. Como resultado, los proyectos son mucho más fáciles de programar y entregar al cliente.
La proporción de salario y bonificación al mismo tiempo al nivel del 80/20%.
Motivamos a adaptarse a su evaluación de costos laborales
Si es imposible entregar proyectos más rápido debido a la motivación material de los desarrolladores, entonces ¿quizás valga la pena motivar a los programadores para que se ajusten a sus propias estimaciones de los plazos para las tareas?
De qué se trata: según las estimaciones de la complejidad de las tareas, está planificado que los programadores trabajen; las tareas se establecen para la perspectiva a corto plazo (semana) y a largo plazo (1-2 meses). En consecuencia, si el programador no cumple con la fecha límite, entonces todo el cronograma de trabajo caerá, las fechas límite se moverán en proyectos que dependen de él, y así sucesivamente.
¿Cómo ayudar al programador a mantenerse dentro del plazo previsto?
Es posible recompensar si ha cumplido con la marca. Puede ser privado, si no se cumple.
Sin embargo, las decisiones primera y segunda sugieren que el punto aquí es únicamente en la motivación, y no en razones externas. Ya descubrimos que los programadores, si no se molestan, trabajan lo mejor posible.
Comenzamos a realizar retrospectivas para descubrir por qué una tarea en particular tomó más tiempo de lo planeado para encontrar "cuellos de botella" en la tarea misma, o en el contexto de su ejecución, o en el conocimiento del programador.
Esto ayudó, las tareas comenzaron a realizarse con mayor frecuencia en el tiempo asignado. Se hizo obvio que necesita averiguar sobre las tareas prolongadas antes de que caigan fuera de la fecha límite.
Para esto, se nos ocurrieron "retrospectivas preliminares". Cuando ha pasado más de la mitad del tiempo asignado para la tarea, y la tarea aún no está cerca de la mitad, el programador informa al gerente sobre esto, y juntos buscan razones.
Entonces, por lo que no puedes cumplir con la fecha límite para la tarea
La tarea fue inicialmente evaluada incorrectamente.
O bien la complejidad se evaluó incorrectamente o la solución elegida durante la evaluación no encajó al final. Esto significa que el programador tiene una brecha de conocimiento en un área particular. Importante! Esta información se usa para entrenamiento, no para castigar al programador.
La tarea ha crecido con detalles en el camino.
Si los detalles provienen del cliente y al principio no eran obvios, entonces el programador corrige la evaluación y el gerente vende las horas faltantes y cambia la fecha límite.
Si los detalles eran obvios, pero el gerente los echó de menos
Eso ya habla de las lagunas en el conocimiento del gerente. Entendemos que el gerente debe estudiar para que no surjan problemas similares.
¿Pero necesitas motivación financiera aquí?
Lo necesito Consideramos el premio por la cantidad de horas vendidas al cliente y calculadas por el programador. El objetivo sigue siendo el mismo: motivado para dar una evaluación precisa, el programador profundiza en la tarea, a veces lo dirige a aclarar, a veces ofrece sus propias versiones.
Formación de programadores y motivación para el desarrollo.
En la etapa retrospectiva, encontramos lagunas en el conocimiento de los programadores, pero ¿cómo lograr que estudien y cierren estas brechas?
Estamos ubicados en Krasnodar, y aquí en general hay un estudio de comercio electrónico (de hecho, nosotros). Esto significa que no hay ningún lugar para tomar personal ya preparado. Y todos necesitan crecer desde cero o "crecer" desde el nivel que tenían en otros estudios.
Lo que debe saber un programador
- Frontend
- Backend
- Motor
- Integración (1C y así sucesivamente)
- Linux, Nginx, Apache
Por lo tanto, tenemos 5 áreas de competencia. Cada uno de ellos tiene un cierto conjunto de habilidades a partir del cual se forma el mapa de competencia de un programador. Determina la división de los desarrolladores en niveles (Aprendiz, Junior, Medio, Senior).
A medida que aumenta el nivel, aumenta el salario.
Cómo criamos desarrolladores
Hipótesis 1
La primera idea era dar a los desarrolladores un mapa de competencias y materiales metodológicos y ofrecernos a nosotros mismos para desarrollarlo.
En Bitrix24, comenzamos tareas automáticas en las que todos tenían que informar sobre el progreso en la capacitación.
Y luego me encontré con el primer problema. Por alguna razón, los programadores no querían estudiar y no querían crecer en el mapa de competencias.
Después de un par de meses de intentos inútiles, supuse preguntarles: ¿qué está mal?
Resultó que hay demasiada diferencia en las competencias entre los diferentes niveles. Y ella no motiva a estudiar.
Hipótesis 2
Luego decidí dividir los niveles en varios niveles (como un porcentaje del mapa de competencia estudiado). Y para cada nivel para dar un pequeño aumento en el salario.
Se puso un poco mejor. Los programadores se acercaron para estudiar y tomar exámenes. Pero sigue siendo demasiado lento.
El siguiente problema quedó claro: no hay tiempo ni energía para estudiar materiales en casa, y en el trabajo, los programadores están ocupados con las tareas. Entonces, aquellos que tienen medio día de autoeducación gratuita avanzaron en el mapa de competencias, y aquellos que no se han mantenido en el mismo nivel, lo que los desmotivó fríamente.
Hipótesis 3
Dar tiempo libre. Entre tareas, los programadores comenzaron a salir varias horas a la semana para entrenarse.
Y así funcionó. Los programadores comenzaron a involucrarse en el autodesarrollo, tomar exámenes y aumentar los salarios.
Aquellos que no están listos para aprender, sujetos al tiempo asignado y las perspectivas de crecimiento, simplemente deben dejarse solos. Hay personas que se sienten cómodas a su nivel y si pueden cerrar algunas tareas, ¿por qué no?
Conclusiones
Según nuestra experiencia, los programadores tienen suficiente motivación interna y, si no se les molesta, funcionan lo mejor posible.
Los premios sirven como un motivador adicional, no tanto por la calidad del trabajo como por la inmersión en el trabajo de especialistas relacionados (busque áreas problemáticas en diseño y conocimientos tradicionales antes de que finalmente se acuerde).
Todas las herramientas de aprendizaje no tienen sentido a menos que haya dos cosas importantes. Sentimientos de progreso (incluidas las recompensas alcanzables) y el tiempo asignado para esto. Créame, cuando un programador, apenas logrando cerrar la tarea en un día, llega a su casa desde el trabajo una hora, luego de eso no está absolutamente a la altura de su "plan de desarrollo". Y estoy pensando que "aprenderás ahora y tendrás tiempo libre" dará lugar a una sola reacción silenciosa: "No creo".