Точка принятия обязательств в Канбан-системе. Конспект подкаста Kanban Talks
Конспект подкаста Kanban Talks с Алексеем Цыбульником и Алексеем Пименовым
У многих Канбан-практиков возникают сложности с пониманием термина «точка принятия обязательств». Непонятно, где ее искать, и кто это должен делать. В этой статье мы попробуем разложить все по полочкам.
Об авторе
Алексей Цыбульник — акредитованный Канбан-коуч Kanban University (KCP), автор и ведущий подкаста Kanban Talks. Нас просили дополнить аудио выпуски подкаста версией для чтения. Так что теперь прочитать основное содержание лучших выпусков Kanban Talks вы можете в блоге Кайтена. Если хотите прослушать полную версию — переходите по ссылкам в конце статьи.
Этот выпуск Kanban Talks посвящен важной составляющей рабочего процесса — точке принятия обязательств. Гость подкаста — Алексей Пименов, аккредитованный тренер Kanban University, первый российский специалист уровня Accredited Kanban Consultant, преподаватель, тренер и консультант по Kanban Method.
Давайте начнем.
Что такое точка принятия обязательств?
Сделаю шаг назад, чтобы обрисовать картинку, в которой эту точку надо разместить.
В Канбане есть замечательное слово «сервис». Многие называют сервисами команду, либо совокупность команд. Это не очень правильно. Сервис — это система из людей, их рабочих инструментов и технологического процесса, которая может удовлетворить потребность клиента.
Если рассматривать сервис с момента возникновения потребности у клиента до решения проблемы, то можно заметить, как трансформируется клиентский запрос по ходу работы.
Клиентских запросов обычно много, а возможности их реализовать обычно ограничены бюджетом компании или ещё чем-то. В такой ситуации приходится принимать решение, что взять в работу, а что нет.
И получается, что всю нашу end to end систему можно условно разделить на 3 части:
- Часть, в которой решение ещё не принято. Мы ещё не поняли, стоит это делать или нет.
- Часть, где мы приняли решение и уже делаем.
- Часть, где мы приняли решение не делать. Это мусорная корзина, куда попадают идеи, которые прошли определенный отсев.
Точка принятия обязательств — это как раз некоторая точка, где мы приняли решение, что это надо делать и у нашей производственной системы есть возможность это сейчас взять в работу. И оно поступает в работу.
Кем ставится точка принятия обязательств? Где она ставится? Как решают, что в этом месте должна быть точка принятия обязательств?
Канбан-метод начинается с принципа «начните с того, что есть сейчас». То есть мы не ставим точку принятия обязательств искусственно, а берём процесс, который у вас сформировался, и идём эту точку принятия обязательств искать.
Кто должен стать тем человеком, который начнёт искать точку принятия обязательств?
Вопрос о поиске точки принятия обязательств должен всплывать во время проведения S.T.A.T.I.K. Рекомендую книгу Майка Барроуза «Канбан Метод. Улучшение системы изнутри», в которой подробно описано, как проводить S.T.A.T.I.K. Человек, который инициировал S.T.A.T.I.K, будет тем, кто первый попытается найти эту точку.
Где искать точку принятия обязательств?
Нам надо найти, где работа из опциональной становится обязательной. В потоке до точки принятия обязательств работа конкурирует за то, чтобы быть сделанной. После прохождения точки принятия обязательств конкуренции нет. Подписание контракта в заказной разработке — это точка принятия обязательств. Отказаться от этого контракта вы не сможете.
Где находится точка принятия обязательств для Скрам-команды?
Если рассматривать «ванильный» Скрам, то, конечно, попадание в спринт.
В реальности точка принятия обязательств для скрам-команды находится где-то посередине бэклога.
Подпишитесь на наш канал в Telegram!
Там мы публикуем анонсы новых фич, как только они появляются в Кайтене.
ПодписатьсяКак точка принятия обязательств связана с организационной структурой компании?
Короткий ответ на этот вопрос — никак. И он часто может тяжело восприниматься людьми, особенно которые поработали с определёнными фреймворками.
Процесс прохождения точки принятия обязательств многие воспринимают как процесс передачи информации от одной группы к другой. Например, руководители передают что-то исполнителям.
На самом деле, точка принятия обязательств проходит где-то внутри деятельности команды, а не просто между командами, или командой и индивидом. Тут могут быть множество разных вариантов, поэтому лучше рассматривать принятие обязательств как отдельный процесс, не привязывая его к социальным группам в организационной структуре компании.
Почему это важно? Потому что у нас всегда есть пересечение социальных групп, и, если мы начнем их разделять точкой принятия обязательств, то могут возникнуть задержки в передаче информации, потери и искажения.
Может ли быть несколько точек принятия обязательств?
Когда решение «Делаем вот это» уже принято, то дальше оно не может быть принято еще раз. В этом нет смысла. Решение может быть отменено, если, например, появились новые данные. Но отмена решения ≠ новой точке принятия обязательств.
Но есть некоторые тонкости. Бывает, что мы принимаем разные обязательства. Например, в начале мы обязуемся начать работу над какой-то задачей. Потом, когда у нас появляется понимание рисков, мы обязуемся поставить эту работу к конкретному сроку. И это как раз может быть второй точкой принятия обязательств.
Разделение процесса принятия обязательств за начало работы над задачей и принятия обязательств по дедлайну — хорошая практика, если мы работаем в комплексной среде.
Какие есть проблемы с пониманием термина «точка принятия обязательств»?
Во-первых, это проблема социальных групп. Часто бывает так, что в процессе работы задействовано несколько команд, которые выполняют свой этап и передают задачу дальше. Почему-то люди полагают, что у каждой команды в этой цепочке есть своя точка принятия ответственности. Увы, но нет.
У какой-нибудь команды тестировщиков нет точки принятия обязательств. Всё, что идёт тестировщикам, это уже обязательная работа, от которой нельзя отказаться. Обязательства по выполнению этой работы то уже приняты, они в системе уже есть.
Во-вторых, проблема общих сервисов. Допустим, в компании есть отдел разработки, маркетинга и дизайна. Дизайнеры рисуют картинки для рекламных кампаний маркетологов и рисуют внешний вид сайта для разработчиков. В этом случае у дизайнеров нет точки принятия обязательств. Вся работа, которая идёт на этих дизайнеров обязательна к исполнению. Отказаться от неё нельзя.
Но бывает так, что эти дизайнеры имеют ещё и свой отдельный поток работы. Например, создают брендбук компании. И тогда у них возникает свой собственный апстрим, в котором артдиректор придумывает изменения брендбука организации, согласовывает их с менеджерами и передает задачу команде дизайнеров. Работа, которая идёт от артдиректора, она должна проходить точку принятия обязательства, а работа, которая идёт от команды маркетинга и разработки, это работа уже закоммиченная, в ней не будет точки принятия обязательств.
В-третьих, проблема привязки процесса подготовки решения с процессом принятия обязательств. Процесс подготовки требований не должен быть никаким образом синхронизирован с точкой принятия обязательств. Я считаю, что точка принятия обязательств должна быть отвязана от этого процесса.
Легко себе представить некоторую производственную систему, в которой по какому-то запросу уже есть готовые требования, но решение о том, надо это делать, либо нет ещё не приняли.
Можно представить другую ситуацию, когда некогда писать требования. Рынок требует, чтобы мы уже ввязались в эту работу и требования будут создаваться уже после точки принятия обязательств.
Если процесс принятия обязательств происходит через какое-то собрание, то как это собрание должно быть сформировано, кто его должен вести? И кто там должен участвовать?
По хорошему, на такое собрание приходят руководители и представитель от команд. Проводит собрание наименьший общий руководитель. Представитель от команд приходит на собрание, чтобы сообщить, сколько у него есть слотов и посмотреть, что ж там они там выберут такого.
Озвучивание рисков, сбор данных, оценка потребностей клиентов и т.д. должно происходить до этого собрания. На собрании на основании собранных данных принимают решение, стоит эту задачу делать или нет, и уточняют, когда возникнет слот, в который этот вопрос попадёт.
Что получает заказчик, когда есть чётко обозначенная точка принятия обязательств?
У него появляется понимание, когда примерно задача будет выполнена. Например, что вы это сделаете за 35 дней с 95% вероятностью.
Что получает исполнитель, когда есть чётко обозначенная точка принятия обязательств?
Чёткое понимание, где работа перестает быть опциональной.
Менеджерам знание, где находится точка принятия обязательств, даст очень много информации. В зависимости от того, где она находится, у него могут быть разные процессы оптимизации производственной системы.
А конкретному инженеру знание, где находится точка принятия обязательств, даст только некоторую осведомлённость, выгоды от этого знания он не получит.
Подведем итоги. Точка принятия обязательств — это некоторый момент времени, в котором мы принимаем решение, что задачу надо сделать, и у нашей системы есть возможность эту задачу взять в работу. После прохождения точки принятия обязательств отказаться от работы нельзя. У процесса может быть только одна точка принятия обязательств. Где конкретно она находится — надо искать, ее местоположение может быть разным в разных системах. Искать точку принятия обязательств начинают во время проведения S.T.A.T.I.K.
Послушать 5 эпизод подкаста Kanban Talks «Что такое точка принятия обязательств в нашей Канбан-системе»
Рекомендуемая литература
Барроуз Майк «Канбан Метод. Улучшение системы управления»
Интересные статьи
Ekaterina Svirepo
Max Frolov
Viacheslav Tsyrulnik
Прогрессивные компании уже управляют своими проектами в Kaiten. Присоединяйтесь к лучшим.
