Экономическая модель бережливого производства

 

Потери (или по‑японски м у да, дословно – мусор) – термин, применяемый в бережливом производстве (и производственной системе Toyota) для действий, в ходе которых не добавляется ценность для конечного продукта. Метафора «потери» оказалась сложной для принятия работниками интеллектуальной сферы. Часто трудно признать потерями такие задачи или действия, которые действительно влекут за собой накладные расходы, но при этом необходимы либо желательны для выполнения работы по созданию ценности; например, ежедневные стендапы нужны для координации большинства команд. Такие встречи сами по себе не прибавляют ценности конечному продукту, так что с технической точки зрения это «потери», но признать это многим практикам гибкой разработки сложно. Вместо того чтобы погружаться в ожесточенные споры о потерях, я решил найти другую подходящую парадигму и другой язык – вызывающий меньше эмоций и не вводящий в заблуждение.

 

Переосмысление «потерь»

 

Следуя за такими авторами, как Дональд Рейнертсен, я адаптировал понятия из сферы экономики и называю «ведущие к потерям» действия расходами. Расходы подразделяются на три основные абстрактные категории: операционные расходы, координационные расходы и «ошибочная» нагрузка (Failure Load). Категории показаны на рис. 18.1.

 

Рис. 18.1. Модель экономических расходов для бережливой разработки ПО

 

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

Эти расходы подробнее обсуждаются в следующих параграфах. Буду описывать их при помощи простого примера – покраски забора вокруг моего дома в Сиэтле.

 

Операционные расходы

 

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

 

 

Прежде чем начать работу, нужно было найти материалы. Для этого я поехал в магазин Home Depot. Кроме того, требовалось подготовиться: провести мелкий ремонт забора, его шлифовку, подрезку деревьев и кустов, чтобы можно было пройти к забору. Все эти действия не создают ценность. Заказчику неинтересно, что мне нужно ехать в Home Depot и это требует времени.

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

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

Могут понадобиться и другие действия: например, планирование, оценка и определение ожиданий. Клиенту может быть представлена стоимость работы и дата ее выполнения. (В данном случае будем считать, что клиент – моя жена.)

Когда дело наконец доходит до покраски, выясняется, что с 42 секциями забора (если считать обе стороны) невозможно управиться за один подход. Приблизительная скорость работы – четыре секции в час. Поэтому было решено разбить задачу на шесть этапов. Если бы речь шла о разработке ПО, мы бы назвали их итерациями или спринтами; в производстве это партии. Перед тем как начинать каждый этап покраски, также требовался ряд подготовительных мер. Надо было переодеться, доставить материалы: я переносил краску, кисти и другие инструменты из гаража к месту работы и только после этого начинал красить.

Итак, и проекты, и итерации предполагают подготовительные мероприятия.

Поработав пару часов, я обычно чувствовал потребность в перерыве. Допустим, наступало время обеда. Однако я не мог все бросить и начать есть. Сначала нужно было закрыть банку с краской, вымыть кисти либо бросить их в емкость с водой, чтобы они не засохли, пока меня нет. Потом требовалось привести себя в порядок – помыть руки и переодеться. И только после этого я отправлялся обедать.

По окончании проекта у меня может остаться немного морилки, а в Home Depot принимают обратно полные банки и возвращают за них деньги. Поэтому требуется еще одна поездка.

Итак, как итерации, так и проекты предполагают завершающие мероприятия.

С экономической точки зрения подготовительные и завершающие мероприятия – это операционные расходы. Каждое действие, создающее ценность, имеет связанные с ним операционные расходы. Клиент чаще всего их не видит, редко ценит и относится в лучшем случае со смешанными чувствами. Его можно заставить оплатить эти расходы, но он предпочел бы этого не делать. Наверняка вам приходилось приглашать мастера чинить стиральную или посудомоечную машину и платить за вызов 90 долларов. Это операционные расходы. Возможно, вы бы предпочли заплатить меньше или выбрали сантехника, который не берет плату за вызов? Операционные расходы не создают ценности. Они необходимы, но с точки зрения концепции бережливого управления считаются потерями.

Итак, два первых типа потерь – это операционные расходы: подготовительные (или начальные) и завершающие (или конечные).

Если вернуться к проблемам разработки ПО, то становится понятно, что у всех проектов есть свои подготовительные меры: планирование проекта, планирование ресурсов и набор персонала, бюджетирование, оценка, планирование рисков, планирование связи, приобретение необходимых мощностей и т. д. Большинство проектов имеют также завершающие мероприятия, тоже ведущие к операционным расходам: доставка товара потребителям, завершение работы со средами, ретроспективы, обзоры, аудиты, обучение пользователей и т. д.

Операционные расходы есть и у итераций: планирование итераций и выбор элементов бэклога (или рассмотрение требований), вероятно, оценка, бюджетирование, привлечение ресурсов и настройка сред. В то же время возможны операционные расходы на интеграции, поставку, ретроспективы и завершение работы со средами.

 

Координационные расходы

 

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

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

Любая форма встречи – это координационное мероприятие, включая любимые agile‑сообществом стендапы. Исключение составляют совещания, которые ставят задачей получение ценности для потребителя. Если три разработчика собираются у доски и моделируют проект кода, который собираются реализовать, то это не координационная деятельность, а деятельность по созданию ценности. Дело в том, что она порождает информацию, необходимую для реализации функциональности, значимой для клиента.

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

Если члены команды собираются для получения информации, создающей ценность, – дизайна, теста, части анализа, участка кода, – то такая встреча относится не к координационным расходам, а к работе по созданию ценности.

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

Таким образом, пятиминутный стендап лучше 15‑минутного, если в результате достигается одинаковый уровень координации. То же самое можно сказать про 15– и 30‑минутные стендапы.

Можно попытаться сократить координационную деятельность, найдя другие, более эффективные способы координации работ.

Один из вариантов – дать членам команды полномочия для самоорганизации. Административно‑командный тип управления, при котором сотрудники встречаются для предварительного распределения заданий, ведет к потерям. Самоорганизация обычно сокращает координационные затраты на проект. Однако для успешной работы требуется информация. Методы, используемые в Канбане (например, визуальный контроль цепочки создания ценности и визуализация работы на досках с карточками, в электронных инструментах и отчетах), дают достаточно информации для координации, что облегчает самоорганизацию и снижает координационные расходы на проект. Использование классов обслуживания и их визуализация разноцветными карточками или треками на доске наряду с соответствующими наборами правил для каждого класса обслуживания позволяет команде самостоятельно планировать работы и автоматизировать расстановку приоритетов. Иногда это называется самоускорением (я связываю этот термин с Элияху Голдраттом и управлением буферами).

Чем больше информации доступно членам команды, тем больше полномочий можно предоставить команде и тем меньше потребуется координационной деятельности. Позвольте прозрачности работы, потока, процесса и правил по управлению рисками заменить координационные действия. Сокращайте потери, активнее используя прозрачность.