Get best of the week

Método Kanban: Entendiendo su proceso como un proceso de aprendizaje colectivo

Prefacio


En la comunidad profesional de gerentes de procesos de habla rusa, hay muy poca literatura sobre el método Kanban en ruso. Decidimos corregir esta injusticia y publicaremos los artículos más importantes desde nuestro punto de vista en ruso, que influyeron en el desarrollo del método.

Comprender su proceso como un proceso de aprendizaje colectivo


Y el primer artículo de la serie sobre cómo construir de manera más eficiente una visualización de sus procesos de trabajo y percibir un tablero. El autor del artículo original es Alexei Zheglov y se puede encontrar aquí.

Existe una tendencia general y un deseo de hacer el trabajo más colectivo. Sin embargo, cuando le pido a las personas en la oficina que dibujen un proceso de su trabajo, a menudo proporcionan algo como esto (simplifico):


En esta vista, los trabajadores forman una cinta transportadora, pero su trabajo realmente no se parece a una línea de montaje. Por ejemplo, un desarrollador de software puede detectar una inconsistencia lógica en la especificación de requisitos y enviar el trabajo a inteligencia empresarial. Un ingeniero de calidad (QA) puede hacer lo mismo al probar el software creado. El analista actualizará la especificación y enviará la tarea a QA. El control de calidad puede encontrar un error y enviarlo de vuelta al desarrollador. Un especialista en implementación puede encontrar algo en el código que impide la entrega. Luego, el desarrollador realiza los cambios necesarios. Ahora el código debe volver a probarse, por lo que vuelve al control de calidad, después de lo cual vuelve a la implementación.

Dicha interacción se produce no solo entre los miembros individuales del equipo, sino también (lo más importante) entre los departamentos corporativos, los servicios y los equipos multifuncionales. Por lo tanto, las personas dibujan muchas flechas conectadas en diferentes configuraciones para mostrar todos estos programas.

Algunos intentan visualizar este proceso en un tablero que llaman "kanban":


Luego se preguntan: ¿Qué sucede si, por ejemplo, el probador devuelve el elemento de trabajo al analista o desarrollador? ¿Debe la tarjeta permanecer en su lugar o moverse? ¿Qué sucede si tenemos un límite de WIP (estos números están en los encabezados de las columnas)? ¿Qué pasa si esta columna ya está llena hasta el límite, otra tarjeta debería volver?

¿Hay una mejor manera?


Esta pregunta es bastante común y se basa en un malentendido de la naturaleza del trabajo de servicio profesional. En lugar de una serie de transmisiones entre trabajos especializados, se trata principalmente de crear información y acumular conocimiento. Esto se convierte en un obstáculo cuando se intenta hacer que el proceso parezca un diagrama de flujo. Además de una limitación al intentar visualizarlo, tras la ejecución del trabajo.

En el ejemplo de ofrecer una nueva funcionalidad de un producto de software, se puede crear el siguiente conocimiento (no necesariamente en este orden):

  • configuración exacta del entorno de trabajo (SO, servidor web, servidor de bases de datos, software de terceros)
  • ejemplos clave del comportamiento de la funcionalidad desarrollada, casos de uso, criterios de aceptación, especificaciones ejecutables, etc.
  • ( , . .)
  • -
  • : , , ..
  •   , .

Todos en cualquier servicio profesional pueden crear su propia lista de conocimientos que crean en su proceso de entrega. Cuando se completa el trabajo, todo este conocimiento ya existe, pero cuando recién comenzamos a trabajar en las necesidades del cliente o la solicitud de suministro de algo, todo esto falta.

Si tratamos de visualizar el proceso de acumulación de este conocimiento, el resultado podría verse así:


En este ejemplo, el trabajo de especificación es dominante en una etapa temprana del proceso de entrega. Los analistas de negocios pueden realizar un análisis funcional, descomposición y refinamiento de requisitos. Pero al mismo tiempo, otros profesionales pueden contribuir. Los probadores pueden ayudar a convertir los criterios de aceptación en pruebas ejecutables. Los especialistas y desarrolladores de implementación pueden evaluar el impacto en la base de código y la infraestructura.

Esta actividad genera mucho conocimiento al principio, pero al final se desvanece. No podemos analizar sin cesar todo el camino hasta la entrega. Por lo tanto, el desarrollo del código en algún momento se convierte en la principal forma de acumular conocimiento.

Por supuesto, la mayor parte del desarrollo del código recae sobre los hombros de los desarrolladores, pero otros también pueden ayudar. Los requisitos aún pueden necesitar aclaraciones y aclaraciones (hola analista). El probador puede tomar software parcialmente listo, probarlo y dar retroalimentación al desarrollador. Los desarrolladores pueden colaborar con especialistas en implementación para ver cómo los cambios emergentes afectarán la implementación.

Pero esta actividad se desvanecerá. No podemos avanzar más puliendo el código. Entonces, pasamos a probarlo.y enfóquese en resolver cualquier error restante. Otra actividad en el estudio del conocimiento comienza a dominar. Los probadores son responsables de ello, pero necesitan la ayuda de desarrolladores, correcciones de errores y otros especialistas.

Tenga en cuenta que los tres puntos de inflexión en el nuevo diagrama de proceso no son transferencias entre especialistas funcionales o departamentos. Estos son cambios en la actividad dominante y cambios correspondientes en el patrón de interacción.

Conclusión


No necesitamos considerar los procesos como una red de especialistas y la transferencia de autoridad. Cuando intentamos visualizar nuestros procesos visualmente, no necesitamos representarlos en forma de bloques que representan especialistas, y muchas flechas que los conectan en todas las direcciones.

En cambio, podemos ver nuestro proceso de entrega como obtener información y crear conocimiento. Al hacernos la pregunta, ¿qué acciones realizamos para acumular conocimiento para entregar lo que entregamos? Podemos visualizar nuestro proceso como una secuencia de acciones conjuntas.

¿Que sigue?


En los siguientes artículos, me gustaría dar ejemplos del reflejo del proceso de acumulación de conocimiento, para procesos fuera del mundo del desarrollo de software.

Necesito preparar una serie de artículos, como recomendaciones: cómo un especialista en procesos puede componer un reflejo de los procesos con equipos de servicios profesionales . Para aquellos que usan sistemas Kanban, este enfoque tiene varias ventajas en el diseño y operación de estos sistemas.

Muchas gracias a Aleksey Pimenov yStepev.

More articles:


All Articles