Личный опыт лидера команды по переходу от формального "зачитывания требований" к совместному созданию понимания. Простые шаги, которые помогли нам победить "иллюзию понятных задач" и в разы сократить количество срочных доработок в середине спринта.
Прошел год с тех пор, как наша команда Sugar CRM совершила прыжок из уютного водопада в бурные воды Agile. Мы пережили мучительные получасовые, а иногда и часовые дейлики вместо 15-минутных, прошли через «гадание на кофейной гуще» на планировании спринтов и вроде бы обжились.
Но одна проблема упорно не сдавалась, грозя похоронить все наши agile-начинания. Мы вроде делали всё по книжке: проводили Product Backlog Refinement (PBR), оценивали задачи в Story Point (SP), обсуждали задачи, писали чек-листы и выходили с встреч с чувством выполненного долга.
А потом начинался спринт. И всё шло под откос.
Диагноз: «Иллюзия понимания»
Симптомы были до боли знакомы любой команде:
Лекция вместо диалога: аналитик делится экраном с Confluence, где лежит подробнейшая «портянка» требований, и в течение получаса… пересказывает её нам голосом.
Кивание вместо вовлечения: команда кивает, задаёт 1-2 формальных вопроса для очистки совести. Все расходятся с ощущением "всё понятно".
«Пожар» на тестировании: через несколько дней выясняется, что забыли обсудить какой-нибудь кейс. Разработчик понял логику иначе, чем задумал аналитик. Аналитик тычет в документацию. Тестировщик находит «баг», который на поверке оказывается просто неоговорённым требованием.
Результат? Пожарный режим. Срочные созвоны, переделки, переносы. Задача на полдня растягивалась на два дня. На ретроспективах звучала одна и та же фраза аналитика: «Реализация идёт не по документации!» или «Почему разработчик принял решение делать по-другому!».
А ведь документ — наш ключевой артефакт для сопровождения и интеграций, в том числе для смежных команд.
Возникал порочный круг: мы тратили часы на создание документа, потом на его "озвучивание", а в итоге всё равно работали по устным договорённостям, которые все благополучно забывали.
Моё прозрение пришло вместе с простым вопросом к себе: «Амина, если на встрече говорит один человек, то чьё понимание мы уточняем?
Где сбой? Я точно знала, не в людях, а в процессе. Уж очень я верю в людей.
Как бережно изменить этот театр одного актёра? Без революций и обвинений. Мягко.
Как вовлечь всю команду (разработчиков, тестировщика, аналитика, тех лида) для создание единой картины?
И главное: как наконец достичь предсказуемости и перестать срывать спринты?
Ответ, как это часто бывает, оказался на поверхности. Нам нужно было перевернуть сам принцип встречи: превратить PBR из монолога в диалог, из лекции — в интерактивный воркшоп.
Три кита, на которых мы построили новый PBR
Когда стало ясно, что менять нужно процесс, я решила отказаться от формата «список правил». Вместо этого мы с командой договорились построить три новых принципа — как три кита, на которых теперь держится наше взаимопонимание.
Кит 1. Дисциплина подготовки или «Прочитать ДО, а не ПОСЛЕ»
Что было?
Раньше ссылка на задачу летела в чат за пять минут до PBR.
Все заходили в телемост с одним вопросом: «Ну, о чём там?».
Это был билет в один конец. Туда, где будет «Галя у нас отмена, фичи в проде не быть».
Что мы сделали?
Мы ввели простое, но железное правило — PBR начинается за два рабочих дня до самой встречи. Теперь аналитик не «сбрасывает ссылку на документ в Confluence», а формирует «информационный пакет» и чёткую повестку.
А разработчик и тестировщик обязаны прийти с вопросами и быть подготовленными.
Наши грабли и лайфхаки
Первые недели правило саботировали. В чате звучало: «Некогда читать», «Сначала послушаю аналитика», «Такими отвлечениями я не успею дотестировать фичу». Надо было менять не поведение, а понимание ценности.
Я собрала команду и объяснила нашу цель на языке, который все понимали — на языке времени, как капитала.
«Ребята, это как инвестиции. Сейчас тяжело отложить час на чтение задачи. Кажется, ты его теряешь. Но если ты этого не сделаешь, через три дня ты обязательно потратишь три часа на переделку, авральные созвоны и нервотрёпку из-за недопонимания. Это плохая инвестиция с отрицательной доходностью.
А если ты «вложишь» этот час сейчас — ты покупаешь себе спокойствие и предсказуемость на всю следующую неделю. Ты накапливаешь капитал свободного времени в буд��щем. И тогда ты сможешь смело “курить бамбук”, зная, что задача идёт точно по рельсам».
Мы не стали вводить санкции. Мы просто начали делать это инвестиционное преимущество видимым. Контраст с авралами прошлого стал лучшим аргументом. Постепенно внутренняя мотивация — желание работать спокойно и эффективно — перевесила инерцию. Подготовка перестала быть «правилом», а стала осознанным выбором профессионалов, экономящих свой самый ценный ресурс.
Кит 2. Воркшоп вместо собрания: роли, камеры и живая история
Что было?
Один говорит, остальные в телефонах или усердно пытаются понять, очевидно, нужно больше времени. Выключенные камеры, вздохи, тишина в ответ на вопрос «Всем всё понятно?». Думаю, многим это знакомо.
Что мы сделали?
Мы буквально расписали роли и сценарии каждого участника, как в пьесе:
Докладчик (Аналитик/DPO): его задача — не читать текст, а рассказать историю: «У нашего клиента Марии сейчас проблема… Вот как мы хотим её решить…».
Модератор (часто я): следит за таймингом и вытаскивает мнение молчунов. Фраза «Ильгиз, а как ты с точки зрения архитектуры на это смотришь?» стала нашей мантрой.
Участники: их работа — быть скептиками и соавторами.
Самый спорный пункт — камеры. Я объяснила это не контролем, а психологией внимания: когда видишь лицо человека, ты невольно вовлекаешься в диалог. Справились просто: начали встречу с личного неформального вопроса каждому («Как выходные?», «Че у тебя там на фоне», «Какой милый кот!», «Успел нарядить елку»). Через неделю это стало естественным ритуалом.
И самое основное: мы фиксируем «артефакты» так сказать. Последние 15 минут встречи — пишем критерии приемки или что пользователь должен увидеть на выходе. ВМЕСТЕ в реальном времени. Я шарила экран с Jira, и мы формулировали их тут же. Это магия: когда ты сам участвуешь в создании критерия, ты уже не сможешь сказать «я не так понял».
Кит 3. Тестировщик — не молчун, а главный «адвокат дьявола»
Что было?
Тестировщик терпеливо слушал, уходил, а через три дня приносил лист «багов», половина из которых — просто неоговорённые требования. Это была тихая война.
Что мы сделали?
Мы "легализовали" критический анализ. Теперь одна из ключевых ролей тестировщика на PBR — задавать неудобные вопросы «А что, если…?» ещё до написания первой строчки кода.
«А что, если пользователь нажмёт отмену на третьем шаге?»
«А если в этом поле будет не число, а спецсимвол?»
«Мы учитываем, что этот сервис может ответить с задержкой?»
Эффект: его чек-лист рождается прямо на глазах у команды. Он делится экраном, мы все смотрим, дополняем и — что главное — сразу принимаем решение, как система должна себя вести.
Это убирает 80% последующих споров на ретро.
И главное: что стало с видео записями встреч? Ах, да мы же раньше записывали наши PBR.
Мы перестали их делать. Раньше мы надеялись, что запись спасёт, но она лишь поощряла пассивность: «Пропустил момент? Послушаешь потом». В новом формате, где каждый — активный участник, а итог фиксируется онлайн (критерии в Jira, чек-лист в Confluence), необходимость в многочасовом конспекте отпала сама собой. Запись осталась только как справочный материал для отсутствующих, но таких почти не осталось — ценность живого участия стала очевидна всем.
Она, возможно, актуальна новичку, если считает для себя полезным переслушать на замедленном 😊
И как итог: мы не внедрили правила сверху. Мы вместе построили новый ритуал, где у каждого есть роль, право голоса и — что важно — ответственность за общий результат. Это был переход от культуры тихого согласия к культуре активного сотворчества.
Заключение: какие плоды мы пожинаем спустя квартал
Мы работаем в новом формате около 4 месяцев. Это эксперимент, который стал нашей новой реальностью.
Главный результат: метрика предсказуемости спринта (Sprint Predictability) выросла и стабильно держится на уровне 85%. Был спринт, где мы достигли 91.3%. Конечно, это заслуга не только PBR, а совокупности многих факторов. Но именно он стал тем самым ключевым изменением, который перекрыл поток "сюрпризов" в середине спринта.
Стало намного приятнее планировать: "пацан сказал — пацан сделал". Последние три спринта мы забираем ровно столько, сколько можем сделать, и — делаем.
Ну что, друзья, надеюсь статья была для вас полезной. Делитесь в комментариях своими методами и принципами! С какими похожими проблемами сталкивались и как их решали? Очень ценно обмениваться живым опытом.
Для меня будет огромной радостью, если опыт моей команды поможет кому-то перестать "тушить пожары" и начать стабильно достигать поставленных целей.
