32

Усвоенные уроки

С уменьшением НЗР появляются ограничения

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

Сначала менеджеры хотели, чтобы параллельно выполнялось несколько проектов, но через несколько недель стало очевидно, что для менее приоритетных проектов не хватает ресурсов. Одного взгляда на доску было достаточно, чтобы убедиться: ни одна из задач с низким приоритетом так и не была начата. Это подтолкнуло менеджеров к сокращению количества проектов на команду.

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

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

Это все было понятно и до начала нашей работы по Kanban. А вот что было непонятно, так это с чего начать, и как об этом договориться со всеми заинтересованными. Когда появилась Kanban-доска,

каждый смог увидеть, как конкретная проблема влияет на поток. Это помогло скоординировать усилия по еѐ решению между разными отделами организации.

Доска по ходу работы будет меняться, поэтому не отливайте еѐ в бронзе!

Все наши Kanban-доски изменялись по ходу работы. Как правило, внешний вид доски менялся два-три раза, пока команды не находили удобный для себя формат. Поэтому тратить много времени на первый дизайн доски, скорее всего, не имеет смысла. Убедитесь только, что вы можете легко менять еѐ внешний вид. Мы, например, обозначали столбцы и строки черной изолентой. Изолента легко переклеивалась, к тому же еѐ можно было клеить и на доску, и на стену. Ещѐ я видел, что линии рисовали толстым маркером (только убедитесь, что он стирается :-).

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

Рисунок 14. Ранняя Kanban-доска с наклейками для текущих приоритетов

Не бойтесь экспериментировать и ошибаться

Урок, который я извлек из этого приключения, состоит в том, что конца-то у него и нет. Как только мы решим, что закончили внедрение Kanban, мы автоматически совершим большую ошибку. Это путь постоянных экспериментов и непрекращающегося обучения. Но невозможно учиться, не делая ошибок. По ходу работы у нас было достаточно ошибок (плохой дизайн доски, оценивание задач, никому не нужный burndown ..) – но каждый раз мы учились чему-то новому и важному. Если бы мы перестали пробовать, как бы мы тогда могли научиться?

Успехи Kanban вдохновляют менеджеров и разработчиков, работающих по Scrum, начать экспериментировать с Kanban-досками. Надеюсь, эта книга им поможет!