На этой неделе у нас был, пожалуй, самый горячий sprint review за последнее время 🔥

И это было отлично😊 Разбирали одну вполне обычную задачу по новому тарифу. В какой-то момент обсуждение разогрелось, и стало понятно: проблема вообще не в этой конкретной задаче.

У нас просто сломалась цепочка до разработки. Где-то не добили бизнес-логику. Где-то не зафиксировали состояния. Тексты приехали сырыми. В каких-то местах вообще оказалось непонятно, кто отвечает за финальный смысл.

А тестирование получило всё это последним и внезапно должно было разобраться, что вообще считается правильным результатом****✖️

И тут команда оживилась 💬Тестирование говорит: «Я не могу это принять, потому что ожидаемый результат не определён». 💬Разработка говорит: «Не надо генерировать нам огромное ТЗ на 20 страниц. Скажите нормально, что должно получиться». 💬Дизайн говорит: «Я могу хорошо упаковать текст, но не могу придумать за продукт, что мы хотим сказать клиенту».

И в какой-то момент я понимаю: окей, это уже не проблема конкретной задачи. Это проблема процесса.

Мы очень любим считать узким горлышком разработку. Просто именно туда приезжают все долги, которые накопились раньше: продукт не договорился с маркетингом, не собран GTM, не готовы тексты, не продуманы состояния, не подключили вовремя юриста, нет критериев приёмки.

И разработка превращается в место, где все наши «потом разберёмся» наконец становятся проблемой.

По итогам решили не изобретать ещё один идеальный шаблон ТЗ. Нам нужен нормальный Definition of Ready перед разработкой: 🟢 что получит пользователь; 🟢 какие есть сценарии и состояния; 🟢 какие тексты он увидит; 🟢 какие тарифы, роли и ограничения затрагиваем; 🟢 подтверждена ли бизнес-логика; 🟢 нужен ли маркетинг / юрист / бухгалтерия; 🟢 готов ли дизайн; 🟢 как мы поймём, что задача сделана; 🟢 что точно НЕ делаем в рамках этой задачи.

Пока этого нет 😕 задача не Ready.

Для меня это был очень хороший sprint review. Да, местами горячий🙃 Но я гораздо больше не люблю встречи, где все вежливо говорят «в работе» и расходятся. Сильная продуктовая команда — это не команда, где нет конфликтов. Это команда, которая умеет вовремя сказать: «ребята, у нас здесь система не работает» — и начать её чинить.