Страница полезна до первой встречи или перед запросом предварительной оценки. Полного ТЗ на этом этапе обычно нет, но часть вводных уже можно собрать.

Когда применять

<ul><li>какую бизнес-задачу должен решить проект;</li><li>кто будет пользоваться решением и в каких сценариях;</li><li>какие системы уже есть в контуре;</li><li>какие данные нужно получать, хранить или передавать;</li><li>есть ли требования к безопасности, доступам, аудиту, SLA или отчетности;</li><li>какие сроки, бюджетные рамки или закупочные ограничения уже известны;</li><li>кто принимает решения по требованиям и приоритетам.</li></ul>

Минимальный набор вводных

<ul><li>старое ТЗ, RFP, презентацию или перечень требований;</li><li>схему текущего процесса или архитектуры;</li><li>описание интеграций и внешних систем;</li><li>примеры отчетов, экранов, документов или API;</li><li>ограничения инфраструктуры и эксплуатации.</li></ul>

Что можно передать после NDA

После такой подготовки можно быстрее понять, какую форму оценки использовать: предварительную вилку, фиксированный объем этапа, discovery или команду на период.

Результат

Короткий список вводных, которые помогают быстрее перейти от идеи к рабочей оценке проекта.

Перед обсуждением

Оценка и рамка

Оценка и рамка проекта

Что подготовить перед обсуждением проекта

Предварительная оценка возможна до полного ТЗ, если прямо указать, на каких вводных она построена и где остается неопределенность. Задача такой оценки — дать рабочий ориентир, а не спрятать риск в слишком точной цифре.

<ul><li>Фиксированный объем этапа. Подходит, когда ближайший объем достаточно стабилен, а критерии приемки понятны.</li><li>Предпроектный этап. Подходит, когда задача понятна, но решение, требования и архитектурные развилки еще нужно собрать.</li><li>Диапазон оценки. Подходит для раннего сравнения вариантов, если часть требований еще зависит от решений клиента или внешних систем.</li><li>Команда на период. Подходит, когда объем меняется, а приоритеты нужно регулярно уточнять.</li></ul>

Рабочие модели оценки

<ul><li>цель проекта и ближайший результат;</li><li>обязательные и отложенные требования;</li><li>источники требований;</li><li>интеграции и внешние зависимости;</li><li>кто утверждает приоритеты и изменения;</li><li>какая степень точности ожидается от оценки.</li></ul>

Что нужно согласовать до оценки

Чем меньше стабилизированы требования, тем осторожнее должна быть форма оценки. Для плавающего объема точная цена без допущений обычно создает ложные ожидания.

Граница обещания

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

Как выбрать форму оценки, если требования еще не оформлены полностью.

Оценка без ТЗ

Оценка проекта без полного ТЗ

Страница нужна, когда требования уже есть в разных источниках: ТЗ, переписке, интервью, таблицах, презентациях, старой системе или закупочных материалах. До оценки их нужно собрать в один рабочий слой.

<ul><li>формальные документы: ТЗ, RFI, RFP, договорные приложения, политики безопасности;</li><li>интервью и бизнес-ожидания;</li><li>текущая система, интеграции, данные и контур эксплуатации;</li><li>целевая модель решения и ограничения архитектуры.</li></ul>

Источники требований

<ul><li>формулировку требования;</li><li>источник;</li><li>приоритет;</li><li>статус: подтверждено, гипотеза, требует решения;</li><li>зависимости и ограничения;</li><li>критерий приемки или проверки результата;</li><li>ответственного за решение.</li></ul>

Что фиксировать в реестре

В одном списке не стоит смешивать требования к системе, план работ, задачи команды, идеи на будущее и календарные ожидания. Для оценки важно отделить ближайший объем от пожеланий, гипотез и будущих этапов.

Что нельзя смешивать

После нормализации требований появляется база для оценки: видно, что входит в ближайший объем, что зависит от решений клиента и где нужен отдельный discovery.

Как собрать исходные ожидания в рабочую базу требований перед оценкой или стартом этапа.

Требования

Требования до старта работ

Discovery нужен, когда перед основной разработкой необходимо снизить неопределенность: собрать требования, сравнить варианты решения, проверить архитектурные гипотезы, разобрать данные, интеграции или экономику будущего продукта.

<ul><li>решение еще не собрано в понятную первую очередь;</li><li>требования приходят из разных источников и противоречат друг другу;</li><li>есть важные интеграционные или архитектурные развилки;</li><li>нет закрепленного владельца приоритетов;</li><li>от проекта ждут бюджет и сроки, но объем еще нестабилен.</li></ul>

Признаки, что без discovery рискованно

<ul><li>собранная база требований;</li><li>первая очередь результата;</li><li>ключевые архитектурные и интеграционные решения;</li><li>список рисков и открытых вопросов;</li><li>рекомендованная модель следующего этапа.</li></ul>

Что должно получиться на выходе

Discovery не должен притворяться полной разработкой или гарантией абсолютной определенности. Его задача — сузить неопределенность до управляемого уровня и подготовить решение о следующем шаге.

Чего discovery не обещает

После discovery должно быть понятнее, можно ли идти в фиксированный объем, нужна ли оценка диапазоном или проекту больше подходит команда на период.

Когда проекту нужен отдельный этап предпроектной проработки и что должно быть на выходе.

Discovery

Когда нужен discovery

Страница нужна, когда в обсуждении смешиваются разные предметы покупки: готовый результат, поддержка существующей системы, развитие продукта, сопровождение или команда на период.

<ul><li>Проект под результат. Подходит, когда можно описать границы этапа, результат и приемку.</li><li>Поддержка или сопровождение. Подходит, когда важны стабильность, обработка обращений, исправления и регламент реакции.</li><li>Выделенная команда. Подходит, когда объем меняется, а клиент управляет приоритетами и загрузкой команды.</li><li>Предпроектная проработка. Подходит, когда сначала нужно уточнить требования, архитектуру и модель следующего этапа.</li></ul>

Основные варианты

<ul><li>предмет работ;</li><li>границы результата или периода;</li><li>критерии приемки;</li><li>порядок изменения требований;</li><li>ответственность за доступы, данные и внешние системы;</li><li>правила коммуникации, отчетности и управления приоритетами.</li></ul>

Что фиксировать в КП или договоре

Если клиент ждет готовую систему, а фактически покупает процесс работ или команду на период, оценка и ожидания быстро расходятся. Модель покупки лучше назвать до расчета бюджета.

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

После выбора модели понятнее, что именно оценивается: результат, этап, период работы команды, объем поддержки или отдельная проработка.

Как различать разработку под ключ, поддержку, сопровождение и выделенную команду перед оценкой и договором.

Модель покупки

Проект, поддержка или выделенная команда

Этот раздел помогает превратить первичный запрос на разработку, доработку или сопровождение в рабочую рамку для оценки. Здесь собраны материалы о вводных, требованиях, discovery и моделях работ, которые влияют на бюджет, сроки, договоренности и следующий шаг.

Для чего нужен раздел

<ul><li>цель проекта и ожидаемый результат;</li><li>границы ближайшего этапа;</li><li>известные требования и открытые вопросы;</li><li>интеграции, данные, роли и ограничения;</li><li>модель работ: фиксированный объем, предпроектный этап, поддержка или команда на период.</li></ul>

Что входит в рамку оценки

Страницы в этом разделе не заменяют ТЗ, договор или discovery. Они помогают подготовить разговор, собрать вводные и выбрать форму следующего шага без ложной точности.

Как читать материалы

Практические материалы для предварительной оценки ИТ-проекта: вводные, требования, discovery и выбор модели работ.