Блог

Что такое Discovery и зачем он нужен?

2025-05-17 06:31
Алекс Цыбульник (Kanban Coach) и Егор Ткачёв (Agile Coach, эксперт по OKR и масштабированию Agile Policy) поговорили о Discovery — этапе в разработке, про который все слышали, но далеко не все понимают, как он работает и зачем нужен.

Что такое Discovery и почему он важен

«Время от идеи до результата — это time to market. Всё, что до попадания задачи в бэклог, — это Discovery. А то, что после — это Delivery», — Егор Ткачёв.
Если упростить:
  • Discovery — этап исследования. Что именно мы хотим сделать, зачем, как и для кого.
  • Delivery — этап реализации: разработка, тестирование, выкладка ценности клиенту.

Почему это важно

Разработка — самый дорогой этап. Хорошие разработчики стоят дорого, и компания хочет выжать из их времени максимум пользы. Но если в разработку пускать всё подряд, потом оглядываешься — и оказывается, что половина сделанного никому не нужна. Бюджеты потрачены, люди выгорели, пользы — ноль.
Discovery помогает экономить: отсечь ненужное, уточнить задачи, не переделывать. Это особенно актуально не только в IT, но и в любой сфере — от маркетинга до строительства.
Пример из жизни: дом без подвала
Представьте, вы строите дом:
  • Сказали строителям: «Хочу четыре этажа» — и они начали строить.
  • В середине процесса вспомнили: «А подвал бы не помешал».
  • Чтобы добавить подвал после фундамента — нужно ломать, переделывать, тратить деньги и время.
Вот зачем нужен Discovery: чтобы заранее выяснить всё, что важно. Лучше на этапе планирования потратить время на уточнение, чем потом исправлять.

Где начинается Discovery и как его выстраивать

Когда Егор приходит в команду, он первым делом смотрит на бэклог:
  • Насколько он чистый и структурированный?
  • Есть ли оценки задач?
  • Используется ли Definition of Ready — критерии, по которым задача считается готовой к началу работы?
После этого он спрашивает продукт-менеджера: «А как эти задачи сюда попали?» — и отсюда начинается выстраивание Discovery-процесса.

Где проходит точка принятия обязательств: команда, заказчик и реальность

Иногда в проектах возникают две крайности: команда боится брать на себя обязательства, а заказчик — наоборот, хочет их как можно раньше. Например, прямо на этапе идеи.
Спикер подчёркивает: фиксированная точка принятия обязательств — это благо для команды. Она понимает, с какого момента действительно несёт ответственность и должна «фигачить». Чем яснее эта точка, тем проще.
Проблема возникает, когда заказчики хотят сдвинуть её максимально «влево» — на самый ранний этап. Но это просто не работает.
«Мы не можем вгрузить в команду всё и сразу и ожидать, что она сделает это качественно. Если нужен результат — нужны подготовка и планирование».
Чтобы продукт получился качественным — с проверенными фичами, тестами, автотестами — нужна предварительная работа. Когда заказчикам объясняют, что благодаря чёткой точке обязательств они смогут понимать, когда задача начнёт делаться и когда закончится, — большинство соглашаются.

А если команд несколько?

Допустим, у нас не одна команда, а несколько: одна по Scrum, другая по внедрению, третья — исследовательская. Как быть с обязательствами?
Если это компонентные команды (каждая отвечает за кусок процесса), то точка принятия обязательств наступает, как только первая команда начинает работу. Проблема в том, что дальше задача «гуляет» между другими командами, и это:
  • увеличивает простой;
  • вызывает потери информации;
  • снижает общее качество продукта.
Поэтому Scrum и Kanban рекомендуют создавать end-to-end команды, которые ведут задачу от бэклога до прода. Это позволяет:
  • избежать лишней координации между этапами;
  • повысить скорость;
  • сократить потери при передаче.

Что такое компонентная команда?

Простыми словами: это команда, которая отвечает не за весь процесс, а за часть. Например, одна заливает фундамент, другая — строит стены с одной стороны дома, третья — с другой. Чтобы построить весь дом, они вынуждены постоянно синхронизироваться. Это и есть компонентная структура, которая усложняет поставку ценности.

А если end-to-end команда невозможна?

Бывает, что создать кросс-функциональные команды нереально. Например, DevOps-специалистов или дизайнеров всего двое на компанию. Как встроить их в поток?
Есть два подхода:
  1. Частичное встраивание: выделить специалиста хотя бы на 10 % в команду. Например, сотрудник compliance подключается заранее, чтобы команда учла его требования до выхода в прод.
  2. Развитие компетенций внутри команды: на время берётся нужный эксперт, команда учится, перенимает навыки — и компетенция появляется внутри.
«Такое мы делали в банке — сначала было сложно, но через несколько итераций работало уже как часы».

Про факапы на этапе Discovery

Факапы бывают у всех. Особенно на этапе Discovery — этапе исследования и формирования идеи. Главная ошибка — начинать додумывать и брать на себя роль визионера, а не исследователя.
«Один раз я предложил на этапе Discovery сразу писать тест-кейсы — казалось, будет удобно. А потом оказалось, что задача даже не до конца понята. Всё откатили».
Вывод: сначала — критерии готовности. Всё остальное потом. И никаких тест-кейсов, пока не ясно, что вообще делаем.

Что такое критерии READY?

Definition of Ready (DoR) — набор условий, при которых задача готова к тому, чтобы её взяла команда. Спикер предлагает собирать эти критерии вместе с командой. Просто задать вопрос:
«Что вам нужно, чтобы сделать задачу быстро и качественно?»
Ответы команды — и есть база для DoR. Их можно чуть обогатить, но без фанатизма.

Как отказаться от идей, которые не проходят в бэклог?

Особенно в больших компаниях сотрудники пытаются любой ценой «протащить» идею: через руководство, через давление. Тут важно различать:
  • Мечта и недоработка — иногда идею можно доработать и попробовать позже.
  • Неподходящая идея — нужно уметь отказывать.
Пример из банка: председатель принёс идею, которая «точно принесёт миллионы». Сделали. Через квартал выяснилось — эффект на 2 500 рублей. После этого даже он начал задумываться.

Выводы: где на самом деле создается ценность

Хорошая Discovery — это не только про идеи и гипотезы. Это про чёткие рамки, вовремя сказанное «нет» и понимание командой своей зоны ответственности. Только тогда можно строить устойчивый поток ценности: от идеи до реализации — без догадок, паники и внезапных поворотов в проде.
Важно:
  • Команда должна понимать, когда начинается её обязательство.
  • Не все идеи обязаны дойти до реализации.
  • Отказ — тоже часть продуктивного процесса.
  • End-to-end команды — наше всё (если возможно).
  • Discovery — это про честность, ясность и уважение ко времени.
А еще, как показывает практика, даже самые горячие идеи от руководства могут не сработать. И это нормально. Главное — уметь исследовать, проверять и не бояться отклонить лишнее. Так продукт становится по-настоящему полезным, а команды — спокойными и эффективными.
Хотите улучшить управление в вашей компании?
Если вы хотите вывести управление в вашей компании на новый уровень, специалисты Neogenda помогут в этом. Мы работаем с крупнейшими компаниями, такими как Tinkoff, Яндекс, Авито, Сбер и Билайн, и уже обучили более 5 000 сотрудников. Наши эксперты подберут для вас индивидуальные решения, основанные на реальном управленческом опыте и современных практиках.
Запишитесь на бесплатную консультацию в Zoom, чтобы найти способы сделать вашу команду еще эффективнее.