- Ингредиент №1. Видение продукта – «бульон» командной ответственности
- Ингредиент №2. OKR снизу вверх – «рыба»
- Ингредиент №3. Покер-планирование – «картошка»
- Ингредиент №4. Фасилитация – «морковка»
- Ингредиент №5. Боли пользователей – «лук»
- Ингредиент №6. Разделение команды – «концентрат»
- Ингредиент №7. Погружение в продукт – «сливки» (самое ценное)
- Специи: обратная связь
- Лавровый лист
- Вода: доверие – основной ингредиент
- Результаты: что получилось на выходе
- Как не пересолить: важные предостережения
- Резюме для практиков
«Поднимите руки, кто играет в покер-планирование?» – с этого вопроса начал своё выступление Сергей Шаблонов.
Но разговор пошёл вовсе не о техниках оценки задач. За внешне безобидной ситуацией – тестировщики вдруг начали стабильно завышать оценки в покере – скрывалась глубинная проблема, знакомая любой продуктовой команде.
«В какой-то момент тестировщики стали давать двойное завышение. Первый спринт, второй – то же самое. Обоснования странные, неаргументированные. Мы начали спрашивать: "Ребята, что происходит?" Они говорят: "Нам постоянно по башке бьют за баги на проде, а мы крайние"».
Тогда Сергей и его команда задумались: команда целиком делает продукт, но почему-то отвечает только тестировщики за качество, продакт – за метрики, разработчики – за код? Эта разобщённость рождает буферы (завышенные сроки), конфликты, снижение мотивации.
Решение пришло неожиданное – сварить «суп командной ответственности». Вдохновляясь идеями экстремального программирования (коллективное владение кодом, предложенное Кентом Беком ещё в 90-х), команда решила расширить принцип «любой может исправить ошибку в чужом коде» на весь продукт.
«Я люблю метафоры, – признаётся Сергей. – Айтишники вообще их любят. У меня каждый доклад с метафорой. Здесь – кухня».
Ингредиент №1. Видение продукта – «бульон» командной ответственности
«Основной ингредиент, определяющий, какой будет суп. Грибы положите – будет грибной, рыбу – рыбный».
Команда решила, что стратегию продукта должна создавать вся команда, а не только продакт с бизнес-аналитиками. Сергей ставил задачу: «Вы должны собрать команду не наёмников, а визионеров. Когда человек создаёт видение будущего, он больше чувствует ответственность за результат».
Ребята стали соавторами продукта. А соавторство – это и есть командная ответственность.
Ингредиент №2. OKR снизу вверх – «рыба»
В компании использовали классические OKR. Но команда пошла против канона: развернула цели снизу, а не спустила сверху. Эксперты говорили, что это не классика, но для автономного продукта – почему бы нет?
«Слушайте, зашло просто. У меня был отдельный доклад на OKR-саммите. Ребята без мониторинга годовые цели выполнили. Совместное формирование целей формирует командную ответственность гораздо сильнее, чем спущенные сверху».
Сергей ссылается на фасилитатора Майкла Вилкинсона: «Много решений продуманы экспертами, но не включают в подготовку тех, на кого потом эти планы влияют. Именно поэтому стратегия, разработанная всей командой, более рабочая – в неё вложил каждый свою долю».
Ингредиент №3. Покер-планирование – «картошка»
В покер играют многие команды. Но здесь на эту технику посмотрели иначе: не просто как на способ оценки задач или геймификацию, а как на механизм командной ответственности.
«Когда вы играете в покер, человек выбрасывает карты и молчит – это просто механика. А если он говорит? Здесь важно услышать голос каждого».
Поэтому следующий компонент – фасилитация.
Ингредиент №4. Фасилитация – «морковка»
Сергей не профессиональный фасилитатор, но ведёт тренинги по фасилитации. В команде используют «освобождающие структуры» – 30 техник, из которых выбирают нужные: «Один-два-четыре-все», работа в парах, мозговые штурмы.
«Когда вы вовлекаете в решение людей, и чем больше вовлекли, тем больше возникает коллективная ответственность. Самое главное в фасилитации – умение слушать и задавать вопросы. В этом есть проблема, о которой я расскажу позже».
Ингредиент №5. Боли пользователей – «лук»
Продукт либо даёт возможность, либо решает боль. Боли доносят до всей команды не через сухие ТЗ и UML-диаграммы, а через сторителлинг.
«Я приношу в команду истории, которые слышу от пользователей: смотрите, там в регионе люди мучаются, и наш продукт решает эти проблемы. Команда сопереживает – это даёт вовлечённость».
Команда наладила связь с первой линией поддержки. Раньше она воспринималась как «коммутатор заявок», а теперь – как кладезь знаний о реальных болях пользователей. Ребята в мессенджерах обмениваются историями, заражая друг друга ответственностью.
Ингредиент №6. Разделение команды – «концентрат»
В команде было 14 человек. Сергей заметил: количество встреч не меняется, но чем больше людей, тем дольше они идут. Никому не нравятся долгие встречи, поэтому люди начинают молчать, чтобы она быстрее закончилась. А если человек не высказался – нет вовлечённости.
«Мы не слышим друг друга. Нет этого услышания голоса каждого», – решили в команде и провели сессию самодизайна.
Не директивно, а через голосование: «Нужно ли делиться? Когда?» Часть команды говорила: «Мы и так хорошо работаем, давайте после микросервисов». Другие: «Давайте завтра». Визуализация показала: надо делиться сейчас.
«Переспали один день, на следующий провели самодизайн. Команда сама распределилась на две, так чтобы в одной не было одних джунов, а в другой – одних сеньоров. Они даже названия придумали, настолько были вовлечены».
После этого на синках заговорил каждый член команды, а не только тимлид. Отмолчаться стало невозможно.
Ингредиент №7. Погружение в продукт – «сливки» (самое ценное)
Каждый новый член команды, независимо от роли (аналитик, тестировщик, джун), проходит часовое погружение: что за продукт, зачем мы его создаём, история, куда движемся, интересные факты.
«Просто кинуть документацию на "почитай" – это сухие буквы и цифры. А я стараюсь создать образ продукта».
Дальше – глубже. Команда начала приглашать по одному разработчику на глубинные интервью с пользователями. Просто послушать.
«Знаете, магия возникает. Разработчик за цифрами кода начинает видеть живых людей. Слышит их истории, проблемы. У него возникает желание помочь. А помощь людям – это ещё и профилактика выгорания».
Специи: обратная связь
Сергей различает формальные благодарности (письма, премии – их пишут секретари или ИИ, они обезличены) и неформальные.
«Самая классная история – когда директор убегает на совещание и на ходу говорит: "Слушай, кстати, продукт клёвый" – и побежал. Эта фраза стоит в десять раз больше официального письма на бланке».
Мало того, команда передаёт любую обратную связь. Даже негативную. Был случай: в выходные накатывали релиз с миграцией данных – сервис прервался. Тут же эскалация: «У вас там постоянно в самый ответственный момент вы выключаете систему!» Сергей подумал: «Несправедливо», – но всё равно передал эту обратную связь команде.
«Один разработчик говорит: "Так это же клёво! В субботу люди заметили, что система не работает – значит, она востребована. Хуже было бы, если бы никто не заметил"».
Главное – не пересолить. Если продукт переживает турбулентность, не стоит добивать команду негативом.
Лавровый лист
Каждый член команды за последние три года выступил в среднем 15 раз на разных площадках, рассказывая о продукте. Это и развивающая обратная связь, и гордость за своё детище. «Когда была регистрация в Роспатенте, ребята уже могут детям сказать, что фамилия папы на государственном сертификате».
Вода: доверие – основной ингредиент
«Если вы его не добавите, у вас низ подгорит, верх будет сырой. Это доверие».
Сергей провёл опрос в команде: «Что для тебя доверие?» Вот что получилось:
- Я могу смело сказать, что у меня есть идея, и мне не скажут: «Помолчи, у нас бэклог на 300 записей». Её выслушают, обсудят, примут, если она достойная.
- Если будет спор – я не буду упираться: «Я сеньор, а ты мидл, слушай сюда». Мы идём в консепт, а не в консенсус.
- Я могу сказать, что сделаю, и меня не будут троллить каждые полчаса: «Когда? Где?» – потому что знают, что я отвечаю за продукт.
- Если я скажу: «Слушай, у нас сроки», – я не подумаю, что ты стал тимлидом. Ты скажешь: «Спасибо, завис на Stack Overflow, забыл». Или попросишь помощи.
Результаты: что получилось на выходе
«Суп сварили. Теперь – результаты».
- Идей от команды стало в 3 раза больше. Сам Сергей генерирует столько же, сколько и раньше, но команда – в три раза активнее. Причём половина идей – бизнесовые, а не только технические. Марти Каган в книге «Вдохновлённые» (must-read для любого продакта) писал: разработчики, которые только пишут код, используются наполовину. Они классные генераторы бизнесовых идей.
- Скорость повысилась в 1,5 раза. Исчезли буферные зоны – никто не закладывает лишнее время, потому что нет «крайних», есть общая ответственность.
- Конфликтов – ноль. Точнее, есть конструктивные споры ради поиска лучшего решения, но выяснений отношений не стало.
«Dops-инженер однажды говорит мне: "Я не буду это делать, это вообще мой продукт?" Я удивился: "Ты что, акции компании купил?" Он говорит: "Нет, я потратил на это столько сил и времени. Это мой продукт"».
Человек перевёл продукт в собственность. Это, наверное, высший уровень командной ответственности.
Как не пересолить: важные предостережения
- Универсального рецепта не существует. «Мы в Финляндии попробовали суп, вернулись домой, начали варить сами – вкус другой. Вода другая, рыба другая. Так и с командной ответственностью: даже если вы повторите все ингредиенты, у вас будет свой вкус».
- Учитывайте зрелость команды. Если команда на начальном этапе модели Такмана (forming-storming), возможно, нужна директивность и чёткое распределение ролей. Когда перейдёт к самоорганизации – можно внедрять эти практики.
- Не забывайте про A-players. Это лидеры, которым не нужно говорить «где? когда?». Вы начинаете заниматься раздолбаями – это контр-интуитивно. Надо наоборот: заниматься лидерами, чтобы они стали центром притяжения и привлекали других.
- Доверие нельзя подделать. Если вы на словах «за Agile», а при первом инциденте становитесь директивным руководителем – всё развалится. «Истинное лицо вылезет сразу».
Ответы на вопросы: как быть с приоритизацией и конфликтом идей
Из зала спросили: «У вас есть методика приоритизации (RICE). Вы формируете роадмап вместе с командой. Не конфликтует ли это? Ведь идеи команды могут быть классными, но при приоритизации они уступают другим задачам».
Сергей ответил: «RICE – да, используем. Но роадмап и бэклог – разные вещи. Роадмап – верхнеуровневое видение. Разработчики, когда погружаются в него, начинают предлагать архитектурные изменения заранее – это плюс. А бэклог приоритизируем по RICE, где оценка effort – от команды. Конфликты бывают, но они конструктивные. Фронтенд-разработчик может ругаться с дизайнером не потому, что фреймворк не позволяет, а потому что он считает решение неудобным для пользователя. Они спорят, я как продакт могу "продавить", но стараюсь этого не делать. Если я начну давить с позиции силы – команда перестанет генерировать идеи, вернётся в режим "чего изволите", и качество продукта упадёт».
Другой вопрос: «Когда ваша идея и идея команды попадают в бэклог, как вы решаете, чью брать?»
«Мы обсуждаем на равных. У меня есть функция функционального руководителя (это вообще антипаттерн по Марти Кагану, но так исторически сложилось), но я этим не пользуюсь. Идеи от меня, от команды, от стейкхолдеров – все рассматриваются через одну методику приоритизации. Если я вижу, что моя идея слабее – я уступаю. Доверие – это когда ты готов сказать: "Ты прав, давай делать по-твоему"».
Выступление Сергея Шаблонова – это не теория, а живой рецепт, проверенный на команде из 14 разработчиков (впоследствии – две команды по 7 человек), работающей над внутренним продуктом с 20 000 пользователей.
Главные ингредиенты командной ответственности:
- Совместное создание стратегии (видение продукта).
- Формирование целей снизу (OKR).
- Покер-планирование как способ услышать голос каждого.
- Фасилитация и техники вовлечения.
- Доставка болей пользователей до команды через сторителлинг.
- Разделение большой команды на малые (до 7–8 человек).
- Погружение каждого нового члена в продукт и участие в глубинных интервью.
- Искренняя (неформальная) обратная связь, включая негативную.
- Публичное представление продукта (выступления, патенты).
- Доверие – вода, без которой суп не сварится.
«Я думаю, что если вы попробуете сварить свой суп, он будет у вас точно вкусный. Не бойтесь экспериментировать», – завершил Сергей.
Резюме для практиков
- Командная ответственность ≠ коллективная безответственность. Это когда каждый чувствует себя владельцем продукта, а не исполнителем.
- Начинайте с доверия. Без него любые техники будут имитацией.
- Маленькие команды эффективнее больших. 14 человек – предел, после которого теряется голос каждого.
- Дайте команде участвовать в стратегии и целях. Люди больше вовлекаются в то, что создавали сами.
- Используйте неформальную обратную связь. Искреннее «продукт клёвый» от директора стоит больше официальной благодарности.
- Не пересаливайте. Учитывайте зрелость команды и текущую ситуацию.
Статья подготовлена по материалам выступления на форуме «Управление продуктом 2026». Полная видеозапись и презентация доступны в архиве форума.
#productmanagment #управлениепродуктом #pm #event #конференции #интерфорум #interforum #interforums
76 дней
На фоне стремительного развития технологий и смены поколенческих ценностей корпоративное обучение переживает тектонические сдвиги. Внедрение ИИ, работа…
84 дня
На Форуме «Экономическая безопасность бизнеса 2026» будут детально разобраны наиболее острые проблемы, с которыми сталкиваются специалисты в текущих…
