Оценка объёма и трудозатрат проекта учебного видео

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

Кратко

Определение объёма превращает расплывчатую идею («нам нужна платформа учебного видео») в чёткий список того, что вы будете делать и чего не будете; оценка превращает этот список в трудозатраты, сроки и обоснованное число. Единственное число, которое называет подрядчик, – наименее надёжная часть оценки. Честная оценка – это диапазон, который сужается по мере того, как исчезают неизвестные. Сильнее всего на него влияют четыре решения по объёму: live или запись, насколько интерактивно видео, со сколькими системами вы интегрируетесь (включая государственные вроде ФИС ФРДО и ЕСИА) и сколько нефункциональной работы вы учитываете (тестирование, доступность, защита персональных данных по 152-ФЗ, управление проектом). В статье весь путь пройден по шагам, с полной арифметикой; в итоге получается реалистичная профессиональная платформа учебного видео примерно за 8,5 млн ₽ и около семи месяцев – то же рабочее число, что и в модели стоимости платформы обучения. Если относиться к оценке как к дисциплине с устоявшимися методами (относительная оценка, трёхточечная оценка PERT, прогноз по референтному классу), а не как к одной догадке, вы точно поставите задачу инженерам, оцените смету по существу и избежите перерасходов, которые губят большинство проектов.

Зачем это читать

Если вы заказываете продукт с учебным видео, судьбу проекта решает не запуск, а оценка. Слишком низкое число помогает получить финансирование, а потом оставляет проект недостроенным; число без диапазона не позволяет отличить осторожного подрядчика от оптимистичного. Большинство ИТ-проектов выходят за рамки: по классическим данным многолетнего отраслевого исследования CHAOS, проекты в среднем обходились в 189% от исходной оценки бюджета и занимали 222% от исходного срока, и лишь меньшинство укладывалось в срок и бюджет. Статья написана для тех, кому нужно превратить идею в объём и бюджет, не будучи инженером: директора по обучению, основателя онлайн-школы или EdTech-стартапа, продакт-менеджера. Она даёт тот же метод определения объёма и оценки, которым хорошая инженерная команда пользуется внутри, чтобы вы могли сами составить или проверить число.

Сначала объём – туман не оценишь

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

Возьмите фразу, с которой обычно начинается проект: «Нам нужна платформа, где сотрудники смотрят обучающие видео, а мы видим, кто прошёл». За одним этим предложением скрывается десяток развилок, и каждая меняет стоимость на сотни тысяч, а то и миллионы рублей. Видео записаны один раз и смотрятся по запросу – или есть живые занятия? Достаточно «посмотрел» – или внутри видео учащиеся отвечают на вопросы? Завершение должно уходить в HR-систему компании – или просто показываться на дашборде? Выдаёте ли вы удостоверения о повышении квалификации, сведения о которых нужно вносить в государственный реестр? Будет мобильное приложение – или только сайт? Нужна ли доступность для людей с ограниченными возможностями здоровья? Ни на один из этих вопросов исходная фраза не отвечает, и каждый – решение по объёму, которое нужно принять, прежде чем число обретёт смысл.

Самый полезный инструмент здесь – список «в работе / за рамками»: буквально две колонки, где каждая функция-кандидат отнесена либо к «в работе» (делаем сейчас), либо к «за рамками» (не в этой версии). Функция «за рамками» не отброшена: она запланирована на более позднюю фазу, и благодаря этому первое число остаётся честным. Привычка относить каждую идею к одной из колонок и превращает идею в объём. Рабочий лист в конце статьи содержит такой список как заготовку.

С этим тесно связана идея минимально жизнеспособного продукта (MVP) – наименьшей версии продукта, которая приносит реальную пользу и позволяет учиться на реальных пользователях, намеренно оставляя продвинутые функции на потом. Для платформы учебного видео MVP может быть только веб-версией на готовом плеере, с простым трекингом завершения, без живых занятий, мобильных приложений и глубоких интеграций. MVP – не дешёвая версия полного продукта, а другой, меньший объём, выбранный осознанно. Решить, что входит в MVP, а что подождёт, – самый результативный ход при определении объёма: так вы быстрее выпускаете продукт, учитесь на нём и оцениваете остальное с куда меньшей неопределённостью.

Нажмите, чтобы увеличить

Два числа под каждой оценкой: трудозатраты и время

Прежде чем переходить к методам, зафиксируйте различие, на котором спотыкается почти каждый начинающий заказчик: трудозатраты и длительность – не одно и то же. Трудозатраты – это объём работы, измеренный в человеко-времени (человеко-днях, человеко-неделях, человеко-месяцах). Длительность – это время по календарю, и она зависит от того, сколько людей работают параллельно и сколько они ждут друг друга.

Задача в десять человеко-недель не займёт десять календарных недель, если пятеро инженеров могут одновременно работать над независимыми частями. Но и в две недели она не уложится: часть работы делается строго по порядку (нельзя протестировать плеер, пока его нет), а на одном проекте люди никогда не работают со стопроцентной отдачей. Хорошие команды знают по опыту: календарное время всегда больше, чем наивное деление «трудозатраты ÷ люди», из-за координации, ревью, встреч и тех частей, которые просто нельзя распараллелить.

Деньги следуют за трудозатратами, а не за длительностью: вы платите за человеко-время. Поэтому любая оценка строится по цепочке: объём → трудозатраты (человеко-недели) → стоимость (трудозатраты × смешанная ставка) → длительность (календарный план с учётом порядка работ и размера команды). Если держать эти величины раздельно, вас больше не удивит, что «три месяца» и «три инженера на три месяца» стоят совершенно по-разному.

Коротко о ставке, потому что от неё зависит весь масштаб. Одна и та же человеко-неделя стоит по-разному в зависимости от того, кто и где её выполняет: штатный разработчик или студия, Москва или регион, junior или senior. Ориентир по рынку труда – медианные зарплаты разработчиков «на руки» по данным Хабр Карьеры на 2026 год: 97 тыс. ₽ в месяц у junior, 178 тыс. у middle, 304 тыс. у senior и 380 тыс. у lead; во втором полугодии 2025 года медиана разработчиков в Москве была около 230 тыс. ₽, в Санкт-Петербурге – 200 тыс., в регионах – 159 тыс. Часовая ставка подрядчика всегда выше зарплаты в пересчёте на час: в неё входят налоги и взносы, менеджмент, тестирование, простои и маржа. Поэтому трудозатраты в человеко-неделях можно переносить из одной оценки в другую, а рубли – нет.

Строительные блоки: карта «функция → трудозатраты»

Основа оценки «снизу вверх» – карта «функция → трудозатраты»: вы разбиваете продукт на узнаваемые блоки, привязываете к каждому реалистичный диапазон трудозатрат и стоимости и складываете. Платформа учебного видео почти всегда раскладывается на одну и ту же горстку блоков. Диапазоны ниже – ориентиры 2026 года для профессиональной заказной платформы: публичные оценки заказной разработки, пересчитанные по курсу 85 ₽/$ и приведённые к ставке 4 700 ₽ в час – той же, что в рабочем примере ниже. Это те же блоки, что и в модели стоимости; здесь они служат слагаемыми оценки.

Две вещи в этой таблице застают врасплох. Во-первых, стоимость интеграции указана за штуку, а не суммарно: за словом «интеграции» в брифе скрывается множитель, потому что три интеграции стоят примерно втрое дороже одной. Во-вторых, последняя строка – вообще не функция, но это реальные деньги. Видимые функции – лишь часть работы, а тестирование, админ-инструменты и координация обычно добавляют ещё 25–40% сверху. Оценка, которая перечисляет только эффектные функции и забывает эту строку, занижена заведомо.

Нажмите, чтобы увеличить

Четыре множителя, которые сильнее всего влияют на итог

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

1. Live или запись – самый большой скачок

С инженерной точки зрения видео по запросу – дешёвый вариант: каждое видео кодируют один раз, хранят и раздают через сеть доставки контента (CDN). Live-видео – живой виртуальный класс – это другая и куда более крупная разработка. Оно работает на WebRTC (Web Real-Time Communication) – браузерном стандарте аудио и видео в реальном времени, ставшем рекомендацией W3C в 2021 году, – а в групповом занятии потоки всех участников идут через медиасервер, который называется Selective Forwarding Unit (SFU). Скрытая работа – во всём вокруг: сигнальный сервер для соединения участников, STUN- и TURN-серверы для обхода NAT и счёт за трафик, который становится самой крупной и наименее предсказуемой текущей статьёй live-видео. Практики прямо говорят, что настройка SFU, STUN/TURN и сигналинга, а затем тестирование в реальных сетях – это «многонедельная работа как минимум», и это ещё до первой учебной функции.

Практическое правило оценки: если живые занятия входят в объём, это не маленькое дополнение, а второй продукт, подключённый к первому. Здесь же проходит самая ясная развилка «строить или купить» во всём проекте. Готовый видео-API или SDK реального времени с поминутной тарификацией (ориентировочно порядка 0,34 ₽ за участник-минуту, сверяйте с прайсом провайдера) превращает недели инфраструктурной работы в дни интеграции, но поминутная плата остаётся с вами навсегда. Собственный медиасервер на open-source (mediasoup, Janus, LiveKit) в российском облаке окупается только на большом и стабильном масштабе. Технические детали – в статьях WebRTC для живого обучения и масштабирование живого класса; для определения объёма важен один вопрос – live в работе или за рамками, потому что ответ может удвоить бюджет разработки.

2. Насколько видео интерактивно

Видео, которое только проигрывается, – дешёвое. Видео, внутри которого учащийся действует – отвечает на тесты в плеере, выбирает ветки сценария, кликает по активным зонам, – это строка «интерактивный видеоплеер», и её диапазон (720 тыс. – 2,8 млн ₽) широк именно потому, что под словом «интерактивный» понимают очень разное. Простой тест поверх видео стоит скромно. Настоящий ветвящийся сценарий, где видео меняется в зависимости от выбора учащегося, – одна из самых трудоёмких функций учебного видео: каждую ветку нужно написать, плеер должен отслеживать состояние, а аналитика – понимать, какими путями шли учащиеся. Если в брифе написано «интерактивный», ваша задача при оценке – уточнить, какие именно взаимодействия нужны: от одного этого слова стоимость блока может измениться вчетверо. Механика разобрана в статьях что делает видео интерактивным и ветвящиеся сценарии.

3. Со сколькими системами вы интегрируетесь

Каждая интеграция – отдельная строка объёма со своей стоимостью: каждая внешняя система говорит на своём языке и ломается по-своему. В учебном видео это обычно стандарт или внешняя система, с которой нужно состыковаться, и каждая требует настоящей инженерной работы:

• Вход учащегося через существующие корпоративные учётные записи – единый вход (SSO) через SAML или OIDC, – чтобы людям не приходилось заводить новый пароль.
• Трекинг, который умеет читать LMS. Стандарт с фиксированной моделью данных, который упаковывает курс так, чтобы любая система обучения могла его запустить и сохранить результаты, называется SCORM (ADL); он отслеживает завершение, балл и время внутри запуска из LMS. Более богатый современный стандарт, Experience API (xAPI 1.0.3, ADL), записывает детальные события как утверждения в Learning Record Store (LRS) – хранилище, которое само по себе отдельный компонент, и его нужно развернуть.
• Запуск вашего инструмента внутри чужой LMS. Learning Tools Interoperability (LTI 1.3, 1EdTech) делает это через запуск на базе OIDC с подписанным токеном. Это доверенный запуск, а не вход по паролю, и корректно реализовать его – реальная работа.
• Государственные системы. Если вы выдаёте удостоверения о повышении квалификации или дипломы о профессиональной переподготовке, сведения о них нужно вносить в ФИС ФРДО – с 01.09.2025 в течение 30 дней со дня выдачи. Если на аттестации нужно подтверждать личность через Госуслуги, это интеграция с ЕСИА по правилам электронного обучения (п. 14–18 ПП 1678). Если вы обучаете охране труда, результаты проверки знаний попадают в реестр обученных лиц Минтруда. Каждая такая система – отдельная строка со своим регламентом подключения.

Правило для оценки здесь механическое, но его легко упустить: посчитайте интеграции, потом умножьте. Фраза «интегрируется с нашими системами» в брифе скрывает число. Зафиксируйте его – две? пять? – потому что при 240 тыс. – 1,4 млн ₽ за штуку это один из самых сильных рычагов во всей оценке. Сами стандарты разобраны в статьях SCORM: что это, xAPI (Tin Can) и LTI: запуск инструментов внутри LMS.

4. Нефункциональная работа: платформы, масштаб, данные, доступность

Четвёртый множитель – всё, что не видно на экране как функция, но требует реальных трудозатрат. Мобильное приложение в дополнение к сайту – фактически второй клиент, который нужно разработать и сопровождать (720 тыс. – 3,5 млн ₽). Проектирование под большую растущую аудиторию добавляет архитектурную работу.

Отдельная строка – персональные данные. Как только платформа хранит данные учащихся, вы становитесь оператором персональных данных по 152-ФЗ, а это конкретные задачи. Базы с ПДн граждан РФ должны находиться в России: с 01.07.2025 операции с ними с использованием баз данных за рубежом не допускаются, так что зарубежные формы, CRM, аналитика и SaaS-LMS для сбора ПДн отпадают. Согласие на обработку с 01.09.2025 оформляется отдельно от других документов, а за несовершеннолетних его дают законные представители. Нужны меры защиты и порядок реагирования на утечки: штраф для юрлица за утечку – до 15 млн ₽, за повторную – 1–3% выручки.

Для многих заказчиков обязательна и доступность. Международный стандарт WCAG 2.1 уровня AA (критерий успеха 1.2.2 требует субтитров к записанному видео) лёг в основу ГОСТ Р 52872-2019. Национальный стандарт добровольный, но его часто прописывают в ТЗ, а для обучающихся с ОВЗ 273-ФЗ требует специальных условий обучения (ст. 79). Наконец, если заказчик – образовательная организация, правила электронного обучения требуют, чтобы LMS, ПО видеосвязи и прокторинга создавались и использовались по законодательству РФ и (или) входили в реестр российского ПО (п. 21 ПП 1678). Госзаказчики на практике смотрят на реестр, и это меняет выбор готовых компонентов. Каждый из этих пунктов – решение по объёму, которое влияет на всю оценку, и обычно всё это обнаруживается после сметы, а не до. Честнее решить их при определении объёма и заложить в цену. (Объём работ по доступности разобран в статье WCAG 2.1 AA и ГОСТ Р 52872-2019 для учебного видео.)

Как на деле получить оценку

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

Относительная оценка (story points). Вместо того чтобы заранее угадывать часы для каждой задачи, agile-команды оценивают задачи относительно друг друга («эта функция примерно такого же размера, как та, что мы делали в прошлом спринте») в абстрактных единицах – story points, часто по шкале 1, 2, 3, 5, 8, 13. Команда оценивает вместе, нередко с помощью planning poker: все открывают карты одновременно, чтобы ничьё мнение не стало якорем для остальных. За несколько спринтов команда узнаёт свою скорость (velocity) – число points за спринт, – и по ней points переводятся в календарь. Сила относительной оценки в том, что люди гораздо лучше говорят «больше или меньше вот этого», чем угадывают абсолютные часы.

Трёхточечная оценка (PERT). Для каждого блока пишите не одно число, а три: оптимистичный случай (O, всё идёт хорошо), наиболее вероятный (M) и пессимистичный (P, что-то пошло не так). Ожидаемое значение считают по формуле PERT (Program Evaluation and Review Technique), которая придаёт наиболее вероятному случаю большой вес:

Ожидаемые трудозатраты  E = (O + 4M + P) / 6
Неопределённость (СКО)   ≈ (P − O) / 6

Пример для слоя трекинга: оптимистично 4 человеко-недели, наиболее вероятно 6, пессимистично 12.

E = (4 + 4×6 + 12) / 6 = (4 + 24 + 12) / 6 = 40 / 6 ≈ 6,7 человеко-недели
СКО ≈ (12 − 4) / 6 ≈ 1,3 человеко-недели

Вы закладываете около 6,7 человеко-недели, а разброс (±1,3) показывает, насколько можно быть уверенным в этой цифре. Трёхточечная оценка решает две задачи сразу: даёт более реалистичное ожидаемое значение, чем одна догадка, и показывает, насколько неопределён каждый блок, – ровно ту информацию, которую единственное число теряет.

Прогноз по референтному классу (взгляд снаружи). Самая надёжная поправка на человеческий оптимизм – перестать смотреть только на свой проект. Люди оценивают, представляя шаги этого проекта («взгляд изнутри»), и систематически занижают; эту склонность Канеман и Тверски назвали ошибкой планирования (planning fallacy). Лекарство – прогноз по референтному классу: посмотреть на фактические итоги похожих завершённых проектов («взгляд снаружи») и отталкиваться от их реального распределения. На практике спросите подрядчика, сколько на деле стоили и сколько длились его последние три сопоставимых проекта учебного видео, а не на что он надеется в вашем. Если уверенное число «снизу вверх» расходится с референтным классом, верьте референтному классу: завершённые проекты не страдают оптимизмом.

Почему одно число всегда неверно: конус неопределённости

Если сложить три метода, вы придёте к главной идее оценки: ответственная оценка – это диапазон, и шире всего он в начале. Это конус неопределённости – устоявшаяся закономерность, которую популяризировал Стив Макконнелл на основе более ранней работы Барри Боэма. На стадии начального концепта, пока объём не определён, оценки реалистично точны лишь в пределах примерно 0,25×–4× от итогового факта. Дело не в некомпетентности: 16-кратный разброс задан тем, как мало известно в начале. По мере того как объём фиксируется, требования детализируются, а дизайн готов, конус сужается: примерно до ±50% после определения продукта, до ±25% после завершения требований и ещё сильнее по ходу работы.

Нажмите, чтобы увеличить

Практических следствий три. Во-первых, тот, кто называет точное единственное число для неочерченного проекта, либо угадывает, либо прячет диапазон, – спрашивайте диапазон. Во-вторых, сузить число помогает не давление, а информация: вложитесь в платную фазу дискавери и дизайна, и конус действительно сузится. В-третьих, резерв на непредвиденное (contingency) – обычно 15–25% на разумно очерченном проекте – не «запас в карман», а названная и видимая ширина конуса на текущей стадии. Скрытый запас – тайная подушка внутри каждой задачи; резерв – явная строка, которая говорит: «вот во сколько сейчас оцениваются неизвестные». Показывайте его, а не прячьте.

Рабочий пример: от идеи к 8,5 млн ₽ и семи месяцам

Соберём число, которое используется во всей модели стоимости: профессиональная заказная платформа учебного видео с интерактивным плеером, трекингом xAPI, двумя интеграциями (SSO и HR-система), базовым живым классом, веб-клиентом и лёгким мобильным приложением. Оценим трудозатраты по каждому блоку тремя точками, переведём их в стоимость по условной смешанной ставке подрядчика 4 700 ₽ в час (при 40-часовой неделе это 188 000 ₽ за человеко-неделю), а затем разложим по календарю.

Функции дают около 42 человеко-недель и 7,9 млн ₽. Теперь нефункциональная работа поверх них. Обычно на QA, админ-инструменты и управление проектом закладывают 25% даже при строго очерченном объёме, но здесь оценки по блокам уже включают часть этой работы, поэтому вместо плоских 25% добавим видимый резерв около 7%: 7 914 800 ₽ × 1,07 ≈ 8,47 млн ₽. Итог – около 8,5 млн ₽, как и в рабочем примере модели стоимости. Обратите внимание: оценка – это сумма оценённых блоков, поэтому так важно очертить каждый из них.

Ставка здесь – допущение, а не прайс: в неё, помимо работы разработчиков, входят налоги и взносы, дизайн, тестирование, управление проектом и маржа. Подставьте ставку своего подрядчика: во сколько раз она отличается от 4 700 ₽ в час, во столько же раз изменится и итог, а 42 человеко-недели останутся теми же. Поэтому договариваться в первую очередь стоит о человеко-неделях.

Теперь переведём 42 человеко-недели в календарь. Работа идёт фазами, и не все участники небольшой команды заняты одновременно: сначала дизайн, затем плеер и трекинг вместе, интеграции, live и мобильное приложение внахлёст, потом фаза стабилизации и тестирования, которую нельзя торопить. Реалистичная длительность – около семи месяцев, а не десять-одиннадцать недель, которые дало бы наивное деление «42 ÷ 4». Разницу дают координация, ревью и порядок работ, которые деление «трудозатраты ÷ люди» всегда игнорирует.

Нажмите, чтобы увеличить

Не забудьте счёт, который не кончается

Объём, в котором оценена только разработка, неполон: у платформы учебного видео есть вторая половина стоимости, которая растёт каждый месяц, пока у вас есть учащиеся, – доставка видео, минуты живых занятий, хранение, субтитры и хостинг в российском облаке. Для платформы на 5 000 учащихся этот текущий счёт – примерно 2,0–4,5 млн ₽ в год, то есть 6–13,5 млн ₽ за три года. Это сопоставимо со всем бюджетом разработки или больше него, а с ростом аудитории текущий счёт уходит далеко вперёд. Поэтому определение объёма должно включать оценку текущих расходов, а не только разработки, и расчёт «строить или купить» зависит от обеих частей. Полная арифметика и таблица для расчёта своих чисел – в модели стоимости платформы обучения. При определении объёма помните: у вопроса «сколько это стоит?» два ответа, и дать нужно оба.

Частые ошибки

Называть единственное число для неочерченного проекта. Самая частая и самая разрушительная ошибка. Пока объём не зафиксирован, честный ответ – диапазон (на стадии концепта конус шире ~16×). Точное единственное число на этой стадии – догадка, выдающая себя за расчёт. Спрашивайте диапазон и допущения за ним.

Оценивать только разработку, забыв об эксплуатации. Команда находит 8,5 млн ₽ на разработку, запускается и получает счёт за видео, который никто не смоделировал. Оценивайте обе половины, иначе деньги кончатся уже после запуска, а не во время разработки.

Прятать запас вместо того, чтобы показать резерв. Тайный запас в каждой задаче подрывает доверие и срезается на переговорах; видимая строка резерва размером с текущую ширину конуса защитима и выдерживает проверку. Сумма та же, а доверие к ней совсем другое.

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

Вспоминать о регуляторике после сметы. Выгрузка в ФИС ФРДО, отдельное согласие на обработку ПДн, базы данных в России, требование реестра ПО у образовательного заказчика – строки объёма, а не юридические формальности. Если они всплывают после подписания сметы, то превращаются в доработки по худшей цене.

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

Где здесь Фора Софт

Чтобы хорошо очертить и оценить продукт учебного видео, нужен опыт похожих проектов: референтный класс и есть главный актив. Фора Софт с 2005 года разрабатывает видеоконференции, стриминг, e-learning, телемедицину, OTT и видеонаблюдение и выпустила 250+ проектов, поэтому наши оценки опираются на то, сколько на деле занимали сопоставимые проекты, а не на оптимистичный взгляд изнутри. Особенно это важно на развилках «строить или купить»: в live-видео выбор между готовым API и собственной SFU-инфраструктурой меняет бюджет на порядок и решает, получится ли число, под которое можно найти финансирование, или число, на котором проект встанет. Честный результат – очерченный диапазон с видимыми допущениями, а не единственная цифра, за которой спрятан конус.

Главное

• Очертите объём до оценки: список «в работе / за рамками» и названный MVP превращают идею в то, к чему можно привязать число.
• Стоимость определяют трудозатраты (человеко-недели); длительность – отдельный календарный вопрос, и она всегда больше, чем «трудозатраты ÷ люди».
• Сильнее всего на число влияют четыре решения: live или запись, глубина интерактивности, число интеграций (включая госсистемы) и нефункциональная работа (включая 152-ФЗ и доступность).
• Оценивайте по трём точкам (PERT: E = (O + 4M + P) / 6), сравнивайте блоки относительно друг друга и сверяйтесь с референтным классом завершённых проектов.
• Ответственная оценка – это диапазон; на стадии концепта конус неопределённости шире ~16× и сужается лишь по мере исчезновения неизвестных.
• Оценивайте текущие расходы, а не только разработку: за несколько лет они могут превзойти весь её бюджет.

Что читать дальше

• Модель стоимости платформы обучения: во что обходится создание и эксплуатация
• Построить, купить или расширить существующую LMS
• Эталонная архитектура: корпоративная LMS с видео