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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вариативность в промышленных процессах изучается с начала 1920-х годов. Пионером в этой области был Уолтер Шухарт. Его методы заложили основу движения по управлению качеством и стали базой как для производственной системы Toyota, так и для метода «шесть сигм», обеспечивающих качество и непрерывное совершенствование. Методы Шухарта были взяты на вооружение, развиты и дополнены Эдвардсом Демингом, Джозефом Джураном и Дэвидом Чемберсом. Их работы вдохновили Уоттса Хамфри и основателей Института технологий разработки ПО Университета Карнеги – Меллон, которые считали, что изучение и систематическое снижение вариативности сулит большие преимущества для разработчиков.