— Привет!
— Привет!
— Скажи, а каково это — делать техническую поддержку?
— Ну-у-у, представь себе велосипед… и он горит… и ты горишь… и дорога горит… и вообще, ты в аду…
(с) автор не известен
Не важно кто вы, новичок или опытный менеджер, каждый из нас сталкивался с ситуацией, когда задач много, они приходят из разных источников и конца и краю этому не видно. Еще в качестве «контрольного выстрела» кто просит все сделать еще вчера. Узнали в этом абзаце себя? Тогда данная статья вам в помощь.
Я расскажу с какими основными проблемами столкнулся в работе, когда мне только-только передали управление тех.поддержкой, куда эти проблемы делись и как мы живем сейчас, спустя 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 это не только «сухая» методика, но и система ценностей и принципов, которые направлены на непрерывное улучшение и адаптацию текущих процессов. Нет предела совершенству, поэтому только вперед!
Автор: DeadMoose
