Оценка ИТ-проекта: почему разные команды дают разные сроки и кто из них прав
Вы приносите одно и то же ТЗ в три компании - и получаете три разные оценки.
У одной "3 недели".
У второй "2 месяца".
У третьей "полгода".
Каждая команда уверена, что именно её цифра правильная. Вы - в замешательстве. Сроки отличаются в разы, аргументы противоположные, а решения нужно принимать сейчас.
В этой статье разберёмся, почему оценки ИТ-проектов так различаются, как отличить реальную оценку от "коммерческой", и как выбрать команду, если сроки прыгают от исполнителя к исполнителю.
Почему это важно
За 10+ лет работы в ИТ я видел десятки проектов, которые "летели" только из-за того, что заказчик выбирал исполнителя по минимальным срокам. Результат всегда одинаковый: переделки, перерасход бюджета, горящие дедлайны и потерянные месяцы.
Меня зовут Антон Рябов. Уже более 10 лет я занимаюсь управлением ИТ-проектами. Последние 5 лет работаю в компании 2PEOPLE IT, где руковожу разработкой веб-, мобильных и AI-проектов под заказ - от идеи до запуска и дальнейшей поддержки.
Через мои руки прошли сотни оценок: от маленьких MVP до сложных корпоративных систем. И я много раз видел, как одна и та же задача у разных команд превращается то в "2 недели", то в "4 месяца".
Вот почему я хочу объяснить механизмы, которые стоят за такими разрывами.
Почему оценки ИТ-проектов отличаются
Различия в сроках - это не хаос и не "кто-то что-то придумал".
Есть конкретные причины, почему оценка ИТ-проекта у компаний может отличаться в 3-5 раз.
1. Нет единой методологии оценки
Одна компания использует:
- декомпозицию по задачам + оценку трудозатрат,
другая - - похожие проекты из прошлого,
третья - - оценку "на глаз" от ведущего разработчика.
Методологии разные - итоговые сроки тоже.
2. Разный уровень проработки ТЗ
Сроки на один и тот же проект могут отличаться, потому что:
- у одной команды больше уточняющих вопросов,
- другая принимает ТЗ как есть,
- третья закладывает риски "вслепую".
Чем хуже проработано ТЗ, тем "шире" оценка.
3. Команда не одинаковая
Оценку дают живые люди, а не алгоритм.
Факторы:
- сеньор или мид считает задачи?
- есть ли опыт в похожих проектах?
- знает ли команда вашу технологию?
Для одних интеграция - "2 часа", для других - "2 дня".
4. Разные стандарты качества
Одна команда делает:
- автотесты,
- CI/CD,
- документацию,
- защиту от edge-кейсов.
Другая - "лишь бы работало на демо".
Качество не видно сразу, но в оценку оно закладывается.
5. Занижение сроков ради продажи
Это частая причина.
Некоторые студии сознательно дают оценку в 2-3 раза меньше - чтобы:
- выиграть тендер,
- обойти конкурентов,
- быстрее закрыть сделку.
Потом сроки "уточняются" и удлиняются уже после старта.
Как формируется реальная оценка
Чтобы понять, кто прав, важно знать, как должна выглядеть честная оценка разработки.
Ниже - схема, по которой работают зрелые команды.
1. Декомпозиция проекта на мелкие задачи
Чем мельче задачи - тем точнее оценка.
Большие блоки - главный источник ошибок.
2. Учёт ограничений и интеграций
Подрядчик обязан учесть:
- сторонние сервисы,
- API третьих лиц,
- нестандартные компоненты,
- архитектурные решения.
Если этого нет в оценке - будьте осторожны.
3. Буфер на риски
Риски неизбежны:
- изменения требований,
- технические сложности,
- неопределённости.
Их нужно закладывать прямо в оценку.
Если буфера нет - срок почти гарантированно будет сорван.
4. Проверка трудозатрат команды
В хорошей оценке видно:
- кто делает,
- сколько времени требуется,
- на что уходит время.
Не "фронтенд - 120 часов", а:
- авторизация - 12 часов
- профиль - 10 часов
- настройки - 16 часов и т.д.
Как проверить оценку подрядчика
Вот реальные способы понять, адекватна оценка или нет.
1. Спросите: "Какие риски вы заложили?"
Если команда отвечает: "Рисков нет" -
значит они просто не проводили анализ.
2. Попросите показать декомпозицию
Нет декомпозиции => нет реальной оценки.
3. Уточните, какие части можно сделать параллельно
Хорошие команды умеют ускорять без потери качества.
4. Посмотрите, учитывают ли они согласование
У 40% студий в оценке отсутствуют:
- ревью,
- согласования,
- тестирование,
- исправления.
Это сразу вдвое занижает сроки.
5. Сравните не только сроки, но и подход
Иногда команда с более длинным сроком предлагает:
- сильную архитектуру,
- реальные риски,
- проверяемую декомпозицию,
- этапность,
- прогноз по изменению сроков.
Чаще всего именно она даёт честную оценку.
Почему заниженные сроки - опасны
Короткие сроки кажутся привлекательными, но на практике приводят к:
- переносу релизов,
- удвоению бюджета,
- потере качества,
- техническому долгу,
- хаотичному кодовому стилю,
- конфликтам.
Очень часто проект, обещанный за 2 месяца,
в итоге занимает 6-8 - с теми же результатами, но с большим количеством нервов.
Как выбрать команду, если оценки расходятся
Практическая схема:
- Уберите крайности
Самая маленькая и самая большая оценка почти всегда не подходят. - Сравните декомпозиции
Что учтено? Что пропущено? Что уточнено? - Выберите подход, а не цифру
Проект - это не число в человеко-часах, а процесс. - Смотрите на прозрачность
Если команда объясняет, как она считает - ей можно доверять. - Оцените коммуникацию
Скорее всего, так же, как они общаются на старте, они будут общаться весь проект.
Вывод
Оценка ИТ-проекта - это не просто цифра в коммерческом предложении.
Это отражение зрелости команды, её опыта, рисков, методологии и качества.
Разные сроки - это нормально.
Важнее понимать, почему они разные и кто действительно даёт реалистичную оценку.
Если статья была полезной - поддержите лайком и поделитесь опытом.