Nuestro equipo desarrolla productos de crédito y garantía para personas jurídicas. La dirección es joven, los primeros números comenzaron en 2018. Hicimos el check-in y estudiamos el mercado, lanzamos un descubierto, un préstamo para incrementar la facturación y garantías bancarias. Los planes eran lanzar un préstamo con contrato, préstamos garantizados y otros productos.
Síntomas
Nuestro proceso desde el inicio rápido de la mecánica de comestibles ha estado acumulando muletas. Los aguantamos y, como se puede suponer, una vez notamos que las tareas para los procesos comenzaron a desarrollarse durante demasiado tiempo. Esto se reflejó en la constante transferencia de lanzamientos, las tareas no se completaron a tiempo. Los errores se acumulaban y afectaban a un segmento pequeño y específico de clientes.
Hubo situaciones en las que la liberación para la siguiente tarea, que ya se había trasladado durante dos meses, se pospuso nuevamente indefinidamente. Al mismo tiempo, la liberación de la función de descubierto rompió las garantías bancarias. Hubo una desincronización de la comprensión del producto. Los desarrolladores consideraron cosas importantes a las que el equipo comercial ni siquiera prestó atención. Las características clave de los productos, por otro lado, seguían siendo desconocidas.
Para salir de la situación de crisis se creó un grupo de trabajo, que se enfrentó a la tarea de hacer “rápido y bueno” de “malo y largo”. Por nosotros mismos, nos fijamos metas para mejorar el rendimiento y reducir la cantidad de errores.
Problemas
Habiendo profundizado en los procesos del equipo, encontramos una maraña de problemas que no se podían resolver por separado, requerían un enfoque integrado:
- pila de tecnología antigua;
- proceso kanban largo y torcido;
- los negocios subieron a los asuntos internos del desarrollo;
- el equipo de desarrollo estaba perdiendo interés en el proyecto;
- toxicidad general.
Les contaré con más detalle cómo se expresó esto.
Pila de tecnología antigua. Nuestro proceso se escribió en IBM ODM, un sistema con una serie de características que se interpusieron en el camino del equipo. Fueron descritos en detalle por nuestro arquitecto Denis Kotskinen el caso de un proyecto vecino (aunque había IBM BPM, pero en general todo es justo). Por separado, observo que no hay especialistas en el mercado con experiencia en este sistema.
Proceso de entrega prolongado. Oficialmente, nos posicionamos como un equipo kanban, pero los procesos parecían un cruce entre cascada y scrum. El legado del desarrollo en cascada es que los negocios, el desarrollo y las pruebas solo se comunican en la tarjeta Jira. Todos tenían un pensamiento claro: "He hecho mi parte del trabajo, mi cabaña está al borde".
No vinimos a Kanban de inmediato. Al principio, usamos Scrum con sprints, que se muestra mejor en proyectos jóvenes. Luego se dieron cuenta de que era moralmente difícil para el equipo transferir tareas de un sprint a otro, y cambiaron a kanban. Luego quedó claro que nadie sabe cómo trabajar con el flujo de entrada, el ciclo de desarrollo comenzó a aparecer. Se manifestó en el hecho de que las tareas de la empresa se recibían una vez a la semana, luego el equipo las evaluaba, quedó claro que nada estaba claro y la tarea se envió para la próxima semana. Al mismo tiempo, en palabras, hicimos kanban y buscamos cuellos de botella.
Entiendo que las ideas de Kanban y Scrum no se contradicen entre sí y hay ejemplos en los que una combinación de metodologías muestra buenos resultados. Pero quiero enfatizar que hubo una posición radical de puro kanban. El gran número de retornos de la prueba al desarrollo también se ralentizó enormemente, lo que señaló la baja calidad de la tarea en las primeras etapas.
Violación del modelo a seguir. Los analistas de negocios se dedicaron a la arquitectura: se les ocurrió una solución técnica al problema. Esto llevó al hecho de que a menudo abandonaban el descubrimiento profundo en favor de la elaboración y especificación de la solución, y este truco, junto con una arquitectura débil, ralentizó el desarrollo varias veces.
Pérdida de interés del equipo en el proyecto.Un equipo joven, ambicioso y con talento. Inicio puro. Después de lanzar y escalar, comenzaron los dolores de crecimiento. La presión constante del negocio, la complejidad del desarrollo debido a la falta de refactorización, los problemas internos acumulados, la acumulación de meses venideros llevaron a la fatiga banal y al agotamiento.
Debido a todo lo anterior, la atmósfera en el equipo se agrió. Los problemas se solucionaron en retro, pero no se resolvieron, y deambularon de semana en semana. La toxicidad general se desvaneció, cualquier diálogo sobre el trabajo se convirtió en reproches mutuos.
Qué hemos hecho
Hablando francamente, al principio solo entendimos que necesitábamos reescribir el proceso desde cero para deshacernos de las muletas y fortalecer el equipo con desarrolladores experimentados. Seis meses después, puedo nombrar dos cosas más que nos ayudaron:
- Reconstruyendo el proceso kanban. Gracias al centro de entrega de Tinkoff Biznes, que se ocupó rápidamente de nuestros problemas y ayudó a adaptar Jira.
- Sincronización empresarial y de TI. Aquí nos impulsó la creencia de que el equipo debe tener una buena comprensión del producto y no solo realizar las tareas que lo traerán.
Al final, reescribir el proceso resolvió el problema de la pila de tecnología y ayudó a deshacerse de las muletas. El replanteamiento del proceso Kanban ayudó a reconstruir el modelo a seguir y reducir la cantidad de devoluciones, es decir, aumentó la velocidad de entrega de tareas al producto. Varias actividades de sincronización y repensar los formatos actuales han enderezado la atmósfera general.
Parte 1. Reescribiendo el proceso
Entonces comenzamos a reescribir el proceso de IBM ODM a Camunda. Las razones para elegir Camunda se describen en el artículo de Nikolay. nshipyakov...
En los procesos de solicitud, utilizamos un término como etapa - una parte lógicamente cerrada del proceso, con un significado claro para el cliente, por ejemplo, "Recopilación de documentos" o "Firma de un contrato de préstamo". La primera tarea para nosotros fue lanzar un préstamo por contrato. Nos dimos cuenta de que la lógica de las tres etapas es específica para ella, y el resto no es diferente de etapas similares de un préstamo circulante. De hecho, escribimos tres etapas de un nuevo producto en Camunda. En el futuro, toda la etapa se reescribió cuando apareció una tarea empresarial para su cambio serio.
Surge una pregunta natural: ¿cómo negociamos con la empresa? Está claro que reescribir una funcionalidad que ya funciona lleva más tiempo que modificarla en el motor antiguo. Todo resultó bastante simple: los colegas estaban listos para invertir en un nuevo proceso, porque vieron lo genial que funcionaba en un proyecto vecino (y hola de nuevo, DenisKotskin). Al mismo tiempo, el tiempo de desarrollo del nuevo motor no fue mucho más largo, desde que comenzamos la rotación: los chicos agotados se mudaron a otros proyectos, contrataron empleados con experiencia en el desarrollo y diseño de procesos comerciales para reemplazarlos.
Parte 2. Cambiar el orden de realización de las tareas
Al cambiar el proceso de desarrollo, nos basamos en las siguientes pautas:
- No debe haber pasos que no se reflejen en la pizarra.
- Se debe brindar experiencia técnica al equipo.
- El equipo debe comprender cómo afecta la tarea al negocio.
Al cambiar el proceso Kanban, hemos identificado nuevas etapas que antes pasaban implícitamente por la etapa de desarrollo: esta es la arquitectura y el encuentro de tres amigos. Naturalmente, la arquitectura no se realiza sobre cambios menores, pero tratamos de hacer una reunión de tres amigos para cualquier tarea. Nastya tiene un artículo sobre el método "Three Amigo"Travieso... Quiero agradecer especialmente a Nastya: su formación en pruebas ágiles nos inspiró a realizar muchos cambios dentro del equipo.
El equipo recibe datos sobre el valor del producto en el formato de una historia de usuario y una evaluación del impacto de la tarea en el producto. Puede ser difícil detectar el engaño de los clientes empresariales inteligentes. Por ejemplo, la calificación "Esta regla es importante, se verificará en todas las solicitudes" es mucho menos informativa que "Realizamos un análisis, la regla rechazará 10 solicitudes adicionales por semana". Por eso, antes de enviar una tarea para el desarrollo, valido la calidad del valor escrito, como representante del equipo empresarial que comparte los valores de los desarrolladores.
También abandonamos prácticas que no nos funcionaron. Por ejemplo, ahora rara vez hacemos retro, solo cuando es necesario, cuando la necesidad de discutir algo se acumula. Esto sucede aproximadamente una vez al mes. Definitivamente resolveremos los problemas señalados en retro, ya que es importante que cada miembro del equipo vea cambios positivos en los temas que lo agobian.
Dejamos de usar storypoints y evaluación en equipo de una tarea; trabajamos con fechas de vencimiento que recibimos de la empresa y, en función de ellas, gestionamos el flujo de entrada. En tareas grandes que se realizan durante un par de meses, realizamos la descomposición: permite realizar una especie de puntos de control y aumentar la precisión del debido. Para monitorear el progreso, nos reunimos periódicamente y discutimos si estamos a tiempo. Si vemos que no es así, ajustamos el flujo de entrada y tomamos menos tareas pequeñas. En términos de la precisión de cumplir con la fecha límite, solo puedo decir que para nuestra principal tarea actual encajamos en lo debido.
En cuanto a la redistribución de roles, fortalecimos el equipo con un arquitecto y un segundo analista de sistemas. El equipo empresarial intenta explicar claramente qué se necesita en la tarea, qué valor conlleva, pero no aconseja ni se mete en el funcionamiento interno del desarrollo. También cuido del equipo empresarial.
Parte 3. Sincronización de los equipos comerciales y de TI
Usamos varios formatos para sincronizar empresas y desarrolladores.
Demo por tarea. Esta es una reunión de todos los interesados (analistas de cartera, departamento de riesgos, comercializadores y especialistas en TI) con una discusión sobre el valor, el problema problemático y la solución técnica.
Una reunión importante donde puede encontrar errores perdidos en la etapa de descubrimiento y tener tiempo para corregirlos. Además, el gerente que dirige la tarea no sabe con certeza qué procesos de la empresa se verán afectados por la liberación. Con nosotros, dicha publicidad nos permite prevenir situaciones en las que se rompen cambios en el proceso, por ejemplo, informes analíticos.
Retro en la tarea.En esta reunión, discutimos los problemas de los desarrolladores y clientes que encontraron durante el desarrollo del problema. Lo llevamos a cabo después de los análisis posteriores al lanzamiento, cuando las pasiones han disminuido y todos están listos para un diálogo constructivo. Tras conocer los motivos, formamos puntos de crecimiento y una nube de ideas, que probaremos en el futuro.
Realizamos conferencias sobre productos en el formato de un programa educativo y posterior discusión. Su objetivo es sumergir a los chicos de TI en el contexto empresarial. Según los comentarios recopilados en forma de encuesta con la redacción más general "Califique la conferencia de hoy", la calificación promedio es de 8.5 sobre 10.
Salir
Seis meses después, reescribimos más del 80% de los procesos, lanzamos un préstamo contra un contrato utilizando un motor completamente nuevo. El ambiente de equipo ha mejorado y nos hemos vuelto más eficientes. Para verificar esto, realizamos una encuesta del equipo y tomamos estadísticas de Jira.
La encuesta preguntó sobre la atmósfera en el equipo, la calidad de las especificaciones, el desarrollo y la arquitectura, la calidad de la comunicación con la empresa. Según los resultados de la encuesta, el puntaje promedio de los chicos que han estado en el proyecto durante más de seis meses aumentó de 6 a 8 puntos sobre 10. Desafortunadamente, la encuesta no es completamente honesta, ya que se realizó después de los cambios. Las cifras que se muestran son para principios de año y principios de julio. Así que es justo decir que la situación en el equipo ha mejorado, pero no se puede decir cuánto.
El rendimiento (número de tareas por día) se ha duplicado durante este tiempo. Naturalmente, no a expensas de la descomposición: acordamos de antemano ciertos estándares a los que nos adherimos.
El número de devoluciones de la prueba al desarrollo ha disminuido ligeramente. Es decir, con un aumento múltiple en la cantidad de tareas mostradas para producción, la cantidad de devoluciones no aumentó. Esto indica una mejora en la calidad del desarrollo de la tarea en las etapas de descubrimiento y arquitectura. La cantidad de errores encontrados en producción no ha cambiado.
Que hemos aprendido
Ahora formularé algunas ideas que el equipo y yo hemos aprendido de nuestra experiencia. Si tiene problemas similares en sus equipos, espero que ellos también lo ayuden.
- , . — . , — , . — .
- , , , , , . , .
- — , , . , , discovery .
- . one-one-, , . Shoom3301, .
- : — , IT — . , .