Cómo tratamos de mobbing

Si intentas encontrar mobbing o Mobbing en un motor de búsqueda, una parte importante de los resultados se referirá al "abuso psicológico de las personas". Por lo tanto, es mejor buscar inmediatamente la "programación de la mafia". Por el momento, en los 10 resultados principales de Yandex (27/02/2019) solo hay un artículo en ruso (y ese es una traducción), pero hay muchos artículos en inglés. Si los mira con fluidez, la mayoría de ellos son una teoría, no un análisis de ningún caso práctico. Todos dicen que ayudará al equipo a ser más efectivo, distribuir localmente la experiencia del proyecto y desarrollar habilidades sociales en las personas. Yo mismo probé el mobbing en la práctica durante uno de los entrenamientos de scrum y, francamente, ¡estaba encantado! Después de consultar con el equipo, decidimos realizar nuestra sesión de prueba de mobbing.

Entre las ventajas de este enfoque de trabajo, identificamos por nosotros mismos valores como la difusión de la experiencia dentro del equipo y el desarrollo de habilidades adicionales para cada participante. Después de organizar una reunión dedicada al acoso, nos propusimos tres objetivos: primero, intentar el acoso en la práctica. En segundo lugar, comprender qué desventajas y factores negativos hay en nuestro caso. En tercer lugar, determine si aportará los valores anteriores a nuestro equipo.

¿Qué es el mobbing?

El fundador de mobbing como un estilo de trabajo de Woody Zuill lo describe de la siguiente manera:

personas maravillosas trabajando juntas en una tarea a la vez en un solo lugar en una computadora.

Es decir, el Mobbing es un estilo de trabajo cuando un equipo trabaja constantemente y juntos "atacan" en cualquier tarea. Al mismo tiempo, la tarea pasa por todas las etapas necesarias de su ciclo de vida, y cada miembro del equipo trabaja en ella simultáneamente con todos. Por lo tanto, se logra la inmersión y la comprensión de la tarea por parte de todo el equipo.

Hay varios roles en el mobbing:

• Conductor: se sienta en un lugar de trabajo común, hace exactamente lo que le dice el navegador.
• Navegador: da instrucciones al conductor. Si no sabe qué hacer, consulta con la mafia (el resto del equipo), transmite las acciones necesarias al conductor.
• Multitud: participa en el desarrollo, le dice al navegador lo que debe hacer el controlador.
• PO (propietario del producto): sabe exactamente lo que debe suceder. Establece la dirección deseada para el movimiento del equipo. Puede ser un conductor y un navegador.
• Facilitador: monitorea el cumplimiento de las reglas, anuncia turnos, parquea ideas. Es deseable que haya una persona en este rol.

El mobbing consiste en una sesión, que consiste en ciclos, cada uno de los cuales consiste en turnos.
Sesión: un período de tiempo durante el cual un equipo trabaja en una tarea. Antes de la sesión, la tarea se selecciona y se divide en etapas, y se determina su objetivo: lo que se debe obtener como resultado, por ejemplo, el incremento de lo funcional.

Cambiar: el intervalo de tiempo entre cambiar los roles del conductor y el navegador. El cambio dura, por regla general, 15-20 minutos. Los turnos más cortos contribuyen a una mayor velocidad y una mayor participación del equipo.

Reglas del juego

Durante el turno, el conductor se sienta en la computadora compartida y hace exactamente lo que el navegador le dice. El equipo observa y, si es necesario, discute lo que hay que hacer. El navegador estructura esta discusión y transmite al conductor lo que debe hacer exactamente ahora. El conductor solo escucha las instrucciones del navegador y puede hacerle preguntas. El navegador puede transmitir la pregunta al equipo. El facilitador "estaciona" ideas que fueron expresadas pero no utilizadas por una razón u otra.

Al final del cambio de función, las funciones de conductor y navegador se transfieren a otras personas en un orden predeterminado: el navegador actual va a la mafia, el conductor se convierte en el navegador y la siguiente persona a su vez se convierte en el conductor de la mafia. Cuando cada miembro del equipo visitó cada uno de los roles, el "círculo se cierra", es decir, el ciclo termina.



Después de la sesión de mobbing, cada uno de nosotros compartió sus impresiones, sobre la base de las cuales se sacaron ciertas conclusiones. Como resultado, obtuvimos un resultado que nos dio una idea de cómo y cuándo es mejor usar mobbing, y si se adapta a nuestro equipo. Comenzaré con impresiones negativas.

Negativo

A veces, el papel del navegador no está del todo claro. En algún momento, por ejemplo, el analista podría estar en este rol, y el desarrollador podría ser el conductor. El navegador volvió a contar lo que el equipo le estaba diciendo, sin comprender completamente "qué significa todo esto", debido a la falta de experiencia en desarrollo. Como resultado, surgieron situaciones en las que el navegador simplemente no tenía sentido transmitir las instrucciones del comando, porque, en primer lugar, el desarrollador escucha el comando, entonces, ¿por qué necesita un intermediario? En segundo lugar, el conductor entiende cómo actuar en esta situación, pero de acuerdo con las reglas del rol, sus manos están atadas.

También notamos que si el navegador necesita mirar la siguiente pestaña en el entorno de desarrollo para determinar el siguiente paso, entonces necesita expresar esta idea y esperar a que el controlador cambie la pestaña. Él mismo habría hecho esto mientras expresaba la solicitud al conductor, con todos "sean tan amables" y "por favor, gracias".

La dificultad fue que tenemos dos desarrolladores trabajando de forma remota. En primer lugar, agregó tiempo para una operación como "cambiar los derechos al cursor": para que el administrador remoto pudiera mostrar algo en la pantalla, pero al mismo tiempo no tomar el control del mouse. Para hacer esto, fue necesario expandir la ventana de control de la conferencia, habilitar a la persona adecuada para controlar el cursor y minimizar la ventana. No toma tanto tiempo, pero distrae mucho, lo deja fuera de una tarea (en la que acaba de comenzar a sumergirse) y generalmente interfiere. Como resultado, después de cada turno, el nuevo navegador tuvo que preguntarle al anterior qué quería hacer ahora, ambos tuvieron que recordar esto, "sincronizar", y solo luego continuar.

Otra dificultad debido a la "lejanía" de algunos empleados son sus vecinos. En algún momento, un vecino del navegador remoto decidió perforar agujeros en toda la casa, por lo que escuchamos una amplia gama de sonidos acompañantes con amplificación. Esto, como saben, no nos ayudó en absoluto.

Como estábamos muy limitados en el tiempo (una hora por sesión de mobbing), nuestros turnos fueron muy cortos: 5 minutos cada uno (para que cada participante tuviera tiempo de visitar este o aquel papel al menos una vez). También está fuertemente, en mi opinión, reflejado en el progreso. Como se dijo anteriormente, todos los participantes en la sesión se sumergieron en la tarea solo al final del turno (1-2 minutos hasta el final), y después de este corto período de tiempo, todos se distrajeron con el cambio. Está claro que no harás mucho de esta manera.

A otro equipo le gustaría tener más tiempo para pensar "en silencio" y discutir ideas, pero los cambios frecuentes provocaron tratar de examinar más con las manos que la hipótesis de la teoría.

No tomamos el caso más simple para un experimento de una hora: una tarea de otro proyecto que no era muy familiar para nuestro equipo. La mayoría de las veces descubrimos cómo funciona ese código que necesitamos cambiar en general. Sobre el total de 7 horas de trabajo (1 hora para cada miembro del equipo), realmente no entendimos de qué lado abordar esta tarea.

Se observó que todo el equipo ve la solución al problema desde cierto punto de vista, incluido un probador. Sugerimos que en el futuro (cuando llegamos a la etapa apropiada) esto podría afectar negativamente la objetividad de las pruebas, porque todos sabríamos "cómo funciona", e inconscientemente intentaríamos evitar los cuellos de botella. Desafortunadamente, esto es solo una suposición.

Pero nuestra otra hipótesis fue confirmada. Incluso antes de la sesión, sugerimos que si las personas con diferentes visiones se cruzan mientras trabajan en la misma tarea, habrá una carrera de ideas. Esto es exactamente lo que sucedió: algunos desarrolladores sugirieron llevar a cabo la depuración local mediante pruebas de integración, otros, implementando completamente el proceso comercial que se suponía que debía cambiar. Cada lado hizo argumentos convincentes. Salimos de esta situación debido al hecho de que decidimos probar primero un enfoque, y si, en el momento acordado, entendemos que este método requiere más trabajo, entonces utilizaremos una opción alternativa.

La configuración en el entorno de desarrollo resultó ser un obstáculo: cada uno de los desarrolladores se siente cómodo con sus propios parámetros específicos. En este caso, solo había un entorno de desarrollo y, por supuesto, no a todos les gustaba su configuración.

Incluso logramos cometer un error de facilitación: poco antes del final del turno, el futuro conductor fue a tomar el té. Como resultado, su navegador también se fue a preparar té, y así perdimos un turno en el tiempo.

Como puede ver, algunos factores negativos surgieron como resultado de errores organizacionales, pero, sin embargo, mostraron cómo hacerlo mejor y por qué.

Positivo

Los participantes señalaron que este estilo de trabajo permite a las personas que normalmente reciben tareas del negocio, analizarlas y probarlas, profundizar en el proceso de resolución directa de estos problemas. Vieron trabajar en ellos desde el otro lado: qué pasos sigue una tarea en el camino hacia su implementación. Se hizo evidente para ellos qué acciones están haciendo los desarrolladores para comprender cómo abordar su solución. Por lo tanto, todos ven y entienden lo que está sucediendo actualmente con la tarea.

Para algunos de nosotros es obvio por qué los desarrolladores a menudo requieren un análisis más profundo al describir una tarea, y por qué a veces hacen preguntas bastante absurdas, a primera vista, aclaratorias.

Sin lugar a dudas, esta es una experiencia nueva y valiosa para cada uno de nosotros. Además, una colaboración tan inusual ayuda a fortalecer el equipo, es decir, sirve como una especie de trabajo en equipo: por primera vez, alguien vio el trabajo directo de la otra persona, aprendió sus pensamientos en una determinada situación.

Resultados

Habiendo discutido los comentarios recibidos unos de otros sobre la sesión, llegamos a ciertas conclusiones.

Según nuestros resultados, resultó que en el mobbing no deberías trabajar absolutamente con todo el equipo, o al menos no constantemente. En nuestra realidad, si todo el equipo está trabajando en una sola tarea, las negociaciones con los contratistas no se llevan a cabo y las solicitudes de los usuarios no se procesan. Por supuesto, puede hacer esto hasta que llegue su turno, pero luego debe distraerse, cambiar a la tarea que todos están resolviendo, luego abandonarla nuevamente y recordar lo que detuvo antes del turno.

Es necesario que el navegador tenga un poco más de experiencia que el conductor. De lo contrario, resulta ser un juego de un teléfono roto, cuando el navegador intenta literalmente pasarle al conductor lo que dijo, sin comprender completamente "lo que significa todo". Puede, por ejemplo, cambiar roles no a su vez. Si no puede proporcionar a las parejas navegadores más potentes, pero necesita enseñar a las personas a trabajar no solo de acuerdo con su especialización, entonces, en nuestra opinión, la programación de parejas será más efectiva.

Tenemos la impresión de que el mobbing funcionaría bien cuando aparecieran nuevos desarrolladores en el equipo, o alguien en el equipo decididamente quisiera programar. Luego, al realizar mobbing con desarrolladores experimentados, los recién llegados se sumergirán rápidamente en proyectos de equipo y comprenderán los principios y reglas de trabajo generalmente aceptados.

Del mismo modo, puede trabajar en una tarea en la que solo una persona de un equipo posee experiencia (sí, tenemos una persona y un proyecto de este tipo) para difundir el conocimiento entre el resto.

Asumimos que el acoso es bueno para los equipos de tigres: equipos que se forman para resolver alguna tarea urgente. Pero esto puede funcionar si, al menos, el equipo está en la misma sala y con el entorno de desarrollo preparado para la mayoría. De lo contrario, habrá una pérdida de tiempo debido a factores de comunicación innecesarios.
Si un equipo se acaba de formar, e idealmente, se está formando un nuevo proyecto junto con él, entonces el acoso puede funcionar bien. En este caso, cada participante verá cómo y por qué se toman ciertas decisiones conceptuales, arquitectónicas y de otro tipo, habrá un desequilibrio en el conocimiento sobre el proyecto.

En definitiva, los turnos son necesarios por más tiempo. Al menos 15-20 minutos, en lugar de nuestros 5. Y debe hacer algo con la regla de que un conductor es solo la mano de un navegador, sin su propia cabeza.

Por lo tanto, tratamos de mobbing en la práctica en las condiciones del trabajo de nuestro equipo. Algunas reglas interfirieron con nosotros, algo que entendimos mal, en algún lugar donde cometimos errores. Sin embargo, sentimos en nosotros mismos qué es, si es posible y si necesitamos trabajar en este estilo. Según los resultados de este experimento, no recibimos completamente esos valores que identificamos para nosotros mismos como los más importantes. Vale la pena considerar que probamos el mobbing durante solo una hora con turnos demasiado cortos, porque estos resultados pueden no ser los más confiables. Cuando se trabaja en mobbing “a tiempo completo”, no surgirán algunos problemas y algunos se superarán después de la “adaptación” al proceso. Probablemente, simplemente no logramos obtener los valores que necesitábamos en tan poco tiempo. Para saber esto con certeza, vale la pena probar el mobbing en otras situaciones, pero esta será una historia completamente diferente.

PS
Puede leer y ver los siguientes materiales sobre el tema:
GOTO 2017 - Programación de la mafia: un enfoque de todo el equipo - Woody Zuill
Woody Zuill - Un día de programación de la mafia
Blog de Agilix Consulting: matar colas y acelerar un equipo con mobbing