- hola!
- hola!
- Dime, ¿cómo es hacer soporte técnico?
- Bueno, imagina una bicicleta ... y se quema ... y tú ardes ... y la carretera arde ... y, en general, estás en el infierno ...

(c) el autor es desconocido

No importa quién sea usted, un novato o un gerente experimentado, cada uno de nosotros ha enfrentado una situación en la que hay muchas tareas, provienen de diferentes fuentes y el final no es visible hasta el borde. Incluso como una "toma de control", alguien pide hacer todo ayer. ¿Te reconociste en este párrafo? Entonces este artículo te ayudará.

Te diré qué problemas principales encontré en mi trabajo cuando me entregaron la gestión de soporte técnico, dónde se fueron estos problemas y cómo vivimos ahora, después de 3 años. En pocas palabras, cómo algunos trucos y principios de Kanban me han ayudado personalmente y al equipo en general a reducir significativamente la carga sobre los especialistas.

¿Cuáles fueron los problemas reales?

Lo más común para la gestión de proyectos en el campo de TI (y no solo):

• Grandes listas de tareas
  
• gerentes de montaje;
  
• una gran cantidad de fuentes de estas mismas tareas;
  
• incumplimiento de plazos;
  
• resentimiento en absoluto.
  

Ja, ¿qué es tan terrible? Tomas la tarea y la haces, eso es toda la magia con el conejo. Entonces sí, pero parece que "nuestra liebre era defectuosa".

Nuevas tareas llegaron todos los días, y la vida útil de las antiguas aumentó exponencialmente. En cada especialista, el número de tareas se midió en docenas y no había un final a la vista.

Todos los que estaban involucrados en la cadena sufrieron, desde un programador hasta un cliente que, según nos pareció, se estaba lavando las lágrimas (de hecho, creo que era aún peor que nosotros, y sinceramente hicimos todo lo posible en ese momento )

¿Qué soluciones se han tomado?

Naturalmente, nos quedó claro que esto ya no puede continuar y que algo debe repararse. Encontramos la fuerza y ​​comenzamos a buscar soluciones.

A continuación, hablaré brevemente sobre un par de opciones "geniales" y una buena.

Plan de 7-14 días con fecha de vencimiento final

Sí, eran tontos, pero la experiencia fue útil.

¿Cuál es la esencia de la idea?

• para cada tarea, descubrimos cuánto tiempo llevará en horas hombre;
  
• se asignó una lista específica de tareas para cada fecha durante las próximas 2 semanas;
  
• esta lista se formó sobre la base del tiempo total que se suponía que debía gastarse y el tiempo de trabajo disponible (tenemos 7 horas hombre reales);
  
• las tareas mismas se asignan de inmediato a especialistas de tal manera que lo llenen completamente de trabajo durante 7 horas.
  

Genial! ¡Ahora tenemos un plan claro y sabemos qué tarea se hará cuando! Aquí está: ¡salvación!

Un día después de estas palabras llegó el "BP gerencial".

Un poco de letra.
Los detalles del soporte técnico (al menos con nosotros) con muchos proyectos diferentes es tal que nunca tendrá una lista final de tareas programadas (trabajo atrasado) para la próxima semana. Incluso un retraso de 3 días es una especie de categoría de fantasía. En cualquier momento, una tarea puede volar y debe hacerse en este momento (a veces está justificada, a veces no, pero no se trata de eso).

Y ahora, ¿qué quiero decir exactamente con "infierno gerencial"?



La nueva tarea de la categoría de "aquí y ahora" rompió por completo todo el plan. No solo tuvo que mover las tareas para el día actual , sino que tuvo que cambiar las tareas durante las 2 semanas . Es lógico porque Si esto no se hace, el especialista obtendría una lista que excede las 7 personas / horas por día, pero para nosotros en este caso era inaceptable.

Se invirtió una enorme cantidad de tiempo y esfuerzo en estos movimientos, tanto mentales como físicos.

A partir de esto, cualquier solicitud de los gerentes se percibió "con hostilidad", y cualquier nueva tarea se convirtió en un desastre.

Quizás esta sea la decisión "más genial" en la que intentamos trabajar.

Crear una lista de tareas para especialistas basada en categorías

El Universo relativamente oportuno explicó (podría haber sido antes) que para las tareas que llegaban constantemente no era una opción establecer un tiempo de ejecución específico y construir sobre la base de esto. Aceptado, entendido, abandonado esto.

Pero tampoco se encontrará con la lista general de programadores, se perderán los tipos pobres. Solo para evitar esto, creamos un sistema de categorías para tareas (pequeñas, medianas, grandes y muy grandes) y comenzamos a distribuir todo en categorías.

¿Cuál es la esencia de la idea?

• de acuerdo con una evaluación preliminar aproximada, asignamos nuestra categoría a la tarea: pequeña, mediana, grande y muy grande;
  
• cada categoría tiene su propio tiempo de ejecución promedio constante , algo similar a Story Points (o tal vez lo fueron);
  
• Cada especialista tiene su propia lista de tareas por separado basada en una combinación de categorías. Por ejemplo: 4 pequeñas + 2 medianas; 3 pequeños + 1 grande; 6 pequeños; 1 muy grande, etc.
  
• y así durante los próximos 3 días (se necesita el plan, al menos el más torcido).
  

Hurra, por fin! Chicos, tenemos todo lo que hay que buscar y ... Aquí, en algún lugar de Cosmos, volvió a cargar su arma y comenzó a dispararnos. ¿Qué estaba mal con esta decisión?

1. Tarde, comenzamos a mantener una base de tareas típicas para simplificar la asignación de una categoría.
   
2. Tuve que seguir las colas en cada especialista individual (aunque me llevó relativamente menos tiempo que mover las fechas de lanzamiento varias veces al día).
   
3. El problema con las tareas urgentes fuera de turno no llegó a ninguna parte, todavía se vieron obligados a volver a formar listas.
   

Parece ser una buena solución. Ligeramente mejor que la primera opción, pero aún así no es flexible en términos de tareas urgentes e importantes emergentes.

Técnica basada en sistema de extracción (Kanban)

Por casualidad, llegué a una hora de seminario web gratuito dedicado a Agile y a algunos métodos basados ​​en él (por supuesto, era un anuncio de cursos). Y así, solo después de la parte principal, alguien mencionó a Kanban como una técnica bien establecida para el soporte técnico y no solo.

Inspirados por la nueva información, comenzaron los días de lectura sobre este milagro de gestión. Obtuvimos la información, ahora estamos listos para experimentar con la metodología (actual) adaptada para nosotros.

¿Cuál es la esencia de la idea?

• los especialistas NO tienen su propia cola;
  
• todas las tareas que están listas para trabajar se mueven a una Cola común;
  
• a partir de esta Cola se forma el Plan actual. Un plan es una lista de tareas que no tiene una fecha de ejecución final y es relevante en este momento, en este segundo;
  
• las tareas se incluyen en el Plan actual sobre la base de esas prioridades. Gerente (vida de la tarea, urgencia, etc.);
  
• el Plan tiene un límite en el número de tareas en él;
  
• todos los especialistas de la unidad ven el mismo Plan actual;
  
• Después de completar la tarea actual, el especialista dibuja la siguiente más alta y así sucesivamente.
  

Bueno! Se les ocurrió, les dijeron a todos cómo hacerlo, miramos. Chicos, ¿en serio?

¿Cuáles fueron los resultados después de 1.5 semanas calendario?

1. ¡Hemos reducido el número de tareas actuales en el desarrollo solo de 75 a 25! Y esto siempre que el flujo de tareas entrantes permanezca igual
   
2. Reduce la cantidad de negatividad sobre el tiempo
   
3. Flexibilidad en los procesos.
   

Y esto es justo lo que fue inmediatamente visible.

¿Pero cómo sucedió que todo funcionó más o menos? Mis pensamientos sobre esto son:

• Los programadores mismos ya no eligen la tarea más comprensible . Ahora el gerente manejó la cola y puso en el Plan solo las tareas más necesarias en este momento (este es un punto clave).
  
• Tal atracción influyó directamente en la reducción de la negatividad por parte de los gerentes y clientes. Por qué Sí, porque no hay tareas igualmente urgentes en un proyecto y lo negativo probablemente provocó lo más valioso en este momento.
  
• La flexibilidad y la gracia de un gato, y a veces la agilidad de las papas: el sistema de extracción nos permitió responder a tareas importantes y urgentes sin perder o perder el tiempo cambiando la cola. Traducimos la tarea necesaria al Plan y eliminamos la más reciente (¿recuerda la restricción en el Plan?).
  

Resumen

Si se enfrenta a un gran flujo de tareas, incluso de una fuente, y no siente que la bicicleta se está quemando más de lo que quisiéramos, entonces dirija sus ojos a Kanban. Basado en los principios de esta metodología, puede implementarse sin problemas en los procesos comerciales actuales.

Por el momento, hemos adaptado el sistema de extracción a nuestras necesidades, normalizado el suministro de lanzamientos. Por supuesto, también ocurre "ensuciamiento", pero después de un tiempo el sistema llega a una norma relativa basada en las capacidades actuales.

También vale la pena entender que Kanban no es solo una metodología "seca", sino también un sistema de valores y principios que tienen como objetivo la mejora continua y la adaptación de los procesos actuales. No hay límite para la perfección, por lo tanto solo hacia adelante