Теория ограничений — это метод управления, разработанный Элияху Голдратом в 1980-х годах. Для популяризации своих идей он написал несколько книг в формате бизнес-романов, где на реальных кейсах показал инструменты, которые помогают разложить любую проблему по полочкам и найти возможные пути решения. 

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

Формирование НЖЯ 

Первое с чего мы начали — формирование нежелательных явлений (НЖЯ). Это проблемы, которые мешают достичь лучшего результата. Рассмотрим на общих примерах, как правильно составить формулировку:

• НЖЯ должны описывать состояния, а не одноразовые случаи и действия.

⨉  Отдел продаж пропустил важный звонок в прошлую среду.

✓ Отдел продаж не отвечает на 30% звонков.

• НЖЯ не должно быть субъективным утверждением. Лучше использовать объективные численные показатели.

⨉  Много ошибок выкатывается на пользователей.

✓ В 30% релизов клиенты находили ошибки в течение первой недели.

• НЖЯ не должно содержать причинно-следственную связь (можно вычислить по маркерам «из-за» и «потому, что»).

⨉ Из-за того, что отдел продаж не советуется с производством, срываем сроки.

✓ В 20% заказов срываются сроки поставки.

• НЖЯ не должно быть завуалированным решением, иначе это будет единственным решением проблемы. 

⨉ У вас не хватает документации. 

✓ У 30% сервисов получение описания для регуляторных нужд занимает 2 месяца.

• НЖЯ не должно быть предполагаемой причиной, для начала нужно понять проблему.

⨉ Сотрудники недостаточно обучены.

✓ 40% консультаций сотрудниками первой линии поддержки не завершаются успешно. 

• НЖЯ не должны кого-либо обвинять — это ведёт к конфликтам. 

⨉ Тестировщики плохо проверяют функционал.

✓ В 30% релизах клиенты находили ошибки в течение первой недели.

• НЖЯ не должно требовать пояснения, негативный эффект должен быть очевиден.

⨉ 30% времени тратится на обслуживание станков.

✓ В 20% заказов срывается срок поставки.

• НЖЯ должно находиться в вашей области ответственности.

⨉ Акционеры не выделяют нам достаточно средств на развитие.

✓ Плановая нагрузка на сотрудников выше 100%.

• Относительно этого явления возможно что-то предпринять.

⨉ Регуляторные требования не дают нам запустить новый функционал.

✓ В 20% наших разработок мы поздно узнаём о блокирующих регуляторных требованиях.

Чтобы сформулировать наши НЖЯ, мы пообщались со всеми участниками команды. Это помогло увидеть проблему с разных сторон и составить общую картину. 

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

«Грозовые тучи» и корневой конфликт

«Грозовые тучи» — это метод визуализации, который помогает выявить противоречия, которые мешают эффективной работе. 

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

«Туча» помогла увидеть наш корневой конфликт: мы постоянно мечемся между стабильностью и продуктовой ценностью. В итоге пребываем в неудовлетворительном компромиссе, в котором страдает всё.

Итак, мы определили корневой конфликт. И, к удивлению, в нём нет ничего удивительного, нового и сложного — всё на поверхности. Но в этом и прелесть: большинство решений сложных проблем очевидны. И мы пошли их с помощью следующих мыслительных инструментов.

Формирование исходных посылок

Следующий этап работы — формирование исходных посылок. Мы задаём вопросы (как в схеме ниже), чтобы проверить полученные причинно-следственные связи.

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

Аналогичным образом можно проверить все полученные причинно-следственные связи: они отмечены в схеме чёрными стрелками и красной молнией.

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

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

Дерево текущей реальности

Дерево текущей реальности показывает, как наш корневой конфликт связан с НЖЯ. 

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

В основании дерева находится наш корневой конфликт — «грозовая туча», сверху — найденные НЖЯ, которые являются хроническими проблемами, вызванными постоянным пребыванием в этом конфликте. Ещё выше, как следствие постоянно повторяющихся проблем — низкие показатели деятельности компании. В конечном счёте, это помогает увидеть полную картину и найти ответ на вопрос: что нужно изменить, чтобы решить проблему?

Например, из нашего упрощённого дерева видно, что когда растёт техдолг, мы получаем сразу три неприятных последствия: 

• Сбои решаются долго и с большими потерями.

• Клиенты теряют доступ к нашим сервисам.

• Регулярно происходит отказ сразу нескольких независимых функций/сервисов. 

Но главное, теперь мы знаем причину: такое случается, когда команда больше работает над продуктовыми историями, чем над стабильностью и качеством сервисов.

Поиск решения

Всего у нас получилось порядка 20 решений в пяти категориях: 

• Наблюдаемые данные, метрики.

• Проверка гипотез и MVP.

• Командная работа (орг. изменения).

• Развитие компетенций.

• Изменение процессов.

Из них мы отобрали шесть, в которые верим больше всего. Первым выбрали внедрение SRE, в первую очередь — SLO-подхода для повышения наблюдаемости критичных клиентских путей. Он включает: 

• Sevice Level Objective (SLO) — цель, определяющая, каким должен быть показатель SLI, чтобы пользователи были удовлетворены сервисом.

• Sevice Level Indicator (SLI) — индикатор на базе метрики, который показывает уровень качества обслуживания.

• Error Budget Policy (EBP) — количество ошибок, которое можем допустить за определённый период времени без существенного негатива со стороны пользователей.

Благодаря этому в команде появились договорённости о том, на что в конкретный момент нужно тратить время — повышение надёжности (техдолг) или создание клиентской ценности (фичи). 

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

Конечно, мы думали о SRE ещё до теории ограничений, но только с ней окончательно убедились, что нам это надо. Ожидаемый эффект от внедрения SRE был довольно высок, но мы прекрасно понимали, что полностью устранить конфликт с помощью только этого нововведения не получится. Поэтому решили идти последовательно и внедрять идеи по одной. Возможно, в следующих статьях расскажем о других важных пунктах: например, ограничении количества незавершённой работы (WIP-лимитах) или о том, как правильно и вовремя трансформировать MVP-решения в работающие продукты.

Негативная ветвь

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

Для этого мы использовали такой инструмент, как негативная ветвь: 

1. Запишите негативные последствия, которые может принести ваше решение. 

2. Спросите себя: каким образом наше решение приведёт к негативным последствиям? Нам нужно расписать в подробностях эту логическую цепочку:

   1. На позвоночнике цепочки будут следствия решения.

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

В итоге у нас должна получиться полная логическая цепочка: как следствия и исходные посылки приводят к наступлению других следствий. 

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

4. Найдите решение, которое уберёт какую-то исходную посылку. Разумеется, лучше всего искать его перед первым негативным следствием, но не всегда получается ударить именно туда. Иногда выходит, что последствие такое плохое, что мы готовы потерять часть хорошего (отсекаем ветку ниже). Или решение настолько классное, что мы готовы потерпеть небольшой негатив (отсекаем ветку выше). 

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

Например, мы нашли, что первым негативным следствием для решения «Ввести SLI, SLO» будет то, что продакты их не поймут. Мы отсекли эту негативную ветвь с помощью инъекции — обучать продактов техническим метрикам и добавить стабильность одним из критериев оценки качества продукта. 

Наши выводы о мыслительных инструментах теории ограничений

Работа с теорией ограничений началась с простого внутреннего митапа тимлидов, где мы с ребятами обсуждали наболевшие вопросы. Но в конечном счёте это помогло нащупать решение для глобальной проблемы бизнеса. 

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

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

А вы слышали раньше про теорию ограничений? Какую проблему хотели бы разобрать?