Успеть всё

Иногда бывает, что после затяжного простоя начинают появляться ресурсы, специалисты, руководство поддерживает и поощряет изменения и инновации. Вместе с этим появляются желания и идеи, как много можно усовершенствовать, оптимизировать и быть действительно опорой бизнесу компании. Конечно, на первом дыхании можно сделать очень много, особенно, когда вначале почти непаханое поле. Но позже, настает такой момент, когда IT инфраструктура достаточно разрослась и решения на любые изменения и внедрения принимаются не так быстро и легко, как это было в самом начале. Причиной тому те самые внедрения и инновации, теперь их уже нужно сопровождать, поддерживать, и несмотря на то, что IT отдел подрос, ресурсов недостаточно — перед нами большая, сложная и функционирующая система. Но как же планы? Как же те идеи? Их еще осталось очень много.
img src=«habrastorage.org/storage2/bcb/d90/fc5/bcbd90fc556915157e91527c2097a3a6.png» align=«right»/

Сейчас я хочу рассказать вам о своем эксперименте с канбан-доской, который дал великолепный результат в IT отделе далеко не IT-шной компании. Работа с таким инструментом стала более контролируема и управляема, зависимость задач относительно каждого специалиста стала более прозрачна. Теперь всегда можно с уверенностью сказать, что отдел работает на все 100% и мы движемся к конкретным результатам, которые с большей вероятностью будут достигнуты.

Исходное состояние

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

Описанные выше реалии — это наша исходная точка. Переходим к подготовке…

Проектирование

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

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

Пример:

1. Создать виртуальную машину на ESXi #2, с параметрами Name: ServerABC, Guest: Ubuntu x64, RAM: 2 Gb, HDD: 20Gb Pre-allocated
2. (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 в отдельной задаче или сторонняя проверка не требуется.
• Готово — финальный этап в котором все выполненные стикеры собираются в маленькие книжечки проектов.

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

«Готово»

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