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

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

<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

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

Результат

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

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

Подготовка к проекту

Подготовка к ИТ-проекту

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

<p>Эта страница нужна, когда проект уже можно обсуждать, но полного технического задания еще нет. Так бывает при доработке существующей системы, запуске нового личного кабинета, интеграции с внешними сервисами или переходе от бизнес-идеи к первому этапу работ.</p><p>Предварительная оценка в такой ситуации возможна, если отдельно зафиксировать вводные, допущения и открытые вопросы. Ее задача — дать управленческий ориентир по бюджету, срокам и следующему шагу, а не заменить ТЗ или discovery.</p>

<p>Для первой оценки важны не все детали будущей системы, а несколько опорных вводных. Они помогают понять масштаб задачи и не смешивать обязательный объем с пожеланиями на будущее.</p><h3>Цель и ближайший результат</h3><p>Нужно описать, что должно измениться после этапа: запустить новый сервис, автоматизировать процесс, заменить ручную операцию, подготовить интеграцию или проверить гипотезу.</p><h3>Пользователи и роли</h3><p>Важно понимать, кто будет работать с системой: клиенты, сотрудники, операторы, администраторы, подрядчики или внешние участники процесса.</p><h3>Системы и данные</h3><p>Даже предварительная оценка зависит от того, какие внутренние и внешние системы участвуют, какие данные уже есть и где возникают ограничения.</p><h3>Ограничения и обязательные требования</h3><p>Отдельно фиксируются безопасность, сроки, регуляторные требования, SLA, интеграции, импорт данных, роли согласования и условия приемки.</p>

Какие вводные нужны для оценки

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

Как выбрать форму оценки

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

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

<p>На выходе нужна не только сумма или диапазон. Хорошая предварительная оценка показывает, что входит в ближайший объем, какие решения пока не приняты и какой следующий шаг снижает неопределенность.</p><p>Обычно результатом становится короткая рамка: цель этапа, список ключевых функций, интеграции и зависимости, известные ограничения, допущения по срокам и стоимости, а также вопросы, которые нужно закрыть до коммерческого предложения или договора.</p>

Что должно получиться

<p>Если полного ТЗ еще нет, начните с короткого описания цели, пользователей, систем, данных и ограничений. После этого можно выбрать формат следующего шага: предварительная оценка, discovery, фиксированный этап или команда на период.</p>

Что дальше

Как оценить ИТ-проект без полного ТЗ: какие вводные собрать, какую форму оценки выбрать и где зафиксировать допущения.

Оценка без ТЗ

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

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

<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>

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

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

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

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

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

Требования

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

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

<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>

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

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

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

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

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

Discovery

Когда нужен discovery

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что подготовить до оценки

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

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

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