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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так как определить приводящие к потерям операционные или координационные расходы?

Думаю, нужно спросить себя: «Если эта деятельность действительно создает ценность, то стоит ли тратить на нее больше времени?»

Спросите защитников Scrum, которые абсолютно убеждены, что стендапы создают ценность, не пора ли проводить их два раза в день или увеличить длительность с 15 минут до получаса. Наверняка все они ответят отрицательно. Я возражаю им: «Но ведь если стендапы действительно создают ценность, то увеличение времени должно пойти на пользу!»

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

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

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

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

Множество звонков в службу поддержки приводит, как правило, к большому количеству задач по исправлению дефектов промышленной среды. При выборе функций, которые должны быть реализованы в проекте или итерации, руководство должно выбирать между новыми идеями и дефектами. Последние – это не только программные ошибки. К ним относятся удобство использования и другие нефункциональные проблемы, такие как плохая производительность, задержки при высокой нагрузке или в определенных сетевых условиях и т. д. Исправление дефекта промышленной среды по нефункциональным требованиям может выглядеть как новая функциональность (например, дизайна нового экрана), но это не так. Речь идет об «ошибочной» нагрузке. Дизайн нового экрана появился из-за того, что в прошлом релизе возникли проблемы с удобством эксплуатации.

«Ошибочная» нагрузка не создает новой ценности, а восполняет ту, которая осталась нереализованной после прошлого релиза. Вероятно, предыдущий релиз продукта или сервиса не справился с запланированной функцией. Хотя это бывает связано и с вариативностью или непредсказуемостью рынка, отчасти этот дефицит функционала возник из-за проблем предыдущих релизов. Ошибка в продукте не дает пользоваться какой-либо функциональностью, поэтому потенциальный потребитель либо не приобретает его, либо выбирает конкурирующий.

Итак, нарисовалась неясная картина. «Ошибочная» нагрузка все равно создает ценность. Но важно понять, что ценность к этому моменту уже должна быть создана. Снижение «ошибочной» нагрузки уменьшает возможные расходы из-за отсрочек. Сокращенные расходы означают, что прибыль начнет поступать раньше. Снижение «ошибочной» нагрузки значит, что можно обратить всю доступную мощность на новую функциональность, позволяет бизнесу работать в нескольких нишах рынка и предлагать больше продуктов, порождает больше возможностей и может сократить состав команды, что приведет к уменьшению прямых расходов.

• Потери можно разбить на три основные абстрактные категории: операционные расходы, координационные расходы и «ошибочная» нагрузка.

• Концепция «потерь» является метафорой.

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

• Чтобы определить, действительно ли данный вид деятельности влечет потери, спросите себя: «Стали бы мы при возможности отводить на него больше времени?» Если ответ отрицательный, то такая деятельность является той или иной формой потерь.

• Операционные расходы подразделяются на два типа: подготовительная деятельность и завершающая, или релизная, деятельность.

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

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

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

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