Я оценил доработку учётной системы в 300 часов, заказчик ответил, что это очень много. Я для него посчитал тот же объём тремя независимыми способами: снизу вверх по пользовательским действиям, через функциональные точки с отраслевыми показателями производительности ISBSG и через COCOMO II.

Результат оказался обратным ожидаемому. По отраслевой статистике этот объём — 412 функциональных точек — стоит от ~990 часов (90-й процентиль low-code-проектов в репозитории ISBSG) до ~3 600 часов (медиана Java-проектов там же) и до ~12 400 часов по номинальному COCOMO II. Моя оценка в 300 часов — это 0,73 часа на функциональную точку, то есть ниже минимума всей low-code-выборки ISBSG.

Вывод: спорить «много или мало» бессмысленно, пока не назван состав работ и заложенная производительность. Любая оценка в часах — это в первую очередь заявление о допущениях, и моё было очень оптимистичным.

Все расчёты в статье воспроизводимы: приведены исходные счётчики, веса, формулы и ссылки на источники цифр.

Я делаю учётные системы для бизнеса — заявки, склад, производство, расчёты с исполнителями — и последние годы занимаюсь low-code-платформой, на которой такие системы собираются. Цифры и методы, которые я привожу, к конкретной платформе не привязаны и проверяются по открытым источникам.

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

Сначала про границы применимости подхода. Все три метода, которые будут дальше, оценивают известный объём. Ломаются они на неизвестном:

• Миграция накопленных данных. Обычно её нет в ТЗ, и обычно она стоит десятки часов: старые справочники, дубликаты, записи без обязательных полей.

• Чужие API. Оценка «интеграция — 16 часов» верна для документированного API и рассыпается на лимитах, недокументированных полях и чужих релизах.

• Офлайн. Это не фича, а свойство архитектуры: очередь, разрешение конфликтов, идемпотентность. Дописать позже дороже, чем заложить сразу.

• Приёмка. Заказчик впервые видит систему на своих данных — и именно тогда выясняется, что «мастер» в его компании означает не то, что в модели.

Любое число дальше в статье верно ровно до тех пор, пока ни один из этих пунктов не сработал.

Это и был мотив возражения — «зачем мне ваши 300 часов», — поэтому разберу его до всякой арифметики. Я к таким попыткам отношусь без иронии: инструменты действительно сильные. Но данные по ним уже накоплены, и они устойчиво описывают одну и ту же кривую.

Эдди Османи (Google Chrome DX) в декабре 2024 назвал это «проблемой 70%»: первые 70% решения появляются на удивление быстро, а оставшиеся 30% — крайние случаи, безопасность, интеграция с реальностью — остаются такими же трудными, как раньше. Систематический обзор серой литературы (arXiv:2510.00328, ICSE-SEIP 2026, 101 источник практиков и 518 наблюдений из первых рук) фиксирует ровно этот разрыв: практики приходят за скоростью, получают быстрый результат и сами описывают его как «быстро, но с изъянами», а контроль качества при этом систематически выпадает — проверку пропускают, принимают код без изменений или поручают проверку тому же инструменту, который его написал.

Почему разбор завалов даётся тяжело, показывает эксперимент Anthropic (arXiv:2601.20245, n = 52): участники, решавшие задачу с ИИ, показали на 17% худшее понимание кода, который только что получили. Разделяет не опыт, а поведение — те, кто просил объяснений и задавал уточняющие вопросы, удерживали материал заметно лучше.

И цена ошибки в правах: публичное раскрытие CVE-2025-48757 в мае 2025 года описало больше 170 боевых приложений, собранных на одной популярной AI-платформе, у которых базу мог читать и менять любой анонимный запрос — сгенерированная схема приезжала без политик разграничения доступа.

Ни один из этих фактов не говорит «не делайте сами». Они говорят другое: в оценке варианта «сам с ИИ» надо закладывать не только часы сборки, но и часы на то, чтобы понять и проверить сделанное. В моих терминах — это те же действия, которые я считаю дальше, только с неизвестной производительностью.

Обезличенно: внутренняя учётная система сервисной компании. Мобильный веб-интерфейс для исполнителей, десктопный — для администраторов.

• 8 предметных сущностей: записи о работах, проекты, исполнители с прайсом, задачи с комментариями, справочники, пользователи и роли, файлы (фото и голосовые), настройки.

• 13 таблиц в модели данных.

• Экономика: наценка, комиссия, доля владельца — с фиксацией ставок на момент операции.

• Интеграции: Google Sheets, корпоративный таск-трекер, S3-совместимое хранилище, распознавание голоса для заполнения формы.

• Требования сверх веба: офлайн-режим с очередью, PWA-установка, нативные сборки для двух сторов.

Инвентаризация интерфейса и API:

Плюс действия, у которых нет отдельного вызова API: голосовой ввод, офлайн-очередь, черновики, фильтры и поиск, тема оформления, повтор последней записи. Суммарно получается ≈ 90 пользовательских действий.

Эти три числа — 40 поверхностей, 77 эндпоинтов, 90 действий — дальше используются во всех трёх методах.

Оценивать «экран» бессмысленно: в экране может быть одно действие, а может быть двенадцать. Считаю действия, и для каждого — полный цикл, а не только основной сценарий:

Это и есть источник «средних трёх часов». Отдельно подчеркну: половина строк таблицы — не разработка фичи, а её обвязка. Именно она обычно выпадает из интуитивной оценки, потому что в ТЗ про неё не пишут.

Средние 3 часа обманчивы: действия распределены не нормально, а с длинным хвостом. Модель, которой я пользуюсь:

Шкала 1 / 4 / 16 — геометрическая с шагом ×4; она грубая, но воспроизводимая, и её легко оспорить конкретными цифрами вместо ощущений. 306 часов — это и есть та самая «оценка в 300 часов».

Чувствительность модели:

• хвост 12 тяжёлых действий вместо 9 → 354 ч (+16%);

• простые действия по 1,5 часа вместо 1 → 333 ч (+9%);

• обе поправки вместе → 381 ч (+25%).

То есть даже без изменения объёма работ разброс модели — четверть оценки. Отсюда стандартная надбавка +20–30% на приёмку и багфикс, которую я обычно и называю заказчику отдельной строкой.

Принципиальный момент: 306 часов — это стоимость доведения 90 действий поверх готового бэкенда. Если бэкенда нет, добавляются работы, которых нет ни в одном ТЗ, потому что заказчик считает их само собой разумеющимися:

Складывая: доводка действий (306, с надбавкой ~370) + инфраструктура (240–384) + адаптация фронта — получается 800–1150 часов для варианта «с нуля» и 500–725 часов, если существующий фронтенд переиспользуется и меняется только транспорт.

Раньше ТЗ было соразмерно пониманию самого заказчика — расплывчатое там, где заказчик и сам не знал деталей. Сейчас ТЗ всё чаще составляется с участием ИИ, а модель, обученная на корпоративной документации и лучших практиках, по умолчанию подтягивает язык индустриального уровня: требования к аудиту, ролевой модели, обработке ошибок, миграциям, тестовому покрытию — то, что раньше в текст вписывал архитектор большой команды, теперь появляется само, просто потому что для документа такого типа модель считает это хорошим тоном.

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

Разрыв между «0,73 ч/FP» и «8,7 ч/FP» из следующего раздела — это в том числе разрыв между тем, кто фактически придумал требования, и тем, кто должен под них подписаться.

Это первый метод. Он прост и прям, но у него врождённый порок: я оцениваю сам себя, своей же меркой. Поэтому дальше — два способа проверки, которые про меня ничего не знают.

Функциональные точки (IFPUG) считают не код, а функциональность с точки зрения пользователя. Метрике сорок лет, она стандартизована (ISO/IEC 20926), и главное — по ней есть открытая отраслевая статистика.

Считаю по стандартным весам: внутренние логические файлы (ILF) 7/10/15, внешние интерфейсные файлы (EIF) 5/7/10, вводы (EI) 3/4/6, выводы (EO) 4/5/7, запросы (EQ) 3/4/6 — за низкую/среднюю/высокую сложность.

Поправочный коэффициент VAF = 0,65 + 0,01 × TDI. Для системы с распределённой обработкой, ролевой моделью, офлайном, интеграциями и мобильным клиентом TDI ≈ 40, то есть VAF = 1,05.

AFP = 392 × 1,05 ≈ 412 функциональных точек.

Теперь производительность. ISBSG (International Software Benchmarking Standards Group) публикует Project Delivery Rate — часы на одну функциональную точку — по репозиторию из тысяч завершённых проектов. В короткой работе 2021 года сравниваются 648 Java-проектов и 58 low-code-проектов (Mendix, OutSystems, Salesforce), отобранных по качеству данных A/B:

А вот как в этой шкале выглядят мои собственные оценки:

Это неприятное открытие. Мой вариант «с нуля» по производительности попадает не в Java-медиану (8,7), а в диапазон low-code-платформ. А оценка в 300 часов — 0,73 ч/FP — вообще ниже минимума всей low-code-выборки ISBSG.

Третья проверка — из другой школы. COCOMO II оценивает трудозатраты от размера кода:

PM = 2,94 × KSLOC^E × EAF, где E ≈ 1,0997 при номинальных масштабных факторах, а один человеко-месяц принят равным 152 часам (Model Definition Manual).

Размер получаю из функциональных точек через gearing factor. По таблице QSM для JavaScript это 45–63 строки на точку (среднее 54); беру 50 как центральную оценку для смешанного стека.

• 412 FP × 50 ≈ 20,6 KSLOC

• PM = 2,94 × 20,6^1,0997 ≈ 82 человеко-месяца ≈ 12 400 часов при номинальных множителях

Номинальные множители — это «средний проект средней команды со средними требованиями». Мой случай другой: один сильный разработчик, знакомый домен, современный инструментарий, невысокие требования к надёжности (это не медицина и не платёжный процессинг). Совокупный множитель EAF в таком раскладе реалистично 0,4–0,6:

Даже с очень оптимистичными множителями COCOMO II даёт 5 000–7 500 часов — в шесть-девять раз больше моей оценки «с нуля».

Разброс — в двадцать раз. Это не значит, что какой-то метод врёт: они считают разный состав работ.

В отраслевые цифры входит то, чего в оценке одиночки нет по определению:

• аналитика и формализация требований, приёмо-сдаточная документация;

• управление проектом, отчётность, согласования;

• отдельная роль тестирования и полноценный цикл дефектов;

• коммуникационные издержки команды — те самые квадратичные связи, из-за которых удвоение людей не удваивает скорость;

• корпоративные процедуры: релизные окна, ревью безопасности, приёмка со стороны заказчика.

А в моей оценке есть то, чего нет у среднего проекта из репозитория: готовая платформа вроде 1С, закрывающая аутентификацию, права, аудит, CRUD-API, отчёты, файлы и деплой; один человек вместо команды; знакомый домен; отсутствие формального процесса.

Отсюда практический вывод, ради которого всё и считалось: оценка снизу вверх — это нижняя граница при идеальных допущениях, а не «сколько это стоит». Она верна ровно до тех пор, пока верны допущения. Стоит убрать одно — например, оказывается, что нужен второй человек, или что заказчик хочет приёмочную документацию, — и цифра уезжает в сторону отраслевой.

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

«Много или мало» — вопрос без ответа, пока не заданы три других:

1. Что входит в оценку? Только доводка действий? Плюс инфраструктура? Плюс приёмка и документация? Разница между первым и третьим — в 3–4 раза на одном и том же ТЗ.

2. Какая производительность заложена? Мои 0,73 ч/FP — это рекорд отраслевой выборки. Если исполнитель не показывает, за счёт чего он попадает в такую производительность (готовая платформа, генерация, переиспользование), то оценка не оптимистичная, а фантастическая.

3. Что произойдёт, если допущение не сработает? Кто платит за второго разработчика, за миграцию данных, за неожиданный офлайн-режим.

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

Рецепт целиком воспроизводим, никаких инструментов не нужно:

1. Инвентаризация. Выпишите UI-поверхности (экраны, вкладки, значимые модалки) и действия. Действие — то, после чего в системе что-то изменилось или пользователь что-то узнал.

2. Классификация. Разложите действия на простые / средние / тяжёлые. Если сомневаетесь — кладите в более тяжёлый класс, интуиция систематически занижает.

3. Сумма снизу вверх. Умножьте на 1 / 4 / 16 часов и сложите. Добавьте 20–30% на приёмку.

4. Инфраструктура. Если бэкенда нет — добавьте строки из таблицы выше. Если платформа есть, честно перечислите, что именно она закрывает.

5. Перекрёстная проверка. Посчитайте функциональные точки (это час работы по стандартным весам) и умножьте на PDR из отраслевой выборки. Если ваша оценка даёт производительность лучше 90-го процентиля индустрии — либо у вас есть объяснение, либо у вас проблема.

6. Календарь. Продуктивных часов в месяце у одного человека — около 120, а не 168. Делите трудозатраты на 120, а не на «сколько в месяце рабочих часов».

Последний шаг — самый недооценённый. Он превращает «300 часов» в «два с половиной месяца одним человеком», и дальше разговор идёт уже про сроки, а не про абстрактную цифру.