В этом выпуске Kanban Talks Алексей Пименов и Алекс Цыбульник разбирают ключевую, но часто неправильно понимаемую тему — точку принятия обязательств (commitment point) в Канбан-системе. Это не просто теоретическая концепция, а важный ориентир, который позволяет сделать менеджмент эффективнее. Разберёмся, что это такое, зачем она нужна и какие заблуждения мешают ей работать.
Коротко о участниках беседы
Алексей Пименов — опытный канбан-консультант, живущий в Москве. Из личного: считает трудоголизм своей вредной привычкой и мечтает сделать менеджмент вокруг более осознанным и результативным. Алекс Цыбульник — ведущий подкаста и также практикующий Kanban Coach.
Зачем нужна точка принятия обязательств?
Чтобы понять, где в Канбан-системе появляется точка принятия обязательств, нужно сначала представить себе весь процесс от запроса клиента до результата. Этот процесс называют end-to-end. Клиентская потребность проходит через весь сервис, и где-то в середине мы принимаем решение: «Да, это стоит делать». Вот эта точка и называется точкой принятия обязательств.
Что такое «сервис» в терминах Канбана? Это не только команда. Это люди, процессы, знания, техника, инфраструктура — всё, что вместе превращает запрос в результат. И у каждого сервиса есть ограниченная пропускная способность. Поэтому важно фильтровать, что попадает в реализацию.
Upstream и отсев
До точки обязательства запрос находится в зоне upstream там, где ещё не решено, стоит ли вообще этим заниматься. Здесь копятся знания: проводятся интервью, анализируются риски, оценивается экономика. После анализа запрос может попасть либо в реализацию, либо в «корзину».
Точка принятия обязательств это граница между «об этом думаем» и «это делаем». После неё элемент становится обязательным к реализации.
Частая ошибка: привязка к оргструктуре
Одна из самых распространённых ошибок — воспринимать точку обязательств как переход работы между подразделениями. Например: бизнес-аналитики придумали — передали разработчикам и вот она, точка. Нет, это не так.
На практике бизнес и разработка постоянно взаимодействуют до и после точки принятия. Инженеры участвуют в предварительной оценке, бизнес в поддержке реализации. Поэтому эта точка может находиться внутри одной команды или даже внутри совместной работы разных ролей, а не между ними.
Привязка к организационной структуре создаёт барьеры информационные стены между функциями. Вместо кросс-функционального взаимодействия появляется эффект «перекидывания мяча». Это замедляет процесс и создаёт ложное ощущение ответственности.
Бывает ли несколько точек обязательств?
Иногда — да. Например, сначала команда берёт задачу в работу, а позже берёт на себя обязательство закончить её к определённой дате. Это два разных вида обязательства. Поэтому в сложных средах (например, в разработке с высоким уровнем неопределённости) их может быть несколько. Главное — чётко понимать, что в каждом случае означает «обязуемся».
Почему термин так сложно понять
Алексей делится наблюдением: несмотря на многочисленные объяснения, люди часто трактуют точку принятия обязательств по-своему. Это как «точка, которую легко потерять и сложно объяснить».
Один из корней путаницы попытка отождествить точку с этапом процесса конкретной команды. Например, у тестировщиков есть своя точка, у разработчиков своя. Но в Канбане это всё — часть одного потока, и обязательство уже принято, если элемент передан дальше. Точка одна там, где было сказано: «Да, делаем».
Конфликт точек в общих сервисах
Ещё одна распространённая ситуация общие сервисы внутри компании, например, дизайнерская команда. Эти специалисты могут обслуживать и маркетинг, и разработку, и при этом участвовать в создании брендбука. В этом случае дизайнеры одновременно работают с уже принятыми задачами (например, баннер для лендинга) и с задачами, которые ещё проходят этап принятия решения (например, редизайн логотипа).
Если работа идёт по запросу маркетинга или разработки, она уже считается обязательной — отказаться от неё нельзя. Но если инициатива идёт от арт-директора и требует согласования, бюджетирования, творческой доработки она проходит собственный апстрим. Здесь и возникает точка принятия обязательств: решение, что задачу стоит делать, и в системе есть мощность на её реализацию.
Где здесь классы обслуживания
Важно помнить про классы обслуживания. Они определяют:
- Как задача попадает в систему (например, ускоренно — срочная работа пролетает через апстрим);
- Как к ней относятся внутри системы (приоритет, порядок выполнения).
Взаимодействие между сервисами, как в случае дизайнеров, можно выстраивать через отдельные классы обслуживания или резервирование мощности под такие задачи — и тогда они минуют общий апстрим, попадая сразу в буфер выполнения.
Ошибочная синхронизация с требованиями
Вторая частая проблема — привязка подготовки требований к точке принятия обязательств. Это ловушка. Точка принятия решения «делать или не делать» не должна зависеть от наличия готовых требований.
Примеры:
- Требования уже есть, но решение о реализации ещё не принято.
- Решение уже принято, но требований ещё нет их допишут позже.
Если мы начинаем синхронизировать эти два процесса, появляется артефакт под названием Definition of Ready (DoR), который превращается в бюрократическую преграду. Часто он становится требованием айтишников к бизнесу: «пока не опишете всё, мы работу не начнём». Это приводит к войне между командами, взаимным упрёкам и задержкам.
Решение — развязать процессы полностью. Kanban вообще-то на этом построен: разделённые каденции. Подготовка требований и принятие решений разные циклы. Не мешайте им жить своей жизнью. Иначе получится, как с походом в туалет и обедом: вместе вроде бы логично, но на практике неудобно.
Definition of Ready — не зло, если это договор между всеми участниками процесса, а не инструмент давления одной стороны на другую. Хороший DoR это способ понять, что этап завершён и можно двигаться дальше. Плохой это когда по нему отказываются брать задачу в работу.
Кто должен участвовать в принятии обязательств
Теперь о собрании, на котором решается, какие задачи пойдут в реализацию. Кто там должен быть?
Ошибочный паттерн: приходит бизнес, приходит команда, фасилитатор скраммастер. Бизнес хочет пропихнуть задачи, команда отбивается. Звучит знакомо? Это не тот формат.
Верный подход: собрание проводится между представителями бизнеса. Именно они бьются между собой за слоты в производственной системе. Представитель команды (например, сервис-доставки) приходит с одной миссией сказать, сколько есть мощности.
Если команда сидит на собрании и скучает, думая, что «лучше бы баги пофиксили», значит, вы неправильно построили процесс. Все обсуждения, аргументация, риски, сроки это часть апстрима. На собрание вы приносите уже подготовленные предложения. Оно нужно, чтобы решить: что и когда идёт в работу.
Если команда хочет участвовать в этом собрании, чтобы озвучить риски значит, риски не были собраны вовремя. Ваша апстрим-система не работает.
Как формулировать Definition of Ready
Напоследок о DoR. Его надо формулировать совместно. Это не инструмент давления со стороны айтишников. Это договор между всеми участниками процесса — как понять, что этап завершён и можно переходить к следующему. Если это общий язык и общее понимание это хорошо. Если это стенка — всё развалится.
Что такое точка принятия обязательств и где она бывает
Точка принятия обязательств это момент, когда работа перестаёт быть опциональной и становится обязательной. До неё идеи и запросы ещё конкурируют между собой, после — они уже должны быть реализованы.
Классическая ошибка думать, что она одна. На практике у нас могут быть десятки локальных решений, которые выглядят как обязательства, но по сути ими не являются. Часто она скрыта в черной дыре бэклога: заказчик думает, что работа уже началась, а команда считает её просто ещё одним пунктом в списке.
Организационные перекосы: на примере дизайнеров
В компаниях с общей сервисной функцией (например, дизайнеры работают и на маркетинг, и на разработку), возникает особая ситуация. Когда у дизайнеров нет собственной точки принятия обязательств, их работа становится «обязательной по умолчанию». Но если появляется их собственный поток — например, работа над брендбуком по инициативе арт-директора — тут уже нужна явная точка принятия обязательств, чтобы развести эти два потока по классам обслуживания и приоритетам.
Классы обслуживания и их роль
Класс обслуживания влияет:
- Как работа попадает в систему.
- Как с ней обращаются внутри системы.
Назначение класса должно происходить в апстриме. Если работа срочная (экспедит), она может миновать апстрим и сразу попасть в деливери. Это помогает избегать конфликтов между системами (например, разработка, маркетинг и дизайн), если мощность под конкретный класс обслуживания заранее зарезервирована.
Требования и точка обязательств — не одно и то же
Синхронизация между готовностью требований и точкой принятия обязательств — ловушка. Не стоит принимать решение «делать или нет» только потому, что «у нас уже есть требования».
Definition of Ready может быть полезным артефактом, если он создается совместно и описывает, что именно означает завершённость одного этапа работы. Но как способ отфутболить ответственность — это путь в войнушку между бизнесом и IT.
Кто и как принимает решение
Типичный паттерн на собрании по приёму работы сидит представитель бизнеса, команда и фасилитатор (часто скрам-мастер). Команда сопротивляется, бизнес давит. Правильнее: заказчики сами соревнуются между собой за слоты в системе, а команды просто сообщают, сколько слотов есть.
Команда не обязана «слушать всё» на таких встречах. Если у вас хочется озвучить риски это признак, что нет апстрима. Обсуждать надо раньше, на стадии накопления знаний.
Что делать с переполненными бэклогами
Бэклог в 800–2000 задач это уже не бэклог, а кладбище. Продуктовый трекер может помочь раскапывать это дело и формировать апстрим. Вместо приоритизации — отбор (select) на каждом этапе.
Слишком большой бэклог — сигнал, что у продакта нет понимания мощности команды или права отказаться от задач. Нужен upstream и процесс отбора, а не просто свалка.
Intangible work ≠ Intangible Class of Service
Нематериальная работа (например, апгрейд MS SQL) может быть срочной и важной. Если она лежит в бэклоге с экспедитным классом и не попадает в работу — это проблема. Возможно, владельцу продукта никто не объяснил, насколько она важна.
Кто должен искать точку принятия обязательств
Поиск происходит в рамках статика. Инициатор тот, кто этот статик проводит. Мы ищем, где работа перестаёт конкурировать и становится обязательной. Это водораздел между upstream и downstream. Например, в заказной разработке — это подписание контракта.
Что получает заказчик и исполнитель
- Заказчик: предсказуемость и SLA. Можно спросить: «Что ты хочешь, чтобы мы сделали за 35 дней?» и дать ответ.
- Исполнитель: понимание, где работа становится «обязательной». Особенно важно для менеджеров — это влияет на все процессы оптимизации: где держать узкие места, как управлять мощностью.
Финальные мысли
Точка принятия обязательств штука хитрая. Её нет в бэклоге, и она не там, где вы думали. Без неё Kanban-система превращается в кашу: непредсказуемость, фрустрация, споры.
Хочешь систему, которой можно доверять? Начни с того, что есть. И найди ту точку, где работа становится неизбежной. А потом подумай а точно ли ты хочешь, чтобы именно в этом месте она такой стала?
