Комитет по изменениям, на котором принимают решения
Комитет по изменениям создается с понятной целью: есть очередь доработок, спорные приоритеты, ограничения по бюджету, зависимости от других команд, и нужен регулярный момент, когда все это можно быстро решить. Но на практике такая встреча со временем может превратиться в обычный статус. Аналитики рассказывают, что сделано, разработчики объясняют задержки, РП проходит по списку задач, а самые спорные вопросы в конце переносятся на следующую неделю.
В таких ситуациях проблема не в самом комитете, а в том, что на него приносят слишком много всего сразу. Если в одной встрече смешать статусы, обсуждение требований, технические детали, новые идеи и конфликт приоритетов, час пройдет незаметно, а решений почти не останется. Поэтому я считаю, что комитет должен быть встречей не про «что происходит на проекте», а про «что именно нужно решить сегодня».
Первый фильтр: есть ли вообще что решать
Если задача уже в разработке, срок известен, ответственный назначен и никто не спорит о приоритете, выносить ее на комитет незачем. Ее статус можно посмотреть в системе или включить в короткую сводку до встречи.
На комитет стоит приносить только то, где есть реальная развилка: выбрать один из вариантов, подтвердить увеличение бюджета, решить спор между подразделениями, перенести задачу из релиза, принять риск или подключить смежную команду. Полезный вопрос перед включением пункта в повестку звучит просто: «Что должно измениться после этого обсуждения?»
Если ответ - «все будут в курсе», вопрос лучше оставить за пределами комитета. Если ответ - «выберем вариант А или Б», «подтвердим новый срок», «решим, какая задача идет первой», значит пункт действительно нужен.
Повестка должна быть написана через решение
Формулировка «Интеграция с ERP» ничего не говорит участникам о том, зачем их позвали. Под такой темой можно обсуждать что угодно: состав данных, ошибки обмена, тестовый контур или бюджет. Намного полезнее сформулировать вопрос так: «Решить, выпускаем ли первую версию без интеграции, если ERP не готова к 15 октября».
То же самое с приоритетами. Вместо пункта «Бэклог изменений» лучше написать: «Выбрать, какую из двух задач берем в октябрьский релиз при доступных 80 часах команды». Чем точнее сформулирован вопрос, тем меньше шансов, что разговор уйдет в соседние темы.
Не нужно приносить на комитет сырую проблему
Фраза «есть проблема, давайте обсудим» почти всегда съедает время встречи, потому что участники сначала выясняют, что вообще произошло, потом вспоминают предысторию, потом задают вопросы, на которые никто не подготовил ответ. Если вопрос дошел до комитета, у него уже должен быть короткий контекст и хотя бы несколько вариантов.
Для того, чтобы лучше сформулировать вопрос к обсуждению, лучше заранее подготовиться по такому списку:
- Что произошло. Коротко, без длинной истории.
- Почему вопрос нельзя закрыть на рабочем уровне.
- Какие есть варианты. Лучше два-три реальных.
- Чем они отличаются. По сроку, трудоемкости, риску, влиянию на пользователей.
- Что рекомендует команда.
- Какое решение нужно получить.
Например, вместо «Нужно обсудить согласование договоров» можно написать так: для договоров свыше 5 млн рублей сейчас обязателен финансовый директор, но два филиала просят исключение. Вариант первый - добавить отдельное правило для этих филиалов, это 16 часов. Вариант второй - оставить единый маршрут и обрабатывать такие случаи вручную. Команда рекомендует первый вариант. От комитета нужно подтверждение, можно ли вводить отдельное правило.
После такой подготовки обсуждение уже начинается не с восстановления истории, а с выбора.
Как может выглядеть рабочая повестка
Повестку лучше держать короткой. Если туда попало пятнадцать вопросов, нормального обсуждения все равно не получится. Лучше выбрать несколько пунктов, которые действительно что-то блокируют.
1. Новые изменения
Что берем в проработку, что откладываем, что закрываем без разработки.2. Приоритеты
Какие задачи двигаем выше, если ресурсов на все одновременно не хватает.3. Изменение объема
Где появились новые требования или зависимости и нужна переоценка.4. Блокеры и эскалации
Только вопросы, которые команда не может решить сама.5. Сроки и релизы
Что переносим, что оставляем, где сознательно уменьшаем объем.
Обычные статусы по задачам в эту повестку можно вообще не включать. Если статус требует решения, он сам попадет в один из пунктов выше.
На встрече должен быть тот, кто реально может решить вопрос
Одна из самых раздражающих ситуаций - час обсуждать проблему, прийти к общему мнению и в конце услышать: «Хорошо, теперь надо спросить директора». Значит, состав встречи был собран неправильно.
Если обсуждается бюджет, нужен человек, который имеет право его подтвердить. Если меняется правило работы подразделения, нужен владелец этого процесса. Если спорят два направления, должен участвовать тот, кто может расставить между ними приоритеты. При этом совсем не обязательно постоянно держать на комитете большую группу людей. Основной состав может быть небольшим, а нужных участников лучше подключать под конкретные вопросы.
Начинать обсуждение лучше сразу с развилки
Долгая вводная обычно не помогает. Если карточка вопроса была разослана заранее, на встрече можно начать прямо: «Нам нужно решить, переносим интеграцию в следующий релиз или выпускаем первую версию без нее. Команда предлагает второй вариант, потому что ERP не подтверждает готовность API».
После этого обсуждаются аргументы, но у разговора уже есть границы. Когда участники уходят в технические подробности, полезно возвращаться к исходному вопросу: влияет ли эта деталь на выбор? Если нет, ее можно вынести в отдельную рабочую встречу.
Иногда правильный результат комитета - не решение, а конкретное действие
Бывает, что данных действительно недостаточно. Например, нельзя обещать срок интеграции, пока смежная команда не подтвердила свою часть работ. В такой ситуации не нужно заставлять участников выбирать вариант наугад только ради того, чтобы в протоколе появилось слово «решено».
Нормальный итог может звучать так: «До 8 октября архитектор ERP подтверждает возможность доработки API и срок. После этого вопрос возвращается на комитет». Это тоже результат, потому что понятно, чего именно не хватает, кто это выясняет и когда вопрос должен вернуться.
Эскалация нужна не потому, что задача долго висит
Словом «эскалация» часто называют почти любую сложность, которую не удалось решить за пару дней. Из-за этого в повестку попадают вопросы, которые команда вполне могла закрыть сама.
Я бы закрепила в регламенте несколько понятных причин для эскалации:
- два владельца процесса не могут договориться о правиле или приоритете;
- нужно выйти за согласованный бюджет или лимит трудоемкости;
- изменение влияет на подтвержденный срок релиза;
- нужна работа другой команды, но ее участие не подтверждено;
- нужно принять риск, который команда не уполномочена принимать сама;
- предлагается заметно изменить ранее согласованные границы работ.
Если аналитик просто ждет ответ пользователя или разработчику нужен совет архитектора, это еще не повод собирать комитет.
Шаблон эскалации можно уместить в несколько строк
Проблема: что именно сейчас блокирует работу.
Влияние: что произойдет, если ничего не решать.
Что уже проверили: какие варианты команда рассмотрела.
Варианты: из чего нужно выбрать.
Рекомендация: что предлагает команда.
Решение нужно до: дата, после которой меняются последствия.
Кто должен решить: конкретная роль или человек.
У такого шаблона есть полезный побочный эффект: иногда уже при его заполнении становится понятно, что вопрос не требует эскалации и его можно закрыть без руководителей.
У каждого пункта должен остаться понятный итог
Фраза «обсудили вопрос» для протокола бесполезна. После каждого пункта должно быть понятно, что произошло дальше: одобрено, отклонено, отложено или нужны дополнительные данные.
Если вопрос отложили, нужно записать почему. Если ждут информацию - кто ее готовит и к какой дате. Если вариант выбрали - лучше сохранить не только само решение, но и условия, при которых его приняли.
Например: «Выпускаем первую версию без автоматического обмена, потому что ERP не готова к сроку. Интеграцию переносим в следующий релиз. До запуска бизнесу нужно подготовить временный порядок ручной передачи данных». Через два месяца такая запись все еще будет понятна, а короткое «решено выпускать без интеграции» уже может вызвать вопросы.
Протокол не должен пересказывать всю встречу
Стенограмма почти никому не нужна. В протоколе достаточно оставить вопрос, решение, важные условия, ответственного и срок следующего действия. Если решение относится к конкретной задаче, его лучше сразу записать в той же системе, где эта задача ведется, а не хранить только в отдельном файле.
Вопрос: интеграция с ERP не готова к октябрьскому релизу.
Решение: первую версию выпускаем без автоматического обмена.
Условие: до запуска пользователям передают временный порядок ручной работы.
Ответственный: владелец процесса.
Срок: 12 октября.
Такую запись можно быстро прочитать даже человеку, который не присутствовал на встрече.
Старое решение не нужно пересматривать просто потому, что кто-то снова не согласен
Иначе одни и те же вопросы начинают возвращаться каждую неделю. Повторно выносить тему на комитет стоит тогда, когда появились новые вводные: изменилась оценка, обнаружилось ограничение, смежная команда отказалась от ранее подтвержденных сроков, появилось новое требование закона или поменялся бизнес-приоритет.
В самой повестке при этом полезно прямо написать, что изменилось с прошлого раза. Тогда участникам не приходится заново обсуждать всю историю.
Как понять, что комитет действительно работает
Чтобы оценить полезность встреч, нужно не просто подсчитать, сколько их было проведено за определенный период, а проверить несколько вещей: сколько вопросов закончилось конкретным решением, сколько тем возвращается без новых данных, сколько пунктов откладывается из-за отсутствия нужного человека и сколько времени съедают статусы, которые можно было прочитать заранее.
Если после встречи меняется очередь задач, появляются подтвержденные приоритеты, снимаются блокеры и команда понимает, что делать дальше, комитет выполняет свою функцию.
Если же через час у всех становится больше только комментариев, уточнений и новых встреч, значит формат нужно менять.
Комитет не должен заменять обычную работу проекта
Большая часть вопросов должна решаться без него: аналитик уточняет требования с бизнесом, разработчики разбирают технические детали, РП ведет сроки, владельцы задач отвечают на рабочие вопросы. Комитет нужен там, где команда дошла до границы своих полномочий и без решения бизнеса или руководителя дальше двигаться нельзя.
Поэтому сделать такой комитет полезнее можно довольно простым способом: убрать из него обычные статусы, приносить только подготовленные вопросы, заранее показывать варианты и последствия, приглашать людей с нужными полномочиями и после каждого обсуждения фиксировать конкретный итог. Тогда это уже не еженедельный отчет о жизни проекта, а место, где действительно принимают решения.