Финансовая модель IT‑проекта — это таблица (или набор таблиц), где вы честно переводите «хотим приложение/сайт/CRM» в деньги, сроки и риски: сколько стоит сделать, сколько стоит владеть, когда проект окупится и что будет, если всё пойдёт “по плану”, то есть с задержками.

Самая частая ошибка новичков в IT — думать, что «стоимость проекта» равна «стоимости разработки». Это как считать цену автомобиля по гайкам: ехать-то будет, но недолго и дорого. Финмодель it‑проекта нужна ровно для того, чтобы не выяснить через 4 месяца, что бюджет кончился на авторизации, а впереди ещё интеграции, поддержка и внезапное «а давайте сделаем как у Тинькофф».

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

Зачем вообще нужна финансовая модель it‑проекта

Тезис: финмодель не про «красивый Excel», а про управляемость: вы заранее фиксируете допущения и видите, где проект сломается по деньгам или срокам.

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

Практический вывод: если вы не можете объяснить стоимость проекта через структуру затрат и драйверы (что именно её увеличивает), бюджетом будет управлять случай.

Подводный камень: «оценим по аналогам». Аналоги полезны, но без разложения на компоненты это гадание на прошлогодних сметах.

Ключевая идея: считать не “разработку”, а “владение” (TCO)

TCO (Total Cost of Ownership) — совокупная стоимость владения. Для большинства бизнес‑систем она за 1–2 года легко догоняет или превышает первоначальную разработку: поддержка, серверы, лицензии, доработки, безопасность, аналитика, техдолг.

Что обычно входит в TCO

• Разработка: аналитика, UX/UI, backend, frontend, тестирование (QA), DevOps.
• Инфраструктура: облака/серверы, домены, SSL, резервное копирование, мониторинг.
• Лицензии и сервисы: 1С, Контур, КриптоПро, СКЗИ (средства криптографической защиты), таск‑трекеры, базы знаний.
• Эксплуатация: техподдержка, устранение инцидентов, обновления, SLA.
• Развитие: постоянные изменения по запросам бизнеса (и вот она, «бесконечная дорожка задач»).

Подводный камень: «потом как‑нибудь поддержим». Обычно это означает: «поддержка будет дорогой, потому что её не заложили и не спроектировали».

Методология: из чего реально состоит финмодель it‑проекта

Шаг 1. Декомпозиция результата: что именно вы строите

Тезис: сначала — границы. Потом — деньги.

Как делать: описываете продукт через MVP и последующие релизы. MVP — минимально работающая версия, которая даёт измеримый эффект (не «красивый интерфейс», а, например, сокращение времени обработки заявки).

1. Цель проекта (метрика, а не лозунг).
2. Контуры функциональности (что входит / не входит).
3. Интеграции (1С, Битрикс24, МойСклад, Госуслуги, СМС‑шлюзы, платёжные системы).
4. Нефункциональные требования: нагрузка, безопасность, аудит, отказоустойчивость.
5. Релизный план: MVP → релиз 2 → релиз 3.

Практический вывод: если нет списка интеграций и нефункциональных требований, ваша оценка будет “дешёвой” ровно до первого разговора с безопасником или бухгалтерией.

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

Шаг 2. Выбор модели оценки: Time & Material vs Fixed Price

Time & Material (T&M) — платим за фактически потраченное время команды. Fixed Price — фиксируем цену за объём работ.

Практический вывод: фикс — не про экономию, а про перенос риска. Риск никуда не исчезает, он просто меняет прописку.

Шаг 3. Расчёт стоимости команды: ставка × загрузка × время

Тезис: основная статья затрат в большинстве проектов — люди.

В России (по рынку 2024–2026, вилки гуляют по регионам и компаниям) ориентиры по полной стоимости специалиста для проекта (не только «на руки», а с налогами/накладными у работодателя или маржой у подрядчика) часто считают так:

Практический вывод: «сделаем маленькой командой» работает, если у вас реально маленький периметр. Если периметр средний, маленькая команда просто растянет сроки — и итоговая стоимость догонит “нормальную”.

Подводный камень: считать людей на 100% загрузки. В реальности закладывайте 70–85%: созвоны, согласования, отпуска, инциденты.

Шаг 4. Сроки: оценка по объёму + буфер на неопределённость

Тезис: срок без буфера — это обещание, которое вы заранее планируете нарушить.

• Для MVP часто разумно закладывать 8–16 недель (если это не «госЕПГУ‑масштаб», а нормальный бизнес‑продукт).
• Буфер на риски: 15–30% к срокам/бюджету, если требования не цементные.

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

Шаг 5. Доходы/эффекты: откуда берётся окупаемость (ROI)

ROI (Return on Investment) — возврат инвестиций. В IT‑проектах эффекты обычно двух типов:

• Рост выручки: конверсия, средний чек, удержание, новые каналы продаж.
• Снижение затрат: меньше ручного труда, меньше ошибок, быстрее обработка заявок, меньше штрафов.

Формально: ROI = (Эффект − Затраты) / Затраты. Но важнее — честность допущений: откуда вы взяли цифру эффекта, почему она достижима, какой лаг до результата.

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

Два коротких кейса из жизни (чтобы было не “в теории”)

Кейс №1: «Сэкономили на аналитике — заплатили дважды»

Компания захотела внутреннюю систему согласования договоров с интеграцией в 1С. В смете срезали аналитика («да что там, формы и кнопки»). Через 2 месяца выяснилось, что нужны роли, маршруты согласования, журнал аудита, электронная подпись (КриптоПро), и ещё “маленькая” интеграция с архивом. Итог: +40% к бюджету, +2 месяца, и команда выгорела. Финансовая модель it‑проекта здесь спасла бы хотя бы тем, что вскрыла бы нефункциональные требования и стоимость владения до старта.

Кейс №2: «MVP, метрика, и внезапно проект стал дешевле»

Сервис для обработки заявок клиентов. Вместо большого “комбайна” сделали MVP: одна воронка, один канал входа, минимум интеграций. В финмодели заложили развитие по релизам и явную стоимость поддержки. Через 10 недель получили измеримый эффект: заявки стали обрабатываться быстрее, меньше потерь. На релиз 2 пошли уже из экономии времени сотрудников, а не из веры в светлое будущее. Не магия — просто нормальная финмодель и дисциплина периметра.

Скрытая цена: за что почти всегда забывают платить (а потом платят)

• Данные: миграция, чистка справочников, доступы, качество данных.
• Инфобез: требования ИБ, ПДн (персональные данные), журналы, аудит.
• Поддержка: 1–2 линия, регламенты, база знаний.
• Релизы: тестовые контуры, CI/CD (автоматизация сборки и деплоя), мониторинг.
• Управление: время бизнеса на согласования и приёмку (да, это тоже деньги).

Подводный камень: считать, что «всё это входит в разработку». Иногда входит. Но чаще — “входит” только в презентацию.

Экспертный вердикт и инструмент: мини‑чек‑лист, чтобы оценить it‑проект без гаданий

Если вам нужно быстро проверить, адекватна ли финмодель (ваша или подрядчика), задайте 7 вопросов. Это и есть практичный ответ на «финмодель it‑проекта: как оценить it‑проект, чтобы не остаться без штанов».

1. Что является MVP и какая метрика докажет, что он “взлетел”?
2. Какие интеграции точно в периметре? (1С/Битрикс24/СМС/платежи/Госуслуги — перечислить словами.)
3. Какие нефункциональные требования: нагрузка, доступность, безопасность, аудит?
4. Какая модель контракта и где лежит риск перерасхода (T&M или фикс)?
5. Из чего состоит TCO на 12–24 месяца: поддержка, инфраструктура, лицензии, развитие?
6. Какие допущения заложены в эффект/доход, и кто за них отвечает?
7. Есть ли стресс‑сценарий: +20% задач, −1 ключевой человек, задержка интеграции?

Если на половину вопросов ответы уровня «ну как обычно» — это не финмодель, а успокоительное. Больше практических разборов и шаблонов, которые можно утащить в свой проект, я складываю здесь: https://itokno.ru.

Частые вопросы