Техническое задание

Discovery-фаза проекта: как провести предпроектное обследование

Discovery-фаза проекта: 5 шагов предпроектного обследования для enterprise. Чек-лист deliverables, типичные ошибки и как сократить сроки discovery до 2 недель.

Discovery-фаза проекта — этап, который отделяет успешные корпоративные IT-проекты от провальных. Однако в enterprise его по-прежнему пропускают. Знакомый сценарий: телеком-компания выделила 12 млн рублей на систему автоматизации операционных процессов. Подрядчик выбран, договор подписан, команда из восьми разработчиков приступила к работе. Через три месяца готовый продукт показали операторам контакт-центра — и те отказались им пользоваться. Система не учитывала реальный workflow: операторы работали в трёх параллельных окнах, а новый интерфейс предлагал линейный процесс из 14 шагов.

Причина? Никто не провёл предпроектное обследование. Требования собирали на уровне директоров, а конечных пользователей даже не опросили. Результат — три месяца переделок, 4,5 млн дополнительных расходов и подорванное доверие к IT-директору, который курировал проект. Эту ситуацию можно было предотвратить за две недели discovery. Подробнее о типичных причинах таких ситуаций — в статье почему IT-проекты проваливаются.

Что такое discovery-фаза и почему без неё рискованно начинать разработку

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

По данным PMI, 37% корпоративных проектов проваливаются из-за неточных целей и требований. Исследование IBM Systems Sciences Institute показывает, что исправление ошибки на этапе требований стоит в 6-10 раз дешевле, чем та же ошибка, обнаруженная в процессе разработки. Для enterprise-проекта стоимостью 5-15 млн рублей это разница между доработкой за 300 тысяч и переделкой за 3 миллиона.

Поэтому discovery — не дополнительная статья расходов, а страховка бюджета. Две недели обследования экономят два-три месяца переделок. Подробнее о том, как составить техническое задание, которое станет результатом quality discovery.

5 шагов discovery-фазы: от бизнес-проблемы до технического задания

Discovery — не хаотичный процесс, а последовательность конкретных шагов. Каждый шаг имеет чёткий вход, выход и участников. Давайте разберём каждый из них.

Шаг 1: Stakeholder mapping — определить всех заинтересованных

Первый шаг — составить карту стейкхолдеров. В корпоративном проекте это не только спонсор и product owner. Это ещё IT-служба, информационная безопасность, юристы, финансовый контроль и, что критично, конечные пользователи.

На практике именно здесь допускают первую ошибку: ограничиваются уровнем C-suite и забывают о людях, которые будут работать с системой ежедневно. Результат — требования, основанные на предположениях руководства, а не на реальности.

РольЧто даёт discoveryРиск без участия

Спонсор проектаБизнес-цели и бюджетные ограниченияПроект не соответствует стратегии Конечные пользователиРеальный workflow и болевые точкиПродукт отвергнут пользователями IT-службаТекущая инфраструктура и интеграцииНесовместимость с корп. системами Служба ИБТребования compliance и ФЗ-152Блокировка запуска на финальном этапе

Выход шага: карта стейкхолдеров с ролями, зонами ответственности и графиком интервью.

Шаг 2: Анализ as-is — понять текущее состояние

Второй шаг — исследовать, как процессы работают сейчас. Не «как описано в регламенте», а как происходит в реальности. В enterprise эти две картины расходятся в 80% случаев.

Методы анализа: глубинные интервью (5-10 с конечными пользователями), наблюдение за рабочим процессом (job shadowing), анализ существующих систем и данных. Ключевой артефакт — карта текущего процесса с замерами: сколько времени занимает каждый этап, где узкие места, какие данные вводятся вручную.

Шаг 3: Формирование to-be — определить целевое состояние

На основе анализа as-is команда проектирует целевое состояние. Здесь важно не просто «автоматизировать то, что есть», а переосмыслить процесс. Иногда лучшее IT-решение — убрать три шага из процесса, а не автоматизировать все семь.

Целевое состояние формулируется в измеримых метриках. Например: «Время обработки заявки — с 48 часов до 4 часов», «Количество ручных операций — с 12 до 3», «Процент ошибок — с 15% до 2%». Без таких метрик невозможно оценить успех проекта после запуска.

Шаг 4: Техническая проверка — PoC ключевых интеграций

Четвёртый шаг — проверить технические гипотезы до начала полноценной разработки. В enterprise главные риски обычно связаны с интеграциями: корпоративная шина данных, SSO/LDAP, legacy-системы с устаревшими API, требования к производительности при высокой нагрузке.

На этом шаге создаётся Proof of Concept (PoC) для самых рискованных интеграций. Если API legacy-системы отдаёт данные за 30 секунд вместо ожидаемых 2 — лучше узнать об этом сейчас, а не через два месяца разработки. PoC занимает 2-3 дня, но может сэкономить месяц переделок.

Шаг 5: Формирование scope и дорожной карты

Финальный шаг — зафиксировать scope первого релиза. На основе всех предыдущих шагов команда определяет: что входит в MVP (Must), что переносится на следующие итерации (Should/Could), что не делаем (Won’t).

Результат — документ с приоритизированными требованиями, техническими ограничениями и реалистичными сроками. Именно этот документ становится основой для технического задания и договора на разработку.

Что получаем на выходе из discovery

Discovery без конкретных deliverables — пустая трата времени. Вот что должно быть готово по завершении:

DeliverableСодержаниеДля кого

Карта стейкхолдеровРоли, зоны ответственности, контактыКоманда разработки Карта процессов as-isТекущий workflow с метриками и узкими местамиАналитики, product owner Целевое состояние to-beЦелевой процесс с измеримыми KPIСпонсор, бюджетный комитет Технический PoCРезультаты проверки ключевых интеграцийАрхитектор, IT-служба Scope MVPПриоритизированные требования (MoSCoW)Product owner, разработка Оценка рисковТехнические, организационные, compliance-рискиСпонсор, служба ИБ Дорожная картаСроки, этапы, ресурсы, зависимостиВсе стейкхолдеры

В ITESCO discovery-фаза входит в стандартный пакет разработки корпоративного MVP. По итогам discovery заказчик получает все семь артефактов, а также предварительную оценку сроков и стоимости основной разработки — до 22 рабочих дней при фиксированном бюджете до 900 000 рублей.

Discovery — это не дополнительная трата. Это страховка бюджета проекта. Две недели обследования экономят два-три месяца переделок и миллионы рублей.

Типичные ошибки discovery-фазы: как не превратить обследование в бюрократию

Даже если компания проводит discovery, она может сделать это неэффективно. Вот три ошибки, которые превращают полезный этап в формальность.

Ошибка 1: Discovery без конечных пользователей

Самая распространённая ошибка — проводить обследование только на уровне руководства. CIO описывает, как «должна работать система», а операторы и аналитики узнают о ней в день запуска. Результат предсказуем: продукт не учитывает реальный рабочий процесс.

Как избежать: минимум 5 интервью с конечными пользователями и один день наблюдения за их работой (job shadowing). Это добавляет 2-3 дня к discovery, но полностью меняет качество требований.

Ошибка 2: Формальный подход — «документ ради документа»

Некоторые компании превращают discovery в бюрократический ритуал: 80-страничный отчёт, который никто не читает. Документация ради документации не приносит ценности. Discovery должна давать инсайты и решения, а не описание очевидного.

Как избежать: фокусируйтесь на артефактах, которые напрямую влияют на разработку. Карта процессов — да. Scope MVP — да. Общее описание отрасли на 30 страниц — нет.

Ошибка 3: Игнорирование compliance и безопасности

Discovery, в которой не участвует служба информационной безопасности, создаёт ложное чувство готовности. Команда формирует scope, начинает разработку — и через два месяца узнаёт, что продукт не может быть допущен к эксплуатации без соответствия ФЗ-152, интеграции с корпоративным SSO и аудит-логирования всех операций. Переделка безопасности постфактум обходится в 3-5 раз дороже. Подробнее о критериях выбора подрядчика, который учитывает compliance, — в статье о выборе IT-подрядчика.

FAQ о discovery

Сколько длится discovery-фаза для корпоративного проекта?

Для стандартного enterprise-проекта discovery занимает от одной до трёх недель. Длительность зависит от количества стейкхолдеров и сложности интеграций. В ITESCO discovery входит в стандартный пакет разработки — результаты готовы до подписания договора на основную разработку.

Можно ли пропустить discovery и сразу начать разработку?

Технически можно, но это увеличивает риск переделок в 4-6 раз. По данным PMI, 37% корпоративных проектов проваливаются именно из-за неточных требований, которые должны были быть выявлены на этапе discovery. Экономия двух недель обычно оборачивается потерей двух-трёх месяцев.

Кто должен участвовать в discovery со стороны заказчика?

Минимальный состав: спонсор проекта (бюджетодержатель), владелец продукта (product owner), 2-3 конечных пользователя, представитель ИТ-службы и специалист по информационной безопасности. Без конечных пользователей discovery теряет 60% ценности — требования будут основаны на предположениях, а не на реальности.

Чем discovery отличается от составления технического задания?

Discovery отвечает на вопрос «что делаем и зачем» — это исследование проблемы, пользователей и ограничений. Техническое задание отвечает на вопрос «как делаем» — архитектура, стек, API, user stories. Discovery — входные данные для ТЗ. Качественная discovery сокращает время составления ТЗ в 2-3 раза.

Discovery определяет 80% успеха проекта

Discovery-фаза — это не факультативный этап, который можно пропустить ради экономии времени. Это фундамент, на котором строится весь проект. Пять шагов — stakeholder mapping, анализ as-is, формирование to-be, технический PoC и определение scope — занимают одну-три недели, но определяют судьбу всей разработки.

Каждый из этих шагов решает конкретную проблему: неточные требования, несовпадение ожиданий стейкхолдеров, технические сюрпризы на поздних стадиях и блокировка запуска службой безопасности. Без discovery эти проблемы не исчезают — они просто обнаруживаются позже и обходятся дороже.

Планируете корпоративный IT-проект и хотите начать с качественной discovery? Запишитесь на бесплатный Zoom-колл с командой ITESCO. Мы разберём вашу задачу, определим ключевых стейкхолдеров и предложим план предпроектного обследования — от двух недель до готового scope для MVP.

FAQ о discovery-фаза проекта

Сколько длится discovery-фаза для корпоративного проекта?

Для стандартного enterprise-проекта discovery занимает от одной до трёх недель. Длительность зависит от количества стейкхолдеров и сложности интеграций. В ITESCO discovery входит в стандартный пакет разработки — результаты готовы до подписания договора на основную разработку.

Можно ли пропустить discovery и сразу начать разработку?

Технически можно, но это увеличивает риск переделок в 4-6 раз. По данным PMI, 37% корпоративных проектов проваливаются именно из-за неточных требований, которые должны были быть выявлены на этапе discovery. Экономия двух недель обычно оборачивается потерей двух-трёх месяцев.

Кто должен участвовать в discovery со стороны заказчика?

Минимальный состав: спонсор проекта (бюджетодержатель), владелец продукта (product owner), 2-3 конечных пользователя, представитель ИТ-службы и специалист по информационной безопасности. Без конечных пользователей discovery теряет 60% ценности — требования будут основаны на предположениях, а не на реальности.

Чем discovery отличается от составления технического задания?

Discovery отвечает на вопрос «что делаем и зачем» — это исследование проблемы, пользователей и ограничений. Техническое задание отвечает на вопрос «как делаем» — архитектура, стек, API, user stories. Discovery — входные данные для ТЗ. Качественная discovery сокращает время составления ТЗ в 2-3 раза.

Обсудить enterprise-проект

30-минутный Zoom-колл: оценим сложность, compliance-требования (ФЗ-152, отраслевые регуляторы), корпоративный стек, бюджет и сроки. Без обязательств.

Связаться через форму