Как оценить ИТ-проект без полного ТЗ

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

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

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

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

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

• Цель и ближайший результат: что должно измениться после первого этапа и почему это важно сейчас.
• Пользователи и роли: кто работает с системой, какие права, действия и ограничения нужны.
• Ключевые сценарии: какие операции, статусы, проверки, уведомления или отчеты входят в первый результат.
• Системы и данные: какие CRM, ERP, сайты, учетные системы, справочники, файлы или API участвуют в работе.
• Ограничения: сроки, бюджетный коридор, безопасность, доступы, регуляторика, нагрузка, SLA и условия приемки.
• Владелец решений: кто подтверждает приоритеты, меняет scope и принимает спорные решения.

Если эти вводные еще не собраны, сначала полезнее подготовить brief для оценки ИТ-проекта или собрать требования перед оценкой разработки.

Для оценки важна не только общая идея проекта, но и качество ближайших задач. Проверьте, какая задача уже готова к оценке: есть ли результат, scope, out of scope, зависимости и критерии приемки.

Без полного ТЗ обычно нельзя честно зафиксировать всю будущую стоимость продукта. Но можно оценить управляемую часть работы и явно показать, где начинается неопределенность.

• Ближайший этап: ограниченный результат с понятными границами и критериями приемки.
• Порядок бюджета: ориентир для решения, стоит ли двигаться дальше и какой формат работ выбирать.
• Диапазон стоимости: вилка с перечисленными допущениями и факторами, которые могут ее изменить.
• Трудоемкость discovery: отдельная оценка проработки требований, архитектурных развилок, интеграций и рисков.
• Фиксированный ограниченный scope: набор работ, который можно принять без ожидания, что туда автоматически попадут все будущие идеи.
• Команда на период: состав и стоимость команды, если объем будет управляться через приоритеты и backlog.

Допущение — это не слабое место оценки, а честно названное условие, на котором она держится. Если условие меняется, оценку нужно пересматривать.

• внешний API доступен, стабилен и покрывает нужные операции;
• данные можно получить в нужном качестве, формате и объеме;
• миграция не требует ручной очистки большого массива данных;
• нагрузка, безопасность и хранение данных не требуют отдельной архитектурной проработки;
• роли пользователей и права доступа не меняют модель процесса;
• критерии приемки можно согласовать до старта этапа;
• внешние согласования, закупки, доступы и контуры тестирования не блокируют команду;
• изменения после старта проходят через понятную процедуру, а не попадают в объем автоматически.

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

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

Если нужно выбрать решение и модель следующего этапа, используйте discovery перед разработкой. Если нужно собрать фактическую картину процессов, систем, данных и рисков, подходит предпроектное обследование ИТ-проекта.

• понятно, на каких вводных построена оценка;
• подтвержденные требования отделены от гипотез и открытых вопросов;
• видно, что входит в ближайший этап, а что вынесено в roadmap или backlog;
• названы допущения, которые могут изменить сроки и стоимость;
• учтены не только интерфейсы, но и API, данные, миграции, тестирование, приемка и эксплуатация;
• понятно, кто принимает решения по изменениям после старта;
• следующий шаг снижает неопределенность, а не просто переносит ее в договор.

• называть раннюю вилку окончательной стоимостью разработки;
• оценивать только экранные формы, забывая интеграции, данные, миграцию, доступы и приемку;
• смешивать подтвержденные требования, пожелания, гипотезы и будущий backlog;
• обещать фиксированный объем при плавающих приоритетах;
• не фиксировать, какие вопросы должны уйти в discovery или предпроектную проверку;
• не связывать оценку с ТЗ, roadmap, моделью покупки работ и правилами изменения scope.

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

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

Если оценка упирается в неизвестную технологию, интеграцию, нагрузку, алгоритм или архитектурный подход, сначала стоит запланировать PoC, НИОКР/R&D или короткую исследовательскую итерацию. Если неопределённость лежит в пользователях, ценности, scope или приоритетах, чаще нужен Discovery. Для выбора формата проверки используйте материал НИОКР и R&D простыми словами.