Эксперимент с канбан-доской или как всё успеть
Иногда бывает, что после затяжного простоя начинают появляться ресурсы, специалисты, руководство поддерживает и поощряет изменения и инновации. Вместе с этим появляются желания и идеи, как много можно усовершенствовать, оптимизировать и быть действительно опорой бизнесу компании. Конечно, на первом дыхании можно сделать очень много, особенно, когда вначале почти непаханое поле. Но позже, настает такой момент, когда IT инфраструктура достаточно разрослась и решения на любые изменения и внедрения принимаются не так быстро и легко, как это было в самом начале. Причиной тому те самые внедрения и инновации, теперь их уже нужно сопровождать, поддерживать, и несмотря на то, что IT отдел подрос, ресурсов недостаточно — перед нами большая, сложная и функционирующая система. Но как же планы? Как же те идеи? Их еще осталось очень много.
Сейчас я хочу рассказать вам об эксперименте с канбан-доской, который дал великолепный результат в IT отделе далеко не IT-шной компании. Рабочий процесс с таким инструментом стал более контролируем и управляем, зависимость задач относительно каждого специалиста стала более прозрачна. Теперь всегда можно с уверенностью сказать, что отдел работает на все 100% и мы движемся к конкретным результатам, которые с большей вероятностью будут достигнуты.
Исходное состояние
Допустим, у нас есть несколько специалистов разного направления и квалификации. Перед нами поставлены несколько больших задач или проектов и наша цель — организовать процесс так, чтобы задействовать каждого с максимальной отдачей, в соответствии с его возможностями, как специалиста. Нужно так же учитывать, что есть постоянная рутина, которая с разной периодичностью влияет на занятость любого сотрудника.
Описанные выше реалии — это наша исходная точка. Переходим к подготовке…
Проектирование
На первом этапе нужно разделить каждый проект на атомарные составляющие. В идеале эти задачи нужно выделить и поставить так, что бы их можно было выполнять, не вникая в общую суть вопроса. Кроме этого, каждая задача должна быть сформирована от начала до конца с конкретными метриками и обозначенным конечным результатом.
Далее, в рамках каждого проекта, расставляем зависимость каждой задачи друг от друга. Для этого мы пронумеруем каждую задачу и укажем от каких других задач она зависит. Результатом будет план реализации каждого проекта.
Пример:
Создать виртуальную машину на ESXi #2, с параметрами Name: ServerABC, Guest: Ubuntu x64, RAM: 2 Gb, HDD: 20Gb Pre-allocated
(after: #1) Установить Ubuntu Server 12.04 x64 на виртуальный сервер ServerABC (ESXi #2); разбить HDD: root 2Gb, swap 2Gb, home все оставшееся; IP: 192.168.0.7; hostname: ABC.com; user: abc pass: abc
- …
Работу по разработке проекта и его планированию легко выполняет профильный специалист. После этого проект переходит к руководителю, а специалисты продолжают заниматься выполнением своих текущих непосредственных обязанностей.
Тикет-стикер
После подготовки, у нас на руках есть несколько массивов задач, выполнение которых приведет нас к достижению конкретных целей. В качестве визуального контроля и управления будем использовать канбан-доску, а для сопровождения и детального контроля какую-нибудь тикетную систему (например trac).
Используя эти инструменты, подготовим наши проекты к исполнению. В тикетной системе для каждого проекта создадим отдельный тикет, в который поместим подготовленный план. Далее, по мере начала работ по каждой задачи, будем создавать подтикеты для сопровождения ее исполнения.
Так как наш план уже детально описан и помещен в тикетную ситему (в основной проектный тикет), для визуализации его на доске остается только вкратце переписать каждую задачу на стикер. Подготовленные стикеры размещаем на доске, группируя их по проектам.
Пример стикера:
Поле действия
Подготовка закончена и теперь рассмотрим канбан-доску, с помощью которой будем управлять развитием событий. В отличие от «традиционного» течения слева направо, в этой стикеры будут спускаться вниз по следующим этапам, начиная с «пула»:
- Пул — самое большое место на доске, в котором находятся сгруппированные по проектам задачи. Область намеренно не размечена на участки, чтобы проекты занимали только необходимое пространство, так как они сами образуют область определенного цвета. Более того, термин «проект» в повседневной жизни IT отдела часто может означать просто большую задачу, которую можно разложить на подзадачи.
- Очередь — ближайший краткосрочный план на исполнение. В этот раздел доски помещаются все задачи намеченные на исполнение в ближайшее время, и он используется в основном при реализации быстро идущих или приоритетных проектов. На практике для большинства задач раздел пропускается, и задачи из пула попадают сразу исполнителю в работу.
- Выполнение — этот этап явно разделен на области соответствующие конкретному исполнителю. Выбирая исполнителя нужно учитывать тот факт, что решение некоторых задач может занять одинаковое время, как у высококвалифицированного специалиста, так и у начинающего. Но цели оптимизации исполнения могут быть разными, и как раз на этом этапе можно явно выбрать стратегию достижения цели. Например, мы можем менее требовательные к квалификации и несрочные задачи пропускать через начинающих специалистов, предоставляя им шанс для саморазвития. Естественно, срочные и важные работы нужно направлять на подготовленных специалистов. В общем, стратегий может быть множество, но самое главное мы видим в реальном времени, как у нас идет процесс, и мы оперативно можем подстраиваться под текущую рабочую ситуацию.
- Проверка — так же, как и предыдущий этап разделен на исполнителей, но носит вспомогательный характер и похож на процесс Quality Assurance. Задачи помещаются в него, например, для получения фидбека от другого специалиста или для проверки специалистом, который владеет наибольшей компетенцией. Этот этап так же можно пропускать, если в проекте явно предусмотрен QA в отдельной задаче или сторонняя проверка не требуется.
- Готово — финальный этап в котором все выполненные стикеры собираются в маленькие книжечки проектов.
Для явного обозначения занятости специалистов и невозможности их участия в работах по намеченным проектам, можно использовать магниты определенного цвета, например красного. Так же можно обозначать зеленным магнитом, что специалист свободен и может участвовать в каком-нибудь проекте. Часто зеленые магниты висят на специалистах, для которых на определенный момент нет подходящей задачи, и мы бы очень хотели занять их сразу, как только такая задача найдется.
«Готово»
Надеюсь, предложенный мною инструмент или его усовершенствованный вами вариант поможет грамотно и оперативно управлять потоком интересных и приятных проектов, которые вы ставите себе сами или теми, что ставит перед вами бизнес. Удачи!
Автор: BanderasPRO