Оценка в 300 часов: как взвесить шансы, риски и трудоёмкость промышленного приложения
Разбор реальной оценки: 40 экранов, 77 эндпоинтов, 90 действий — откуда берутся 300 часов и почему «сгенерируется за пару часов» этому не противоречит. Данные исследований о том, где стопорятся те, кто собирает систему сам, и три модели разработки одной и той же системы с цифрами.
Заказчик прислал техническое задание на учётную систему для сервисной компании и попросил оценку. Мы посчитали по аналогичному проекту — получилось около 300 часов. Ответ был короткий: «300 часов — это очень много».
Реакция понятная. Голая цифра ни о чём не говорит, пока не видно, из чего она сложена. Ниже — разбор на этом самом ТЗ: как считать трудоёмкость, где сгорают часы, которых в задании нет, и как трезво оценить шансы собрать такую систему самому.
Считают не приложения, а действия
Первое, что стоит сделать с любым ТЗ, — перевести его из слов в счётные единицы. Не «нужна система учёта», а сколько в ней поверхностей и сколько действий.
| Что считаем | В этом ТЗ |
|---|---|
| Корневые экраны (вход, выбор проекта, каркас) | 3 |
| Вкладки и подвкладки | 13 |
| Админ-разделы (пользователи, проекты, справочники, права, аналитика, интеграции, брендинг) | 7 |
| Значимые модальные окна и панели | ≈ 17 |
| Всего UI-поверхностей | ≈ 40 |
| REST-эндпоинтов | ≈ 77 |
| Пользовательских действий | ≈ 90 |
Девяносто действий — это CRUD по восьми сущностям плюс аутентификация, админка, интеграции и аналитика. Разделите 300 часов на 90 — выходит около 3,3 часа на одно действие. Вместе с проверкой и отображением во всех случаях.
Вот теперь цифра перестаёт быть абстрактной: вопрос не «стоит ли приложение 300 часов», а «бывает ли законченное действие дешевле трёх часов».
Что такое «одно действие» на самом деле
За словом «действие» стоит не форма с кнопкой. Чтобы действие можно было отдать пользователю, нужно закрыть:
- основной сценарий — то, что все и представляют себе под «сделать экран»;
- валидацию: что будет с пустым полем, минусом в количестве, датой из будущего;
- права: кто видит запись, кто меняет, кто не видит её существования;
- пустое состояние: как выглядит список, в котором ещё ничего нет;
- ошибки: нет сети, сервер ответил 500, двое отредактировали одну запись;
- отражение в списках, отчётах и агрегатах — цифра, которая изменилась здесь, должна измениться и там;
- миграцию того, что уже накоплено;
- проверку руками на реальных данных.
Часть действий закрывается за 15–20 минут. Над частью придётся сидеть неделю: экономика с фиксацией ставок на момент операции, ролевая матрица «роль × ресурс × действие», сведение отчёта, который должен сойтись с бухгалтерией. Средние 3,3 часа — это не средняя работа, а среднее по очень разным работам. Интуиция считает лёгкие случаи, а сроки делают тяжёлые.
Почему «сгенерируется за пару часов» не противоречит 300 часам
По этому ТЗ рабочие места действительно генерируются за пару часов. Это правда, и это действительно просто. Но то, что получается, — каркас: экраны есть, а системы ещё нет. Дальше каждое рабочее место доводится по шагам.
Практический вывод, который стоит нескольких проектов: не делать всё «жахом» и потом переделывать, а закрывать по одному рабочему месту — сразу с проверкой на боевых данных. Иначе получается сорок наполовину готовых экранов вместо пяти работающих.
Ровно это описал Эдди Османи (Google Chrome DX) в декабре 2024 года как «проблему 70%»: первые 70% решения появляются на удивление быстро, а оставшиеся 30% — крайние случаи, безопасность, интеграция с реальностью — остаются такими же трудными, как были. Механизм знаком любому, кто пробовал: чинишь баг → правка ломает соседнее → просишь исправить → появляются ещё две проблемы.
Что происходит, когда систему собирают самостоятельно
Это уже не мнение, а данные — за последние два года их накопилось достаточно.
Четыре цифры, вокруг которых крутится весь спор о самостоятельной сборке. Источники — в абзацах ниже.
Кто собирает. По разбору тысячи комментариев в сообществе r/vibecoding (исследование Vercel/Solveo) 63% практикующих вайб-кодинг — не разработчики. Оговорка важна: это демография активного сообщества, а не репрезентативная выборка всех пользователей.
С каким результатом. Систематический обзор серой литературы (arXiv:2510.00328, ICSE-SEIP 2026, 154 источника, 518 закодированных поведенческих единиц) фиксирует «парадокс скорости и качества»: люди приходят за скоростью, получают быстрый успех — и сами же описывают результат как «быстро, но с изъянами». Отдельно авторы отмечают, что контроль качества регулярно выпадает: проверку пропускают, принимают код без изменений или делегируют проверку тому же инструменту, который этот код и написал.
Что происходит с кодовой базой. GitClear на 211 млн строк изменений показал структурную картину: доля скопированных строк выросла с 8,3% до 12,3%, доля изменений, связанных с рефакторингом, упала с 25% до менее 10%, а доля кода, переписанного в первые две недели после коммита, выросла с 3,1% до 5,7%. Это ровно тот механизм, который в сообществах называют «стеной третьего месяца»: каждая новая фича строится в изоляции от остальной системы, дубли накапливаются, и на третьем месяце проект уходит в полную пересборку.
Движение во всех трёх метриках — в одну сторону: дублей больше, переработки меньше.
Почему человек не может разобрать завал сам. Исследование Anthropic (Shen & Tamkin, arXiv:2601.20245, n = 52) — рандомизированный эксперимент: разработчики, решавшие задачу с ИИ, показали на 17% худшее понимание кода, который только что написали, чем те, кто писал руками. Ключевое различие внутри группы — не опыт, а поведение: те, кто просил объяснить и задавал уточняющие вопросы, удерживали материал заметно лучше тех, кто просто принимал готовый ответ.
Чем это заканчивается в проде. Сотрудник Replit просканировал 1 645 приложений, собранных на Lovable: у 170 из них (10,3%) чужие данные — имена, почты, адреса, ключи — были доступны любому. Причина не в «плохом ИИ», а в умолчаниях: сгенерированная схема базы приезжала без политик разграничения доступа (RLS), и никто в процессе сборки об этом не предупреждал.
Сколько это занимает по календарю. Самообзоры того же сообщества дают диапазон от 3 недель до 3+ лет до первого публичного запуска. Оба края реальны — просто первый вирусится, а «я восемь месяцев не могу запуститься» не пишут.
Отдельная оговорка про часто цитируемую статистику YC: у четверти стартапов набора W25 кодовая база на 95%+ сгенерирована ИИ — но там же уточняется, что это сильные инженеры, которые год назад просто писали бы этот код руками. Это история не про людей без опыта разработки.
Вывод из всего блока не «не делайте сами». Вывод в том, что шансы определяются не бэкграундом, а поведением: понимаете ли вы, что вам вернули, и есть ли у вас способ это проверить.
Где сгорают часы, которых нет в ТЗ
В задании написано про экраны и функции. Часы съедает то, о чём в задании не пишут, потому что это «само собой разумеется». Наша оценка того же проекта на собственном стеке:
| Работа, которой нет в ТЗ | Часы |
|---|---|
| Инфраструктура и каркас (контейнеры, CI/CD, конфигурация, хранилище файлов, кэш) | 40–60 |
| Модель данных и миграции (13 таблиц, ограничения, индексы) | 20–30 |
| Аутентификация и защита (токены, хеши, лимиты, блокировки, аудит) | 24–36 |
| Роли, права, изоляция по проекту | 20–30 |
| Транспортный слой (кэш, очередь, обновление сессии, офлайн) | 40–60 |
| Тестирование | 40–70 |
| Наблюдаемость и бэкапы (алерты, восстановление на момент времени) | 16–28 |
| Нативные сборки и публикация в сторах | 40–70 |
| Итого до первой бизнес-функции | 240–384 |
Это и есть ответ на вопрос «почему так много»: до того как система начнёт считать деньги заказчика, кто-то должен закрыть двести с лишним часов работы, которая никак не видна в интерфейсе — и которую замечают только тогда, когда её не сделали.
Три способа получить одну и ту же систему
Мы посчитали этот проект в трёх моделях. Цифры — наши, по одному конкретному ТЗ; относитесь к ним как к порядку величины, а не как к прайсу.
| Разработчики + ИИ в редакторе | ИИ-агенты + свой стек | ИИ-агенты + Интеграм | |
|---|---|---|---|
| Трудозатраты, человеко-часы | 700–1100 (с нуля) | 400–650 | 200–400 (ядро) |
| Календарь | 3–5 месяцев командой | 4–8 недель | 3–6 недель |
| Что делаете сами | всё: бэкенд, база, права, API, инфраструктура, фронт | то же, но пишет агент; ревью и приёмка на вас | доменную модель и ~6–7 рабочих мест |
| Главный риск | объём работ | «правдоподобно, но неверно» в правах, расчётах, безопасности | рамка рабочего места |
| Инфраструктура и поддержка | своя | своя | платформы |
Третий столбец меньше не потому, что там меньше работы, а потому, что часть работы уже сделана до вас: аутентификация и сессии, роли, права и изоляция по объекту, журнал аудита, CRUD-API, отчёты и агрегаты, файловое хранилище, справочники, деплой и бэкапы. В нашей оценке это 60–70% первоначального объёма.
Границы модели тоже стоит назвать честно. Офлайн-first — работа без связи с локальной очередью — в серверную рамку рабочего места не ложится: это отдельный трек в любом подходе. А вот мобильные приложения в сторах закрываются готовой WebView-оболочкой: ребрендинг, сборка и публикация — 30–70 часов вместо 150–250 часов разработки обёртки с нуля.
Пять вопросов, чтобы взвесить свои шансы
- Сможете объяснить, что делает то, что вам сгенерировали? Не «работает ли», а почему именно так. Это единственный предиктор, который в исследованиях отделяет дошедших до прода от застрявших.
- Как вы отличаете «запустилось» от «работает»? Если ответ «нажал и увидел» — у вас нет приёмки, а значит, нет и оценки готовности.
- Кто отвечает за доступ к данным? У 10% публично проверенных приложений он не был закрыт вообще. Если в системе персональные данные клиентов, это не технический вопрос, а юридический.
- Что будет на третьем месяце? Когда правка в одном месте начнёт ломать три других — кто будет разбирать? Это самый частый момент выхода из проекта.
- Какие пункты ТЗ действительно критичны? Офлайн, публикация в сторах, мультиарендность — самые дорогие требования. Каждое стоит отдельно проверить вопросом «что мы потеряем, если этого не будет в первой версии».
Если на первые три вопроса ответа нет, оценка в 300 часов не завышена, а занижена: к ней добавится этап «понять, что уже написано». По наблюдениям исполнителей, которые специализируются на спасении таких проектов, доведение прототипа до продакшна занимает в разы больше времени, чем его первоначальная сборка.
Что делать с оценкой, которая кажется большой
Резать надо не оценку, а объём — это разные вещи.
- Очередь по деньгам, а не по ТЗ. Первым делается то рабочее место, которое сразу начинает приносить пользу: приём заказов, учёт выработки, расчёт с исполнителями. Остальное ждёт.
- Каждое место — на боевых данных. Проверка на реальных данных с первого шага ловит ошибки модели, пока они стоят часы, а не недели. Мы называем это «Живым ТЗ»: прототип собирается за минуты, заказчик сразу видит и правит.
- Не платить дважды за готовое. Аутентификация, права, аудит, отчёты, бэкапы — уже написаны; если они попали в вашу смету, вы оплачиваете чужую решённую задачу.
- Отделить рабочее от витринного. Часть требований в ТЗ существует «чтобы было». В первой версии их не будет — и никто не заметит.
Итог
300 часов — это цена не «приложения», а девяноста доведённых до рабочего состояния действий. Каркас из сорока экранов действительно появляется за пару часов, и в этом нет противоречия: быстро делается первая часть пути, а стоит — вторая.
Шансы собрать промышленную систему самому есть, и они не про диплом. Они про три вещи: понимаете ли вы, что вам вернули, есть ли у вас приёмка и закрыт ли доступ к данным. Всё остальное — трудоёмкость, и её можно посчитать заранее, а не узнать на третьем месяце.
Если хочется сравнить подходы дальше — у нас есть отдельный разбор, кто принимает проектные решения в заказной разработке, коробке и у ИИ-агента, и что агент умеет при сборке приложения на самом деле.