Un empleado que sabe mucho, sabe cómo y está listo para apagar cualquier incendio en su prado, por supuesto, bien hecho. Pero si este héroe se va de vacaciones o incluso renuncia, vendrán tiempos difíciles. Resulta que es importante no solo saber mucho, sino también poder compartir este conocimiento.
Aleksey Troshin (
morroz ) ha estado en la profesión por casi 20 años, ha estado trabajando como gerente de proyectos y productos desde 2002. Durante este tiempo, trabajó en varias compañías, dirigió equipos de 2 a 150 personas y ahora gestiona el desarrollo en FINAM. Aquí, Alex creó un sistema que ayuda no solo a difundir el conocimiento, sino también a motivar a los desarrolladores a crecer en la dirección correcta del negocio y del equipo. Sin embargo, el sistema no se usa en todos los equipos. Por qué Aprendemos sobre esto, así como los enfoques utilizados, debajo del corte.
El artículo se basa en un informe de Aleksey Troshin en Saint TeamLead Conf, que cuenta cómo se difunde el conocimiento en FINAM: cómo crecen la Fuerza y la habilidad de los Jedi, cómo se entrenan los Padawans y qué sucede en el lado oscuro de la Fuerza (dónde estaría sin ella).Productos y equipo FINAM IT
Primero, hablaré sobre algunos de nuestros productos para determinar el contexto de la empresa.
Sitio web Finam.ru : sitio número 1 sobre temas financieros, que contiene muchas secciones diferentes con información financiera, así como servicios útiles, por ejemplo, una tienda de acciones en línea. Puede, por ejemplo, comprar una parte de Apple y regalársela a alguien por un cumpleaños.
La plataforma de negociación FinamTrade , que también tiene una tasa de comisión cero para principiantes.
Comon.ru , un sistema de repetición automática de transacciones de operadores profesionales, una solución para inversores principiantes y aquellos que no tienen suficiente tiempo libre para crear su propia cartera de inversiones.
Red social para comerciantes y mucho más .
FINAM IT es de 150 personas divididas en 25 equipos. El desarrollo es solo interno, casi no atraemos a terceros para nuestras necesidades. La imagen del título muestra perfectamente cómo se arregla todo con nosotros. La composición de los equipos puede ser diferente: algunos equipos tienen un Propietario de producto, pero no hay evaluadores, por ejemplo, otros tienen evaluadores, pero no hay Propietario de producto, pero hay analistas.
En el desarrollo, utilizamos diferentes pilas de tecnología:
- Frontend: React.js, VUE.js.
- Lenguajes: C #, PHP, C ++, Java, móvil.
- Bases de datos: MSSQL, PostgreSQL, Oracle.
- Plataformas: SharePoint, 1C, Diasoft, MS CRM y más.
Cuando me uní a la empresa por primera vez, intentamos dibujar equipos, productos y relaciones. El resultado fue un esquema tan complejo, donde los círculos indican los productos que estamos desarrollando:
Por color, mostré que los equipos están organizados de diferentes maneras. Algunos hacen un producto, otros hacen varios productos. Y hay productos que varios equipos están desarrollando a la vez (por ejemplo, un back office interno).
Dirigiré mi historia en los ejemplos de dos equipos, los llamaré condicionalmente equipo 1 y equipo 2.
Equipo 1
El primer equipo desarrolló un sistema de información interno. Inicialmente, se veía así:
- Un empleado era un experto en la versión actual de la plataforma. Hubo una tarea para transferir esta plataforma a nuevos rieles, porque la versión anterior ya no era compatible.
- Tomamos un nuevo empleado que era experto en la nueva versión de la plataforma. Estuvo involucrado en portar toda la funcionalidad a esta nueva versión.
Equipo 2
El segundo equipo desarrolló varios sistemas internos:
- Un empleado es un experto en un sistema.
- Otro empleado es un experto en otros sistemas.
- Y algunos sistemas fueron desarrollados por ambos empleados juntos.
Sobre expertos
No es casualidad que la palabra "experto" esté resaltada en el texto anterior. Quiero aclarar quién es el experto en el marco de esta conversación. Como maestro de Star Wars, esta persona tiene el Poder: competencia profunda en su área temática, en tecnología, en el producto. Esto suele ser conveniente para una empresa, ya que ofrece un punto de entrada: se pregunta a los expertos cómo hacerlo o cuándo se hará, si se trata de nuevas tareas, o si se ha roto algo o no funciona correctamente.
Me imagino a un experto como un Maestro Jedi de la película "Star Wars": puede hacer cualquier cosa (bueno, o casi todo).
Pero el experto Jedi tiene sus inconvenientes:
- Necesita ser "criado" durante mucho tiempo para que acepte esta Fuerza.
- Cuando se va de vacaciones, siempre es: "¿Qué vamos a hacer todos?"
Para superar la influencia de estos inconvenientes, hemos desarrollado un sistema para mantener las matrices de competencias, que analizaré más adelante. Observo que no lo implementamos en todos los equipos, sino solo donde hubo problemas. Lo peor de todo fue en equipos pequeños.
Nuestro principal dolor de cabeza fue la pregunta "¿Qué sucede si algo le sucede al experto, como con el Maestro Yoda en la imagen de abajo?"
Y probablemente también escuchaste sobre el concepto del factor Bus.
Factor de bus
El factor bus es una medida de la concentración de información entre los miembros individuales del proyecto.
En la definición de Wikipedia, está escrito que este factor determina el número de participantes del proyecto, después de la pérdida de los cuales el proyecto no puede ser completado por los participantes restantes. Convencionalmente, esto significa cuántas personas deben mover el autobús para que ocurra un desastre irreparable con el proyecto.
Cuando tienes un experto, entonces el factor Bus es igual a uno, es decir, todos los riesgos del proyecto están en manos de una persona, y esto es malo.
Un ejemplo de la historia: en 2010, cerca de Smolensk, se produjo un accidente aéreo en el que murieron 96 personas, incluido el máximo liderazgo de Polonia. Después de este evento, se aprobó una regla en Polonia: los cuatro principales líderes del estado (presidente, primer ministro, presidente del Senado, presidente del Sejm) bajo ninguna circunstancia deben volar juntos. Este es un factor de protección contra el factor Bus.
Como saben, en los equipos 1 y 2, los expertos no eran intercambiables, y esto creó problemas potenciales. Era necesario hacer algo para aumentar el factor Bus y ampliar las competencias de los expertos Jedi. Hemos tomado los siguientes pasos.
Paso 1. Incremente el factor Bus
Los Jedi no deberían estar solos. Por lo tanto, es necesario entrenar y entrenar a los Jedi, para que haya más de ellos.
Aclararé que el
Jedi es un papel, no una competencia . Jedi puede ser criado. El segundo papel (en términos de Star Wars) es
Padawan , un discípulo de los Jedi. Se esfuerza por la plenitud del conocimiento del Jedi y lo reemplaza cuando está de vacaciones. Además, puede haber más de un padawan: si el equipo es grande, podemos cultivar varios padawan a la vez. Pero el Jedi sigue siendo el principal responsable de la toma de decisiones.
Cuando decidimos quién se convierte en Jedi, acordamos los Padawans, distribuimos los roles y los visualizamos en la tabla de gestión:
Aquí están los productos horizontales, áreas o módulos. Por ejemplo, si el producto es 1C, puede ser "Salario y personal" o "Contabilidad" u otros módulos. Las columnas verticales indican los empleados. En la intersección ingresamos los roles: quién es el Jedi, quién es el Padawan. Esto da como resultado una distribución clara.
Hay algunas reglas que acordamos para comenzar la distribución.
Reglas de distribución, parte 1:- Un producto, área o módulo: un Jedi . Recordamos que queremos mantener la comodidad de una "ventanilla única", experta y responsable.
- Al menos un padawan . Esto es solo sobre el factor Bus, cuanto más haya, mejor.
- La distribución uniforme de los Jedi . Para no sobrecargar a los empleados, para ser justos.
Parece que todo se distribuyó lógicamente, y resultó así:
En el primer equipo que trabajó en un producto, una persona trabajó en el producto anterior (Sunset), la otra en el nuevo (Sunset 2.0). En la versión "propia" del producto, el empleado era considerado un Jedi, en la versión "alienígena": Padawan, un estudiante de otro empleado.
En el segundo equipo, los empleados recién llegados inicialmente se inscribieron en Padawans, porque todavía no sabían nada sobre ellos. Y luego es similar al Sudoku: tratamos de obtener aproximadamente el mismo número de Jedi y Padawan en filas y columnas.
Paso 2. Controlar el intercambio de conocimientos
Pero, ¿cómo verificar que el Padawan se convertirá en un Jedi, que posee todo el Poder del conocimiento?
Arreglamos el conocimiento
Para hacer esto, fijamos el conocimiento de nuestros productos: haga una lista de todo el conocimiento y póngalo en una tabla. Para cada uno de los productos en una página de Confluence separada, simplemente anotamos el conocimiento de que el producto consiste y los descompone. La descomposición del conocimiento se puede hacer de diferentes maneras, y recuerdo que estas tablas están dibujadas debajo de la página con la distribución de los Jedi y Padawans. Por ejemplo, para el equipo 1, una página para conocimiento de Sunset, otra página para conocimiento de Sunset 2.0.
Además algunas capturas de pantalla de nuestra Confluencia con ejemplos de descomposición.
Por módulos de producto. Por ejemplo, uno de los productos tiene módulos de software separados: préstamos, depósitos, control de divisas; simplemente los pintamos y comenzamos a trabajar con ellos.
Por funcionalidad. Aquí pintamos las unidades de conocimiento en las páginas y secciones del sistema.
Por conocimientos técnicos. Presentamos algunos productos simplemente de acuerdo con el conocimiento técnico del equipo.
Puede descomponerse de cualquier otra manera, lo principal es que podría rociar conocimiento sobre su producto en una mayor cantidad de elementos atómicos.
Agregar documentación
Después de detallar las listas de conocimiento, agregamos la columna de "documentación" a la tabla y comenzamos a llenarla gradualmente: cada línea de conocimiento tiene su propia página con una descripción.
Debo decir de inmediato que este no es un proceso rápido, nos tomó varios meses, pero con el tiempo se completó la lista de documentación y, al final, en todas las áreas de conocimiento sobre el producto, hemos escrito algún tipo de documentación.
Agregar calificaciones
Más a la derecha de la columna "Documentación", agregamos una columna para cada miembro del equipo y evaluamos cuánto tiene este conocimiento cada empleado.
Descifraré las calificaciones:
- 1 - si no ha visto o tocado esta área de conocimiento.
- 2 - vio o escuchó algo, sabe dónde está. Por ejemplo, leí la documentación, solicité acceso al servidor o al repositorio.
- 3 - visto, tocado, puede hacer. Por ejemplo, descarté un error en esta parte del código, verifiqué algo con mis manos.
- 4 - trabajó más de una vez, puede decirle a los demás.
En la primera versión, teníamos cinco grados: la escuela nos enseñó a contar del 1 al 5. Pero resultó que el sistema de cuatro puntos era suficiente, nos detuvimos.
Al calificar para una revisión del conocimiento, podemos hacer preguntas de control. Uno de los equipos para presentar a los recién llegados al proyecto tiene un video de una hora que debe ver y responder preguntas en la lista de verificación. Si una persona no respondió todas las preguntas, se cree que no entendió nada, el video debe revisarse, ya que tiene todas las respuestas.
Paso 3. Visualízalo
En el tercer paso, surgió la pregunta: ¿cómo veo yo, el gerente, de manera inmediata y clara cómo ocurre la acumulación de conocimiento dentro del equipo?
Visualizamos el estado actual pintando los cuadrados de Jedi y Padawan en diferentes colores: verde - el entrenamiento se completó, gris - en el proceso de aprendizaje, rojo - no comenzó a estudiar. Al principio, generalmente mucho rojo, pero al final todos deberían "volverse verdes".
Al principio tocamos un semáforo y pensamos que debería haber amarillo entre el rojo y el verde, pero resultó que el color amarillo brillante nos distrajo de la esencia. Por lo tanto, lo abandonamos y nos volvimos grises. En realidad, lo principal es deshacerse del rojo lo más rápido posible. Imagen con un ejemplo de un semáforo:
Después de eso, perfeccionamos aún más nuestras reglas.
Reglas de distribución, parte 2:- El Jedi debe "volverse verde" primero. Es decir, nos enfocamos en bombear al Jedi. El jefe responsable debe ser competente lo más rápido posible. Especialmente si se trata de un nuevo empleado.
- Al menos un Padawan debe ser verde, habiendo completado el entrenamiento por completo. Pero puede que no tenga prisa por ponerse al día con el conocimiento de los Jedi, lo principal aquí es no detenerse.
- El resto de los padawans pueden estar en el proceso de aprendizaje. Nuestra tarea es no olvidar "difuminar" el conocimiento, para garantizar que las áreas de conocimiento de los empleados se crucen y la cobertura sea máxima.
Requisitos diferenciadores
Para la primera etapa del lanzamiento del sistema, en el que la descripción y la digitalización del conocimiento apenas comienzan, hay una buena práctica: separar los requisitos para los Jedi y Padawan.
Recordemos las estimaciones: Padawan obtiene una marca verde para los "tres" si hizo al menos algo en esta área, y los Jedi deberían estar perfectamente orientados en la misma área, para los "cuatro". Además, es malo para el Jedi (color rojo) si no se obtiene acceso, no se escribe la documentación, etc., es decir, su umbral inferior es "dos". Este enfoque se ilustra en la tabla a continuación.
Esto fue suficiente para comenzar. En la siguiente etapa, puede elevar el listón y decir que ahora todos los números deberían ser iguales.
Y ahora nuestros platos están pintados y todo se volvió más interesante y comprensible:
Fuimos a algunas fotos verdes un año y medio. Poco a poco nos reunimos con los líderes del equipo, una vez cada dos semanas o un mes, vimos lo que estaba sucediendo, actualizamos constantemente algo.
Cuando agregamos una nueva funcionalidad, aparecieron dados rojos. Luego, en la próxima reunión de Timlid, verificamos si seguían rojos. Si es así, comenzaron a descubrir por qué en dos semanas el entrenamiento no había progresado. Si el rojo desaparece, los cuadrados grises permanecen, los revisamos periódicamente. Los resultados de la reunión del equipo se registraron en Confluence en las listas de verificación, donde se anotó el estado. Por ejemplo: "Empleado 1: nivelación 10 de 20". Si en dos semanas estos valores no cambiaron, buscaron por qué.
Cada nuevo empleado siempre está en la zona roja, necesita ser entrenado y bombeado lo antes posible. Pero como?
Paso 4. Bombeando conocimiento y habilidades
Relleno: llenar la documentación
Llegamos a comprender que debemos esforzarnos por garantizar que una fila de la tabla descompuesta del producto corresponda a un conocimiento (una página de la documentación).
La descripción imperfecta es solo visible en esta tabla. Esto significa que las áreas de conocimiento en la columna de la izquierda son demasiado detalladas y, en el lado derecho, probablemente hay una gran hoja de documentación que es difícil de leer y difícil de aprender. Es decir, leyeron una página de la documentación y bombearon 5 líneas de conocimiento a la vez; es ilógico obtenerlo de alguna manera. Es mejor que una línea corresponda a una página en Confluence. Es más fácil marcar la casilla (número) que todas las páginas se estudian y aprenden.
Utilizamos dos métodos de llenado:
- Escritura de memoria (método experto). Cualquiera que sepa cómo hacer algo, se sienta y comienza a grabar sus pasos, por ejemplo, complementando la descripción con capturas de pantalla.
- El segundo método, la investigación , que veo y luego escribo. De esta manera, lo usamos cuando trabajábamos con un sistema que nadie recordaba qué hacer con él. El empleado se sentó para comprender y escribió todo lo que hizo en pasos: aquí debe solicitar los derechos y luego escribir una carta, etc. Por lo tanto, se completó la documentación de la parte que investigó.
Sucede que los intereses de los desarrolladores en términos de autodesarrollo no coinciden con lo que la empresa necesita. Aquí puedes jugar con las probabilidades. Por ejemplo, necesita un impulso en las habilidades de análisis, lo que significa que ponemos un coeficiente de 0.5 en análisis. Queda claro que allí puedes "volverse verde" más rápido. Pero donde los empleados mismos están más interesados, pero no el equipo, las probabilidades son mayores. En estas secciones, el bombeo llevará más tiempo.
Además de trabajar con documentos, llevamos a cabo charlas tecnológicas. Pero la documentación es básica. Creo que esta es la mejor manera de controlar todos los procesos. En la documentación, todo se presenta en los estantes, se puede ver una imagen completa y usted puede influir en la difusión y acumulación de conocimiento.
Entonces, hemos documentado todo lo que necesitamos. El siguiente paso es actualizar.
Actualización
Es muy bueno cuando todos los miembros del equipo tienen derecho a editar la documentación. Entonces, cualquier empleado, familiarizándose con la documentación, leyendo cómo hacer algo, puede tropezar en algún lugar y corregirlo de inmediato. Por ejemplo, el nombre del servidor ha cambiado o algo más, un empleado puede cambiar inmediatamente la documentación. Por lo tanto,
se produce la
actualización automática y la reposición del conocimiento .
Si su equipo en su espacio de Confluence está suscrito a estos cambios, recibirá notificaciones donde lo que se ha agregado, cambiado o mejorado, porque en Atlassian Confluence hay:
- Historial de cambios en la página: siempre puede ver qué y cuándo ha cambiado.
- Suscríbase a las notificaciones de actualizaciones de la página.
- Eliminar a través de la basura.
Convenientemente, hay una eliminación a través de la cesta. Si alguien hace clic accidentalmente en "Eliminar página", todavía no se perderá. Puede restaurarlo y descubrir por qué alguien intentó arrancar este conocimiento de su espacio.
La mayoría de nuestros equipos no tienen un proceso separado para revisar la documentación. Entonces, en uno de los equipos la difusión del conocimiento fue un gran dolor, el líder del equipo olvidó hacerlo. Luego comenzamos a realizar una revisión allí cada seis meses. Creamos una nueva página y comenzamos de nuevo, se corrigió la fecha de la revisión.
El criterio principal para la calidad del intercambio de conocimientos para mí es la partida de un empleado de vacaciones. Si una persona se va de vacaciones y nadie me escribe, no llama y no pregunta nada, entonces creo que todo está en orden en este equipo.
Y si antes de planear unas vacaciones, hay discusiones sobre "qué haríamos sin él", para mí esta es una ocasión en una reunión personal con el líder del equipo para discutir qué sucede con la transferencia de conocimiento en su equipo.
Debe comprender que la documentación no siempre se trata de leer o aprender algo. A menudo necesita hacer algo: solicitar acceso, instalar el programa, abrir algo en el programa. En el curso de estas acciones, se lleva a cabo la actualización. , , . , , , . .
Uso
?
. . , 4 , . , , - . , , . , , . , .
, . : « , . , ».
, — , . «», , . , : « , . ».
. , , 1, 2, 3, 4 . , , . . , , 1, 2, 3, 4. .
« »KPI, : « - KPI , - - , ». , , , , . — .
— , , .
Bus factor: , . , bus- , , , . : , . , . , , . , , . . : «, . - , ».
, , . () . , , . ( ). . , — . .
. , , . , . , . .
Conclusiones
, , , .
« ! ». . !
TeamLead Conf 2020 , . , «», . , . , , , telegram- . 10 11 !