Как узнать, что та или иная деятельность влечет за собой расходы

 

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

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

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

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

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

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

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

 

«Ошибочная» нагрузка

 

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

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

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

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

 

Выводы

 

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

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

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

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

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

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

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

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

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

 

 

Глава 19

Источники вариативности

 

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

Шухарт, Деминг и Джуран опубликовали множество работ по исследованию вариативности и ее использованию в качестве техники управления, а также как основания для программы усовершенствований. Кроме того, существует немало публикаций, рассказывающих о методе количественной оценки, известном как статистический контроль процессов (СКП) и ставшем основным средством изучения вариативности и борьбы с нею. Теперь СКП взят на вооружение и командами, использующими Канбан. Однако СКП и его применение считается более серьезной темой, к которой мы обратимся в одной из следующих книг. Здесь же только затронем проблему вариативности.

Шухарт разделял вариативность и вариации в производственных показателях на два типа – внутреннюю и внешнюю.

Внутренние источники вариативности – это вариации, которые находятся под контролем задействованной системы. В рамках Канбан‑подхода к IT и разработке ПО мы определяем систему как процесс, который задается набором правил, управляющих ее эксплуатацией. Эти правила могут подвергнуться влиянию изменений, вносимых сотрудниками, командой или руководством. Изменения в правилах трансформируют и эксплуатацию системы, и ее производительность. Тем самым изменения в определении процесса – это изменения, которые затрагивают внутренние источники вариативности. Забавно, что такие внутренние вариации Шухарт назвал случайными. Слово «случайный» предполагает, что вариации имеют непредсказуемый характер, что является прямым следствием структуры системы. Но не предполагается, что непредсказуемость равномерно распределена или укладывается в рамки нормального распределения. Изменения в структуре процесса, вызванные изменениями внутренних правил, повлияют на медианное распределение, его распространение и форму.

Приведем пример. Отбивающий в бейсболе обладает коэффициентом ударов (известным также как средний уровень), который показывает, как часто он наносил удары, приводившие как минимум к взятию первой базы. У разных отбивающих разные коэффициенты, обычно они колеблются от 0,1 до 0,35. В любой день такой игрок может продемонстрировать показатели ниже своего среднего коэффициента ударов. Это зависит от ряда факторов: выбора питчера[13], коэффициента успешности ударов других игроков, а также от специфики подач.

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

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

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

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