На этой неделе у нас был, пожалуй, самый горячий sprint review за последнее время 🔥
И это было отлично😊
Разбирали одну вполне обычную задачу по новому тарифу. В какой-то момент обсуждение разогрелось, и стало понятно: проблема вообще не в этой конкретной задаче.
У нас просто сломалась цепочка до разработки.
Где-то не добили бизнес-логику. Где-то не зафиксировали состояния. Тексты приехали сырыми. В каких-то местах вообще оказалось непонятно, кто отвечает за финальный смысл.
А тестирование получило всё это последним и внезапно должно было разобраться, что вообще считается правильным результатом✖️
И тут команда оживилась
💬Тестирование говорит: «Я не могу это принять, потому что ожидаемый результат не определён».
💬Разработка говорит: «Не надо генерировать нам огромное ТЗ на 20 страниц. Скажите нормально, что должно получиться».
💬Дизайн говорит: «Я могу хорошо упаковать текст, но не могу придумать за продукт, что мы хотим сказать клиенту».
И в какой-то момент я понимаю: окей, это уже не проблема конкретной задачи. Это проблема процесса.
Мы очень любим считать узким горлышком разработку.
Просто именно туда приезжают все долги, которые накопились раньше: продукт не договорился с маркетингом, не собран GTM, не готовы тексты, не продуманы состояния, не подключили вовремя юриста, нет критериев приёмки.
И разработка превращается в место, где все наши «потом разберёмся» наконец становятся проблемой.
По итогам решили не изобретать ещё один идеальный шаблон ТЗ.
Нам нужен нормальный Definition of Ready перед разработкой:
🟢 что получит пользователь;
🟢 какие есть сценарии и состояния;
🟢 какие тексты он увидит;
🟢 какие тарифы, роли и ограничения затрагиваем;
🟢 подтверждена ли бизнес-логика;
🟢 нужен ли маркетинг / юрист / бухгалтерия;
🟢 готов ли дизайн;
🟢 как мы поймём, что задача сделана;
🟢 что точно НЕ делаем в рамках этой задачи.
Пока этого нет 😕 задача не Ready.
Для меня это был очень хороший sprint review.
Да, местами горячий🙃
Но я гораздо больше не люблю встречи, где все вежливо говорят «в работе» и расходятся.
Сильная продуктовая команда — это не команда, где нет конфликтов.
Это команда, которая умеет вовремя сказать: «ребята, у нас здесь система не работает» — и начать её чинить.
И это было отлично😊
Разбирали одну вполне обычную задачу по новому тарифу. В какой-то момент обсуждение разогрелось, и стало понятно: проблема вообще не в этой конкретной задаче.
У нас просто сломалась цепочка до разработки.
Где-то не добили бизнес-логику. Где-то не зафиксировали состояния. Тексты приехали сырыми. В каких-то местах вообще оказалось непонятно, кто отвечает за финальный смысл.
А тестирование получило всё это последним и внезапно должно было разобраться, что вообще считается правильным результатом✖️
И тут команда оживилась
💬Тестирование говорит: «Я не могу это принять, потому что ожидаемый результат не определён».
💬Разработка говорит: «Не надо генерировать нам огромное ТЗ на 20 страниц. Скажите нормально, что должно получиться».
💬Дизайн говорит: «Я могу хорошо упаковать текст, но не могу придумать за продукт, что мы хотим сказать клиенту».
И в какой-то момент я понимаю: окей, это уже не проблема конкретной задачи. Это проблема процесса.
Мы очень любим считать узким горлышком разработку.
Просто именно туда приезжают все долги, которые накопились раньше: продукт не договорился с маркетингом, не собран GTM, не готовы тексты, не продуманы состояния, не подключили вовремя юриста, нет критериев приёмки.
И разработка превращается в место, где все наши «потом разберёмся» наконец становятся проблемой.
По итогам решили не изобретать ещё один идеальный шаблон ТЗ.
Нам нужен нормальный Definition of Ready перед разработкой:
🟢 что получит пользователь;
🟢 какие есть сценарии и состояния;
🟢 какие тексты он увидит;
🟢 какие тарифы, роли и ограничения затрагиваем;
🟢 подтверждена ли бизнес-логика;
🟢 нужен ли маркетинг / юрист / бухгалтерия;
🟢 готов ли дизайн;
🟢 как мы поймём, что задача сделана;
🟢 что точно НЕ делаем в рамках этой задачи.
Пока этого нет 😕 задача не Ready.
Для меня это был очень хороший sprint review.
Да, местами горячий🙃
Но я гораздо больше не люблю встречи, где все вежливо говорят «в работе» и расходятся.
Сильная продуктовая команда — это не команда, где нет конфликтов.
Это команда, которая умеет вовремя сказать: «ребята, у нас здесь система не работает» — и начать её чинить.