Pequeña empresa o empresa a gran escala: en todas partes se construye el proceso de interacción con el cliente. En algún lugar, esto lo hace un producto / proyecto (subrayar según sea necesario), en algún lugar, el equipo está directamente involucrado en las comunicaciones. Soy del segundo campamento. En este artículo, le contaré cómo nuestro equipo construyó el proceso de interacción con los clientes sin involucrar a los gerentes. Debajo del recorte, un plan de acción sobre cómo vivir orgánicamente con una gran cantidad de clientes sin cumplir con los plazos y sin olvidar su lista de deseos.
El equipo
El equipo en el que trabajo desarrolla una API pública y es uno de los principales proveedores de datos para 2gis.ru y socios comerciales. Cualquier consulta de búsqueda con 2gis.ru pasa por nuestro equipo: generamos datos en la respuesta.
El conjunto de tareas que llegan al equipo se puede representar condicionalmente de la siguiente manera:
- Tareas imprescindibles para la implementación integral de las que está trabajando todo el departamento o empresa. No se pueden hacer.
- Tareas de soporte de productos. Si algo se rompe, debería haber tiempo para arreglarlo.
- Deuda tecnológica. La presencia de estas tareas depende de la necesidad y la cantidad de otras. Desafortunadamente, en la lucha por las prioridades, son los primeros candidatos para la eliminación.
- Tareas de los clientes. Esas tareas que no están incluidas en los planes del departamento, pero que serán buenas para un cliente específico.
El primer y último tipo de tareas provienen de las mismas personas, la diferencia clave está en las prioridades y el alcance de estas tareas. Si tiene que sacrificar algo, la mayoría de las veces será una deuda técnica y tareas de los clientes.
Ejemplo: la tarea imprescindible es
liberar beta.2gis.ru , la tarea del cliente es agregar un nuevo campo a la respuesta de la aplicación.
La distribución de tareas era casi siempre la misma que la descrita anteriormente, pero el enfoque para trabajar con el flujo de estas tareas solía ser diferente del actual.
Como era antes
Éramos un equipo que se detuvo en el medio en la transición de scrum a kanban. Tratando de controlar el flujo de tareas usando el tablero kanban, no abandonamos el conjunto mensual de tareas que planeamos hacer en un mes, es decir, escribimos un sprint típico.
Recolectamos la lista completa de tareas, establecemos prioridades y calificaciones en Google. Se requería mucha fuerza, nervios y tiempo, por lo tanto, nacimos como un "plan maestro", transmitido dentro del equipo. Una persona con este rol, además de sus tareas principales, una vez al mes verificaba la exactitud de las fórmulas para calcular los recursos, las tareas imprescindibles recopiladas, la lista de deseos de los clientes y los deseos del equipo. Sostuvo largas reuniones de equipo para evaluar estas tareas y trató de agruparlas en una sola lista de trabajos, basada en sus propias ideas sobre las prioridades. El enfoque estaba lejos de ser ideal.
Problema 1. No está claro para los clientes qué sucede con sus tareas.
Todos los meses les preguntamos a los clientes "¿Qué pasará si no hacemos esta tarea?". Si el incumplimiento de las tareas no conllevó pérdidas monetarias para nosotros, con mayor frecuencia le dimos al equipo recursos para esas tareas, cuyo resultado será visible para el usuario final. Como recordará, había entre 15 y 20 clientes, por lo que algunas tareas permanecieron en la cartera de pedidos durante años y estaban esperando en las alas.
Los clientes no entendían cuánto tiempo pasaría cuando la tarea llegara al tablero kanban. Al formar planes, dijimos que la tarea se completará dentro de un mes. Posiblemente Si tenemos tiempo Además, el cliente no entendió lo que debía hacerse, con quién hablar y cómo resolver la tarea.
Googlodok no fue informativo. Era tanto una lista de tareas durante un mes como una acumulación de tareas que se transfirieron de una hoja a otra. Las tareas se perdieron y se duplicaron. No estaba claro dónde incorporar la tarea, cómo entender si la llevaron al sprint mensual o no. Y en general, el Dock de Google parecía repulsivo.
Problema 2. El tablero Kanban no refleja la realidad.
Además de los problemas con los clientes, tuvimos un problema con el mantenimiento de la relevancia de la lista de tareas tanto en el tablero como en la cartera de pedidos. En el trabajo atrasado hubo tareas de la época de los reyes, y simplemente se perdieron nuevas tareas. Solo las tareas con plazos o con la mayor importancia para el equipo se aprobaron en el tablero. Todas las demás tareas se acumulaban en algún lugar debajo, en las profundidades del tablero, repitiendo el trabajo atrasado y aumentando la cola de tareas en todo, sin ninguna esperanza.
Problema 3. El equipo no tiene claro qué sucede con las tareas.
Dentro del equipo no había una comprensión clara de dónde vendrían las tareas, qué será lo próximo y qué pasará con los que se encuentran en la parte inferior del tablero kanban. Aquellos que se comprometieron a sumergirse en las complejidades del proceso no compartieron las alegrías de la planificación e intentaron nunca volver al papel de un "plan maestro". La mayoría eran ignorantes.
En general, nada está claro para nadie, las tareas se están acumulando, los clientes están enojados, el equipo no profundiza en el proceso, porque es complicado y usted necesita hacer algo con todo esto. De todos los problemas, dedujimos una lista de pasos que resolvieron dos problemas: hacerlo transparente para el cliente y hacer que el equipo sea transparente.
Hacer al cliente transparente
- Abandonaron las tareas de embestida de todo tipo en un sprint grande y complejo. Como antes, un conjunto de tareas importantes para todo el departamento se lleva a cabo cada pocos meses, después de lo cual las tareas imprescindibles para el próximo período son claras. En el pasado, tratamos de romperlos y empacarlos por mes, prometiendo liberar todas las tareas para fin de mes. El incumplimiento de algunas tareas causó que el cliente no entendiera cuándo serán liberados. Ahora damos una estimación de cuántos de ellos se incluirán en unos pocos meses, y aproximadamente los desglosamos por meses. En este caso, le damos al cliente una evaluación más vaga del momento, por ejemplo, se realizará en febrero o marzo, pero dichos acuerdos se adaptan a los clientes. Esto les dio una comprensión de lo que haríamos sin hacer promesas falsas o sobrecargar el sprint.
- Pasó de la priorización en guglodok a la priorización en jira. La práctica se extendió a la deuda técnica, tareas de los clientes y tareas de soporte del producto. Con esto, resolvimos el problema de la complejidad de la herramienta.
- Se niega a priorizar las tareas no imprescindibles de los clientes. "Si no puede determinar la prioridad, cambie esta tarea a la herramienta", pensamos, y se nos ocurrió la herramienta "carrusel de clientes".
El algoritmo del carrusel es el siguiente: una vez a la semana, además del conjunto principal de tareas imprescindibles, tomamos otra tarea del cliente. De quién exactamente está determinado por la tabla, lo mismo que en el ejemplo a continuación. Y dado que el orden es circular, de ahí el nombre del instrumento.
Las prioridades entre sus tareas las establece el propio cliente, eligiendo entre nuestra cartera de pedidos, que está marcada personalmente para él. Para que el trabajo con la cartera de pedidos sea cómodo tanto para los clientes como para nosotros, hemos hecho lo siguiente:
- Archivó todas las tareas de la cartera de pedidos anterior a un año. Fue muy agradable, teniendo en cuenta la antigüedad de los problemas. El boleto más antiguo ha estado allí por más de 4 años.
- Marque manualmente todas las tareas con la etiqueta personal del cliente para que pueda configurar filtros rápidos en el tablero en jira, dentro de los cuales el cliente determina la prioridad entre sus tareas. El trabajo es enorme, pero el resultado definitivamente valió la pena. El cliente ve una lista de todas las tareas que ha creado, cambia las prioridades, sin notificar al equipo.
- Después de que fue conveniente trabajar con el trabajo atrasado, volvimos a los orígenes de kanban y nuevamente comenzamos a contar y centrarnos en las tareas de tiempo de ciclo, el tiempo promedio por el cual una tarea pasa a través de un tablero de kanban. Esta cifra ahora le dice al cliente cuánto tiempo su tarea llegará al lanzamiento y cuándo llegará al tablero. Es decir, el problema de previsibilidad se está resolviendo.
Haz que el equipo sea transparente
- Poner las cosas en orden en el tablero. Todo lo que es innecesario e irrelevante, que se encuentra en el profundo todo, se cerró, y lo que hay que hacer se coloca en la cartera de pedidos. El tablero kanban nuevamente comenzó a reflejar el flujo de tareas tal como es. La introducción de límites en la cola antes del desarrollo - todo - y en la cola antes del lanzamiento al lanzamiento - hecho - ayudó a mantener el tablero actualizado. Para recordarle al equipo sobre la necesidad de monitorear las restricciones, escribieron un bot que, en caso de violación de los límites, escribe sobre esto en el chat del equipo. Aquí, después de haber matado a dos pájaros de un tiro, resolvimos el segundo y el tercer problema del proceso pasado: el tablero refleja la realidad y el equipo comprende lo que está sucediendo.
- Dado que el trabajo atrasado es una herramienta de planificación de tareas, debe mantenerlo actualizado. A la luz de todos los cambios, tuvimos una reunión regular, donde revisamos colectivamente las tareas que han llegado y hacemos preguntas sobre los términos y requisitos. Una gran ventaja de esta solución es que los requisitos se especifican / escriben antes de que la tarea llegue al tablero, es decir, realizamos análisis simplificados por adelantado, sin perder tiempo durante el desarrollo.
Todas las tareas que han superado las preguntas de prueba del equipo reciben una calificación adicional que les permite ingresar al tablero.
El papel del "plan maestro" ha evolucionado para complementar el papel del oficial de servicio a cargo del apoyo del proyecto durante la semana. Necesita lanzar tareas en el tablero y celebrar una reunión semanal.
No hay más dolor en averiguar las prioridades y tratar de empujar todo a la vez en una carrera llena de gente. No hay muchas horas de discusiones y aclaraciones sobre los requisitos para una gran cantidad de tareas que se presentaron en un mes; con un análisis semanal, el proceso avanza rápidamente y hay pocas tareas. Las tareas siempre están a la vista y todo el equipo en el contexto de lo que quieren los clientes.
Como
Después de que se resolvieron todos los problemas obvios, se hizo más transparente para todos los participantes, y ahora puede participar en el proceso sin perder sus nervios y mucho tiempo. Aunque esta no es la versión final del proceso de planificación, hay margen de mejora en todas partes.
Lo que quiero hacer a continuación:
- Automatice el proceso de llevar las tareas al tablero kanban. Ahora las tareas son tomadas del trabajo atrasado por la persona de turno, quien durante una semana monitorea la presencia de tareas en el tablero. Me gustaría que una parte de las tareas (o, posiblemente, todos sus tipos) se muevan automáticamente a todo, si es necesario.
- Automatice el proceso de interacción con los clientes y trabaje con el carrusel. Una posible solución sería implementar un bot que le recuerde al próximo cliente que verifique las prioridades de sus tareas.
- Automatice las tareas de extracción con plazos, si corresponde. Es decir, solo agregue automatización para rastrear tales tareas.
¿Resolvió alguno de estos problemas? Comparte ideas en los comentarios.
¿Quieres continuar? Únase a la transmisión en
vivo DevDay
Manage IT de mañana.