Дэвид Андерсон - Канбан. Альтернативный путь в Agile
Эти расходы подробнее обсуждаются в следующих параграфах. Буду описывать их при помощи простого примера – покраски забора вокруг моего дома в Сиэтле.
Операционные расходы
Забор состоит из 21 секции. Потребительская ценность создается, если секция забора покрыта морилкой. Полная потребительская ценность получается, когда все секции покрашены с обеих сторон.
Прежде чем начать работу, нужно было найти материалы. Для этого я поехал в магазин Home Depot. Кроме того, требовалось подготовиться: провести мелкий ремонт забора, его шлифовку, подрезку деревьев и кустов, чтобы можно было пройти к забору. Все эти действия не создают ценность. Заказчику неинтересно, что мне нужно ехать в Home Depot и это требует времени.
Более того, все это раздражает, потому что начало и окончание проекта в результате откладываются. Все эти действия отсрочивают начало работы, создающей ценность.
Итак, чтобы начать работу, создающую ценность, необходимо провести несколько подготовительных мероприятий.
Могут понадобиться и другие действия: например, планирование, оценка и определение ожиданий. Клиенту может быть представлена стоимость работы и дата ее выполнения. (В данном случае будем считать, что клиент – моя жена.)
Когда дело наконец доходит до покраски, выясняется, что с 42 секциями забора (если считать обе стороны) невозможно управиться за один подход. Приблизительная скорость работы – четыре секции в час. Поэтому было решено разбить задачу на шесть этапов. Если бы речь шла о разработке ПО, мы бы назвали их итерациями или спринтами; в производстве это партии. Перед тем как начинать каждый этап покраски, также требовался ряд подготовительных мер. Надо было переодеться, доставить материалы: я переносил краску, кисти и другие инструменты из гаража к месту работы и только после этого начинал красить.
Итак, и проекты, и итерации предполагают подготовительные мероприятия.
Поработав пару часов, я обычно чувствовал потребность в перерыве. Допустим, наступало время обеда. Однако я не мог все бросить и начать есть. Сначала нужно было закрыть банку с краской, вымыть кисти либо бросить их в емкость с водой, чтобы они не засохли, пока меня нет. Потом требовалось привести себя в порядок – помыть руки и переодеться. И только после этого я отправлялся обедать.
По окончании проекта у меня может остаться немного морилки, а в Home Depot принимают обратно полные банки и возвращают за них деньги. Поэтому требуется еще одна поездка.
Итак, как итерации, так и проекты предполагают завершающие мероприятия.
С экономической точки зрения подготовительные и завершающие мероприятия – это операционные расходы. Каждое действие, создающее ценность, имеет связанные с ним операционные расходы. Клиент чаще всего их не видит, редко ценит и относится в лучшем случае со смешанными чувствами. Его можно заставить оплатить эти расходы, но он предпочел бы этого не делать. Наверняка вам приходилось приглашать мастера чинить стиральную или посудомоечную машину и платить за вызов 90 долларов. Это операционные расходы. Возможно, вы бы предпочли заплатить меньше или выбрали сантехника, который не берет плату за вызов? Операционные расходы не создают ценности. Они необходимы, но с точки зрения концепции бережливого управления считаются потерями.
Итак, два первых типа потерь – это операционные расходы: подготовительные (или начальные) и завершающие (или конечные).
Если вернуться к проблемам разработки ПО, то становится понятно, что у всех проектов есть свои подготовительные меры: планирование проекта, планирование ресурсов и набор персонала, бюджетирование, оценка, планирование рисков, планирование связи, приобретение необходимых мощностей и т. д. Большинство проектов имеют также завершающие мероприятия, тоже ведущие к операционным расходам: доставка товара потребителям, завершение работы со средами, ретроспективы, обзоры, аудиты, обучение пользователей и т. д.
Операционные расходы есть и у итераций: планирование итераций и выбор элементов бэклога (или рассмотрение требований), вероятно, оценка, бюджетирование, привлечение ресурсов и настройка сред. В то же время возможны операционные расходы на интеграции, поставку, ретроспективы и завершение работы со средами.
Координационные расходы
Координация необходима, если два или более человек пытаются вместе достичь общей цели. Чтобы улучшить координацию между людьми, мы изобрели язык и коммуникативные системы. Когда мы хотим встретиться с друзьями, чтобы вместе выпить, перекусить и посмотреть кино, мы несем координационные расходы. Все электронные письма, СМС и звонки, которые необходимы для организации встречи, относятся к координационным расходам.
Итак, координационные расходы на проект – это любые действия, связанные с общением и планированием. Когда сотрудники команд проекта жалуются, что не могут заниматься работой, которая приносит ценность, – например, анализом, разработкой или тестированием, – поскольку вынуждены вести переписку, они выполняют ряд координационных задач. Чтение каждого письма и ответ на него – это координационная деятельность. Если они жалуются, что не могут заниматься работой, которая приносит ценность, – например, анализом, разработкой или тестированием, – поскольку постоянно находятся на встречах, то это тоже координационная деятельность.
Любая форма встречи – это координационное мероприятие, включая любимые agile-сообществом стендапы. Исключение составляют совещания, которые ставят задачей получение ценности для потребителя. Если три разработчика собираются у доски и моделируют проект кода, который собираются реализовать, то это не координационная деятельность, а деятельность по созданию ценности. Дело в том, что она порождает информацию, необходимую для реализации функциональности, значимой для клиента.
Рассмотрим разработку программного обеспечения и систем как процесс поступления информации. Он начинается с отсутствия данных, а наличие полной информации соответствует работающей программе, функциональность которой отвечает потребностям и целям клиента. Тогда любая информация, поступающая в интервале между начальной и конечной точками и продвигающая нас на пути к созданию работающей функциональности, считается добавляющей ценность.
Если члены команды собираются для получения информации, создающей ценность, – дизайна, теста, части анализа, участка кода, – то такая встреча относится не к координационным расходам, а к работе по созданию ценности.
Однако если члены команды собираются для обсуждения статуса, распределения заданий или планирования, что помогает скоординировать действия и рабочий поток, то такая встреча – это координационные расходы и она должна считаться влекущей потери. Поэтому необходимо искать способы сократить или исключить координационные встречи.
Таким образом, пятиминутный стендап лучше 15-минутного, если в результате достигается одинаковый уровень координации. То же самое можно сказать про 15– и 30-минутные стендапы.
Можно попытаться сократить координационную деятельность, найдя другие, более эффективные способы координации работ.
Один из вариантов – дать членам команды полномочия для самоорганизации. Административно-командный тип управления, при котором сотрудники встречаются для предварительного распределения заданий, ведет к потерям. Самоорганизация обычно сокращает координационные затраты на проект. Однако для успешной работы требуется информация. Методы, используемые в Канбане (например, визуальный контроль цепочки создания ценности и визуализация работы на досках с карточками, в электронных инструментах и отчетах), дают достаточно информации для координации, что облегчает самоорганизацию и снижает координационные расходы на проект. Использование классов обслуживания и их визуализация разноцветными карточками или треками на доске наряду с соответствующими наборами правил для каждого класса обслуживания позволяет команде самостоятельно планировать работы и автоматизировать расстановку приоритетов. Иногда это называется самоускорением (я связываю этот термин с Элияху Голдраттом и управлением буферами).
Чем больше информации доступно членам команды, тем больше полномочий можно предоставить команде и тем меньше потребуется координационной деятельности. Позвольте прозрачности работы, потока, процесса и правил по управлению рисками заменить координационные действия. Сокращайте потери, активнее используя прозрачность.
Как узнать, что та или иная деятельность влечет за собой расходы
Как выяснилось, многие затрудняются с определением деятельности, вызывающей потери. Например, некоторые сторонники agile-методов считают, что ежедневные стендапы создают ценность. Я не разделяю этого мнения. Не могу представить себе клиента, которого волнует вопрос, проводит ли команда совещания на ходу. Клиентам нужна функциональность, которая воплощает их цели, поставляется в срок и обладает высоким качеством. Им совершенно безразлично, нужны ли для этого команде ежедневные совещания на ходу.
