¿Qué problemas de liderazgo de equipo se pueden resolver con la ayuda del juego?

Hola a todos! Mi nombre es Yevgeny Rtischev, en Sbertekh trabajo como jefe de desarrollo de sistemas de TI en los proyectos del Sistema Frontal Unificado. El 24 de septiembre, hablé en la conferencia Saint Teamlead Conf 2018 en San Petersburgo. Mi informe fue sobre el juego celebrado en el equipo, que alivió en gran medida mi dolor de cabeza como líder, me ayudó con la motivación y la disciplina. La audiencia aceptó muy calurosamente el tema y formuló muchas preguntas interesantes y valiosas.

Me pareció que algunos puntos en el informe se perdieron. Por lo tanto, en el artículo, decidí volver a hablar sobre mi experimento y compartir los resultados. Quien no haya asistido a la conferencia y quiera leer una historia sobre una herramienta alternativa para una Revisión rápida del desempeño, administrar un equipo a través de un juego, aumentar la participación en el desarrollo de productos y cómo combinar los conceptos de "gamificación" y burocracia en grandes empresas, bienvenido .

Introducción

A continuación, habrá una narración consistente sobre mi devenir como líder de equipo, problemas conscientes y errores cometidos. No lo esconderé: la solución es introducir un juego de equipo especial, así que si no tienes el deseo y el interés de pasar 10-15 minutos de tu valioso tiempo, puedes saltar a la sección "Ahora todos están explotando MotC" y leer directamente sobre la esencia del juego, errores de cálculo en equilibrio y ajuste , así como lo que vino de eso.

Problemas y dolor

Cuando llegué a Sberteh, comenzó un nuevo programa interno y era necesario reunir rápidamente un equipo de desarrollo móvil. Un mes después de que me fui, mi gerente (que me estaba contratando) renunció, y todas sus tareas y problemas se volvieron míos. Honestamente, antes de eso tenía poca experiencia en la gestión de un equipo de dos personas durante un año. Más bien, fue como tutoría técnica y tutoría de nuevos desarrolladores. El equipo se expandió rápidamente a 11 personas, evité completamente escribir código, desarrollar arquitectura y otras tareas difíciles. Me volví susceptible a las emociones y mis principios de gestión correspondían a la gestión situacional, y tuve que mirar a más largo plazo, desarrollar personas en el equipo, formar nuevos líderes, marcar y alentar a aquellos que son buenos tirando, y también identificar y castigar a los "malos" y las personas perezosas.

Vi una salida en la introducción de elementos de gestión regular. Es decir necesitaba un sistema con reglas transparentes para recompensas y castigos. Al mismo tiempo, realmente no quería reducir todo a
métodos comunes, cuya reacción siempre resulta ser la opuesta.



Primero, decidí hacer una lista de problemas condicionales, o más bien, esas cosas que haría
Quería mejorar como equipo. Por ejemplo, quería que los muchachos no llegaran tarde al stand-up, que se prepararan, que se escucharan cuidadosamente y que ayudaran a resolver los problemas. A muchas personas no les gusta hacer stand-ups o diariamente, porque considéralo una pérdida de tiempo de trabajo.

El primer paso fue cambiar el idioma que hablamos en la ceremonia ágil: comenzamos a hacer un stand-up en inglés. La decisión fue decisiva: muchos prepararon el texto con anticipación, la duración se redujo (el inglés era lacónico y todos intentaron concentrarse solo en la esencia).

Y luego me di cuenta de que necesitaba experimentar

Formulamos áreas problemáticas.

La tendencia al pensamiento sistémico me dijo que para hacer algo, primero es necesario formular problemas o, más precisamente, aquellas cosas que me gustaría mejorar. Entonces yo
resumió las principales áreas.

Clasificación de miembros del equipo

Nuestra empresa tiene una línea de calificaciones: estos son ciertos niveles que tienen sus responsabilidades formales, privilegios y tenedores salariales. La alineación real de las fuerzas a menudo difiere de la formal por razones obvias: la cantidad de vacantes y sus calificaciones es limitada, todos los muchachos vinieron al equipo en diferentes momentos y bajo diferentes condiciones, alguien mostró un fuerte crecimiento en poco tiempo, etc. El procedimiento de actualización es complejo, lo suficientemente raro y necesita estar bien preparado para ello, es decir. nominar objetivamente a las personas que lo merecen. En el primer procedimiento de este tipo, estaba muy equivocado: dado que me resultaba difícil recordar todos los méritos o fracasos de los individuos, procedí de mi opinión subjetiva, tal vez en algunos lugares debido a mi propia disposición. Y esto está mal.

Los errores en tales situaciones son muy difíciles de corregir. Y me equivoqué por primera vez (un minuto de confesión). Pero las experiencias negativas son un buen maestro. Me di cuenta de que necesitamos una herramienta clara: un indicador simple para ver todos los logros y fracasos de una persona, en qué áreas está creciendo. La información siempre debe ser accesible y relevante, y está bien ser pública, entonces todos los miembros del equipo tendrán menos preguntas con los próximos cambios.

Asistencia para el desarrollo de productos

Cuando llegué, la empresa trabajaba de acuerdo con el modelo de cascada: de hecho, el banco era el cliente y el equipo de Sberbank-Technologies era el contratista interno. Un año después, la compañía cambió a Agile grande: los equipos se descentralizaron y se centraron en el desarrollo de sus propios productos (que podrían ser submódulos de uno grande
sistemas). Sobre los hombros del propietario del producto de dicho equipo, además de la gestión lineal y el arquitecto de servicios (en el caso de un producto técnico), también había una nueva función: la gestión del producto, es decir la formación de su visión, un mapa estratégico de desarrollo, detallado y priorización de tareas, así como la responsabilidad del momento de la implementación.

Y yo, como propietario del producto, realmente quería que los miembros del equipo no solo cumplieran con sus tareas, sino que también ayudaran al producto a crecer, aportar nuevas ideas frescas, quitarme parte de mis responsabilidades y dolor de cabeza. Por ejemplo, se dedicó mucho tiempo a recopilar requisitos, desarrollarlos y descomponerlos en tareas lógicas y secuenciales específicas. Otro problema fue el soporte del producto y la comunicación con los usuarios. Nuestro producto es una biblioteca interna para desarrollar aplicaciones móviles de iOS (ya hay una serie completa de artículos sobre Habr sobre esto). Y nuestros consumidores son otros equipos de aplicaciones. En algún momento, el número de nuestros usuarios alcanzó aproximadamente 120 desarrolladores, diseñadores y gerentes. Y ni siquiera tenía 12 horas al día para comunicarme con todos. Realmente quería que el equipo ayudara activamente en esto.

Precisión de planificación y determinación del tiempo

Durante mucho tiempo, nuestros indicadores de Story Points (en adelante, SP) saltaron fuertemente de sprint a sprint. Cada vez, ocurrió una situación similar debido a defectos de llegada de PROM o
algunas tareas super importantes no planificadas directamente del liderazgo. Los muchachos se quejaban regularmente y no estaban satisfechos, porque no podían entender a dónde se había ido el tiempo, si la tarea recién recibida era más importante que el sprint, qué valor aportaría al producto. Complejidad agregada y el enfoque generalmente aceptado para evaluar defectos en 0 SP: siempre agregué al sprint
cierto número de defectos para que puedan intercambiarse con los críticos que llegaron justo durante el sprint.

Algo fresco y nuevo

Después de dos años de trabajar en un producto y en el mismo equipo, las personas comienzan a cansarse, sus ojos pierden su brillo loco y su productividad disminuye.
La solución que tuvo que inventarse fue encender la luz de nuevo y un poco
animar al equipo.

Un poco sobre el equipo

Me gustaría hablar un poco más sobre el equipo: el propietario del producto, el analista (también conocido como Scrum Master) y 9 desarrolladores de iOS. ¿Entiendes ahora por qué quería entender el equilibrio de poder en un equipo tan homogéneo?



Algunos datos sociales: tuvimos dos niñas y la edad de los participantes estaba en
oscilan entre 22 y 33. Las áreas de interés eran diferentes, pero tratamos de organizar
actividades generales del equipo: juegos de mesa regulares, mini eventos corporativos,
viajes conjuntos a conferencias, etc.

Ahora todos están minando MotC

Siempre he tenido un gran interés en la industria del juego. Cuando era niño, construí mundos enteros a partir de cubos de lego, dibujé juegos de mesa simples en una hoja de papel, me volví adicto a 3D Max y luego comencé a aprender herramientas simples para crear juegos de computadora, como Dark Basic o Game Factory. Pasé mucho tiempo en MMO, y desde lo más extraño: hice mi propia versión del juego Diablo 2 en el editor de mapas para Warcraft 3 (incluso disfrutó el éxito en la red local de la ciudad).

Como entiendes, una vez más, quería crear un mundo de juegos y sumergirme
miembros del equipo en desafío en tiempo real



Los juegos, por sí mismos, contienen una base muy útil, a saber: competencia, puntos y clasificaciones, reglas y violaciones, logros individuales y de equipo. Los juegos infectan con emoción (que en nuestro caso es similar a la participación), y también enseñan la amargura de la derrota y las alegrías de la victoria.

Lo único que queda es elegir un entorno, elaborar mecánicas y reglas, equilibrar el equilibrio y también trabajar en la viralidad condicional.


La mayor parte de mi informe sobre Saint Teamlead Conf se dedicó a crear el juego y completar todos los puntos necesarios (jugabilidad, problemas de equilibrio, psicología de 4 tipos de jugadores, etc.). No traduciré toda esa información en texto; espero que los lectores interesados ​​esperen seis meses cuando olegbunin haga públicas las entradas (o me escriba en privado). También puede venir a escuchar la conferencia principal del equipo el 2 de noviembre .

¿Cómo obtener MotC?

En resumen, puede obtener monedas virtuales para realizar ciertas acciones:
1. Cierre de tareas de sprint. Esto es importante y debe alentarse, porque esto es lo que aporta valor comercial. 1 Story Point trajo 1.2 MotC. ¿Por qué no es el mismo valor? Sí, es simple: en primer lugar, el número mágico ya dice que hay algún tipo de coeficiente y, una vez que se ha indicado su presencia, siempre se puede cambiar con cuidado (para ajustar el equilibrio). Plus MotC - entero, es decir También es un incentivo adicional para cerrar un mayor número de puntos de historia. Por 3 obtienes 3 Motc, y por 5 ya 6.

2. Corrección de defectos. Dado que no hay evaluación en SP, que sea en MotC. Diferentes niveles de criticidad tenían diferente peso en términos de MotC. Pero, de nuevo, para alentar la corrección de defectos (que no todos los desarrolladores desearían), un error cerrado siempre trae un número fraccionario de monedas, que podría redondearse hacia abajo si no se cierra un defecto más.

3. Corrección de tareas no impresas. Además de los defectos, había otras tareas urgentes: el servidor de compilación se descompuso, las pruebas de IU cayeron, una tarea urgente e importante llegó de la administración y mucho más. Ahora, para ellos, la persona recibió MotC y por lo tanto compensó la escasez de SP en el sprint.

4. Calificaciones y rangos. Ya se inventaron 4 categorías: campeón de SP, maximizador de contribución (número máximo de MotC), héroe de sprint y premio de equipo. El principio de los dos primeros, creo, debería estar claro por el nombre, con el resto, más interesante. El héroe del sprint fue elegido por el equipo votando en retro, y este fue uno de los premios más honorables en el equipo tanto en términos de número de Mot como en términos de prestigio e importancia. La presencia de un premio de equipo es clave porque Muestra que no solo el resultado personal es importante, sino también el resultado general de todo el equipo. Se inventaron tres gradaciones: sprint regular, sprint superior y sprint fallido. Sprint se consideró normal, si se cerró más del 78% de la acumulación de sprint, si era 100%, entonces este es el sprint superior. En el caso del sprint superior, todo el equipo recibió un aumento generoso. Pero había una otra cara de la moneda: este es un sprint fallido.

Minería Negativa MotC

Los MotC importan. Por lo tanto, fue posible obtener monedas con un valor negativo. Qué anti-mérito llevó a esto:

1. Sprint fallido. En el caso de realizar menos del 78% de la acumulación de sprint, todo el equipo recibió minería negativa.
2. Abriendo el defecto. Si hubo un defecto inequívoco en la tarea de infusión, entonces el MotC negativo fue obtenido por el desarrollador que inyectó la solicitud de extracción, así como sus revisores.
3. 3. También se inventó un sistema financiado adicional por llegar tarde a un stand-up o falta de atención a colegas. Ella actuó según el principio de "3 en una fila". 3 íconos idénticos colapsaron en uno nuevo, en el que hubo una extracción negativa. Había una regla de amnistía: al recibir más de 25 MotC en el sprint, el colapso no condujo a una minería negativa, pero las insignias no se restablecieron.

¿Cómo gastar MotC?

Si si. El significado de las monedas no está solo en las calificaciones personales, sino también en el hecho de que podrían gastarse. Para esto, se inventó una función de activación. Solo se pueden activar monedas positivas. Había toda una tienda en la que había bienes y su valor. Para el control, su número era limitado.

¿Qué había en la tienda?

1. La capacidad de dejar el trabajo temprano o volver más tarde. El hodovichok más importante.
2. Jornada de trabajo a distancia.
3. Posibilidad de selección de tareas prioritarias en la planificación.
4. Recomendación de LinkedIn.
5. Elegir un módulo para el desarrollo en Swift. Todo el código estaba en Objective-C, y a los chicos realmente les gustaría desarrollarse en Swift.
6. Boletos de conferencia (si están disponibles).

Hubo otras posiciones, pero aquí la regla más importante es garantizar la posibilidad de su compra, de lo contrario la confianza se verá socavada.

Correcciones durante el juego

Durante el experimento, en ciertos puntos, los problemas del equilibrio primario se hicieron notables.
Cuales?

1. Jugadores de modelos a seguir. Además de los desarrolladores, había un analista en el equipo, y su capacidad para obtener MotC era muy limitada, porque La mayor parte de las tareas para los puntos de historia se agudizó para el desarrollo. Además, las funciones del analista incluían parte de las tareas administrativas, que eran costosas de controlar constantemente. La solución fue introducir el concepto de "minería privilegiada", es decir cierto número de MotC se acredita automáticamente por cumplir con las tareas diarias. Es interesante que en el futuro se haya encontrado otro desequilibrio: en ausencia de un analista (por ejemplo, vacaciones), alguien se hizo cargo de sus tareas y, por lo tanto, formó parte de la producción para la minería privilegiada.

2. Depreciación de tareas. Con el tiempo, ciertas tareas repetitivas se vuelven más fáciles de completar. Por ejemplo, teníamos un procedimiento para lanzar una nueva versión del framework (nuestro producto), que tomó aproximadamente 1.5-2 horas de tiempo puro. Con el desarrollo de DevOps, su tiempo dedicado se redujo a 30 minutos. En consecuencia, la remuneración en MotC también ha disminuido. O periódicamente había tareas para preparar nuevas formas de informes o estados. Es difícil hacer esto por primera vez, pero es más fácil repetirlo, por lo tanto, la estimación en monedas disminuyó. El equipo percibió dichos ajustes de manera apropiada.

3. Puntos dobles por defectos. Un ejemplo para mostrar que en cada equipo habrá situaciones imprevistas, y las reglas deben ser "ajustadas". Nos sentamos en la fusión automática en cascada durante mucho tiempo (es decir, al inyectar la revisión, las fusiones automáticas aparecieron en las versiones de lanzamiento anteriores y se desarrollaron). En algún momento, decidimos detener esta práctica viciosa debido a que constantemente colgaban conflictos de fusión en el desarrollo y pasamos a la idea de duplicar tareas en todas las versiones en las que desea cargar los cambios. Esto llevó a la aparición de múltiples tareas similares en JIRA:



Como resultado, formalmente de acuerdo con las reglas, el jugador podría tomar y completar rápidamente 2-3 tareas y obtener 2-3x monedas. Tuve que introducir correcciones para tales tareas, porque su complejidad disminuyó (pero ciertamente no a cero debido a posibles conflictos debido a cambios en las ramas individuales).

4. La idea de recompensar por trabajar con usuarios. Tenía muchas ganas de "obligar" a los chicos a ayudar a nuestros consumidores (y se trata de unos 100 desarrolladores de aplicaciones, llenos de preguntas estúpidas y repetitivas). Probamos diferentes enfoques: nombrar asistentes, mantener una base de conocimiento detallada, hacer crecer una comunidad de usuarios expertos y alentarlos. Pero apareció una solución simple: 1 vez al día, revisé rápidamente el chat de soporte en Slack y les di a los consultores más activos del equipo una pequeña pero agradable recompensa en forma de MotC. Chicos calificados

En general, un juego es un proceso vivo que debe cambiar en el camino. Lo principal es asegurarse desde el principio y dejarse la oportunidad de realizar maniobras orgánicas. Cambiar la mecánica del juego puede causar resentimiento entre los jugadores. Inicialmente, temía no poder calcular correctamente el saldo entre la minería y el costo de los "premios", por lo que inmediatamente indiqué que su número en la tienda es limitado y se repondrá tanto como sea posible. Además, como saben, ¡el mercado de suministro está controlado por un monopolio, que siempre puede declarar un déficit o inflación!

Resultados y observaciones

Todo el experimento duró 9 sprints (4 meses). Se gastaron un total de 968 MotC, y se gastaron 262. Hubo 3 sprints superiores, la misma persona se convirtió en el héroe del sprint 4 veces, la distribución de MotC en el equipo se veía así:

	MotC	MotC +
Jugador 1	104	86
Jugador 2	203	203
Jugador 3	148	128
Jugador 4	65	47
Jugador 5	172	92
Jugador 6	58	40
Jugador 7	68	68
Jugador 8	95	77
Jugador 9	55	55

Aquí está, el único indicador que quería crear.

Por cierto, toda la base de datos se almacenó en Numbers (xls para MacOS) y se envió a los participantes una vez por semana (al momento de emitir MotC para retro). Hubo 5 páginas con fórmulas transversales: historial de minería, historial de compras, tienda de ofertas, detalles de minería y tabla resumen.

Me hicieron una pregunta en la conferencia, no me llevó mucho tiempo realizarla.
La respuesta es no. Por el contrario, comencé a pasar menos tiempo configurando tareas en JIRA en
cada pequeña cosa y sincronizar con un cuaderno en el que regularmente escribía
Todas las tareas delegadas. La tabla llamada "Detallado" era solo
un nuevo tipo de cuaderno en el que podría escribir las instrucciones y cuándo se ejecutaron
registra la recompensa. A continuación se muestra un ejemplo de un sprint por jugador:

MotC	Minería
1	Propuesta para el problema X
1	Ayuda a Makov a actualizar el icono de la biblioteca para una demostración
2	Preparación de un repositorio con repetitivo para IP (demostración para manuales)
2	Preparar un esquema XSD para un ejemplo de una IP, así como consulta repetitiva
3	Defecto de cierre
16	Convertir 14 SP
4 4	Maximizer SP

Cuando terminó el experimento, les pregunté a los muchachos: todos estaban contentos con las innovaciones y confirmaron que era fresca y emocionante.


El resultado es una situación de ganar-ganar. Me ha resultado más fácil gestionar el desarrollo, los muchachos tienen nuevas oportunidades y el espíritu de desafío. Algunos chicos han encontrado por sí mismos nuevas formas de desarrollo y formas de beneficiar el producto. Al mismo tiempo, todo el equipo en conjunto intentó obtener un resultado superior al final del sprint.

No estoy tratando de demostrar que esta es la opción de administración correcta o una herramienta ideal; este es solo un ejemplo de cómo diversificar mi estilo de administración y, en el buen sentido, "animar" a un equipo. , , , . Performance Review .

!

PS Facebook LinkedIn , - 2 .