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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итоги

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

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

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

Как мы тушили велосипед техподдержки