— Привет!
— Привет!
— Скажи, а каково это — делать техническую поддержку?
— Ну-у-у, представь себе велосипед… и он горит… и ты горишь… и дорога горит… и вообще, ты в аду…

(с) автор не известен

Не важно кто вы, новичок или опытный менеджер, каждый из нас сталкивался с ситуацией, когда задач много, они приходят из разных источников и конца и краю этому не видно. Еще в качестве «контрольного выстрела» кто просит все сделать еще вчера. Узнали в этом абзаце себя? Тогда данная статья вам в помощь.

Я расскажу с какими основными проблемами столкнулся в работе, когда мне только-только передали управление тех.поддержкой, куда эти проблемы делись и как мы живем сейчас, спустя 3 года. Говоря проще, как некоторые приемы и принципы Kanban помогли лично мне и в целом команде ощутимо снизить нагрузку на специалистов.

Какие, собственно, были проблемы?

Самые распространенные для управления проектами в сфере IT (и не только):

• большие списки задач;
  
• подгоняющие менеджеры;
  
• огромное количество источников этих самых задач;
  
• срывы сроков;
  
• обиды на всех.
  

Ха, да что тут страшного?! Берешь задачу и делаешь — вот и все волшебство с кроликом. Так-то да, но вот только похоже, что «зайцы у нас были бракованные».

Новые задачи прибывали каждый день, а время жизни старых увеличивалось в геометрической прогрессии. На каждом специалисте количество задач измерялось десятками и конца этому видно не было.

Страдали все, кто был задействован в цепочке, от программиста до клиента, который, как нам казалось, умывался нашими слезами (на самом деле я верю в то, что ему было еще хуже, чем нам, и мы искренне делали на тот момент все возможное).

Какие варианты решения были предприняты

Естественно, нам было ясно, что так продолжаться больше не может и нужно что-то исправлять. Нашли в себе силы и начали искать решения. 

Ниже кратко расскажу о парочке самых «крутых» вариантах и одном хорошем.

План на 7-14 дней с конечной датой выполнения

Да, дурачками были, но опыт полезный.

В чем суть идеи: 

• по каждой задаче выясняли сколько на нее уйдет времени в человеко-часах;
  
• на каждую дату в течение ближайших 2 недель назначался определенный список задач;
  
• этот список формировался исходя из суммарного времени, которое предполагалось потратить, и располагаемого рабочего времени (у нас это фактических 7 человеко-часов);
  
• сами задачи сразу назначаются на специалистов так, чтобы полностью забить его на 7 часов работой.
  

Круто! Теперь у нас есть четкий план и мы знаем какая задача когда будет сделана!  Вот оно — спасение! 

Через день после этих слов наступил «менеджерский АД».

Немного лирики.
Специфика тех.поддержки (как минимум у нас) при множестве разных проектов такова, что у тебя никогда нет конечного списка запланированных задач (далее бэклог) на ближайшую неделю. Даже бэклог на 3 дня — нечто из разряда фантастики. В любой момент может прилететь задача, которую необходимо сделать прямо сейчас (иногда это оправдано, иногда нет, но речь не об этом).

А теперь, что конкретно я имею в виду под «менеджерским адом».



Новоиспеченная задача из разряда «здесь и сейчас» полностью ломала весь план. Мало того, что приходилось двигать задачи для текущего дня, приходилось сдвигать задачи на все 2 недели. Логично, т.к. если этого не делать, то у специалиста получался бы список, который превосходит 7 человеко/часов в день, а для нас в данном случае это было недопустимо. 

На эти движения тратилось чудовищное количество времени и сил, как умственных, так и физических.

От этого любая просьба менеджеров воспринималась «в штыки», а любая новая задача становилась катастрофой.

Пожалуй, это самое «крутое» решение, по которому мы пытались работать.

Формирование списка задач для специалистов на основе категорий

Вселенная относительно вовремя объяснила (могла бы и пораньше), что для постоянно прибывающих задач ставить конкретное время выполнения и строить на основе этого продолжительный план совсем не вариант. Приняли, поняли, отказались от этого.

Но ведь и в общий список программистов не запустишь, потеряются бедолаги. Как раз, чтобы этого избежать мы придумали систему категорий для задач (мелкая, средняя, большая и очень большая) и стали распределять все по категориям.

В чем суть идеи:

• по примерной предварительной оценке присваиваем задаче свою категорию — мелкая, средняя, большая и очень большая;
  
• каждая категория имеет свое постоянное среднее время выполнения, что-то похожее на Story Points (а может они и были);
  
• каждому спецу формируется свой отдельный список задач исходя из комбинации категорий. Например: 4 мелких + 2 средних; 3 мелких + 1 большая; 6 мелких; 1 очень большая и т.д
  
• и так на ближайшие 3 дня (план же нужен, хотя бы самый кривенький).
  

УРА, наконец-то! Ребят, у нас все получи-и-и… Вот где-то тут Космос перезарядил свое ружье и стал в нас палить. Что же с этим решением было не так?

1. Поздно начали вести базу типовых задач для упрощения присвоения категории.
   
2. Приходилось следить за очередями на каждом отдельном специалисте (правда времени уходило сравнительно меньше, чем двигать по несколько раз в день даты релизов).
   
3. Проблема со срочными задачами вне очереди никуда не ушла — они все так же заставляли переформировывать списки.
   

Вроде и неплохое решение. Чуть лучше, чем первый вариант, но все также не гибко в плане возникающих срочных и важных задач.

Методика основанная на вытягивающей системе (Kanban)

Совершенно случайно я попал на один бесплатный часовой вебинар, посвященный Agile и некоторым методикам на его основе (конечно же, это была реклама курсов). И вот, только после основной части кто-то упомянул Kanban, как хорошо зарекомендовавшую себя методику для технической поддержки и не только.

Воодушевившись новой информацией, начались дни чтения про это чудо менеджмента. Информацию раздобыли, теперь готовы к эксперименту с адаптированной под нас (текущих) методикой.

В чем суть идеи:

• у специалистов НЕТ собственной очереди;
  
• все задачи, которые готовы к работе перемещаются в общий бэклог (буфер);
  
• из этого буфера формируется текущая очередь (план). Эта очередь не имеет конечной даты выполнения — она актуальна именно на данный момент, в данную секунду;
  
• в текущую очередь задачи попадают на основе собственных приоритетов тех. менеджера (срок жизни задачи, срочность и т.п);
  
• у текущей очереди есть лимит по количеству задач в ней;
  
• все специалисты подразделения видят одну и ту же текущую очередь;
  
• по завершении текущей задачи вытягивается самая верхняя и так по очереди.
  

Хорошо! Придумали, всем рассказали как делать, смотрим. Ребята-а-а, серьезно?!

Какими были результаты через 1,5 календарной недели: 

1. Мы сократили количество текущих задач на одной только Разработке с 75 до 25!!! И это при условии, что входящий поток задач оставался прежним
   
2. Уменьшили количество негатива по поводу сроков
   
3. В процессах появилась гибкость
   

И это только то, что было видно сразу.

А как же так вышло, что все более или менее заработало? Мои мысли по этому поводу таковы:

• Программисты перестали сами выбирать в работу самую понятную задачу. Теперь очередью управлял менеджер и ставил в План только самые нужные в данный момент задачи (это ключевой момент).
  
• Подобное вытягивание напрямую повлияло и на уменьшение негатива со стороны менеджеров и клиентов. Почему? Да потому что не бывает одинаково срочных задач на одном проекте и негатив скорее всего провоцировала самая ценная на данный момент.
  
• Гибкость и грация как у кошки, и иногда ловкость картошки — вытягивающая система позволила нам реагировать на важные и срочные задачи без потери и траты времени на изменение очереди. Переводим нужную задачу в План и убираем из него более свежую (помним про ограничение в Плане?).
  

Итоги

Если Вы сталкиваетесь с большим потоком задач, пусть даже из одного источника, и не чувствуете, что велосипед горит больше, чем хотелось бы, то обратите свой взор на Kanban. Основываясь на принципах этой методики, ее можно достаточно безболезненно внедрить в текущие бизнес процессы.

На данный момент мы адаптировали вытягивающую систему под свои нужды, нормализовали поставку релизов. Конечно, случаются и «запары», но система через некоторое время приходит в относительную норму исходя из текущих возможностей. 

Так же стоит понимать, что Kanban это не только «сухая» методика, но и система ценностей и принципов, которые направлены на непрерывное улучшение и адаптацию текущих процессов. Нет предела совершенству, поэтому только вперед!