Недавно под одной из моих статей на Habr разгорелся спор («Как малому бизнесу автоматизировать продажи с минимальными вложениями на базе 1С»). Один читатель отметил, что за решение типовой задачи по 1С франчайзи запросил 4000 рублей в час, тогда как в другой облачной системе аналогичное действие обошлось бы в 500 рублей. Другой участник дискуссии возразил свое мнение касательно озвученной проблеме:
“Вы действительно считаете, что если задача решается за 5 минут, она должна стоить 333 рубля? Это как у врача: зашёл, получил диагноз за минуту, но платишь всё равно за приём”.

Этот пример оказался показательной иллюстрацией куда более широкой и глубокой темы: Должна ли стоимость ИТ‑услуг определяться временем, трудоёмкостью, квалификацией или ценностью результата?

Историческая модель: «часы = деньги»

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

Однако с ростом зрелости отрасли и распространением узкой экспертизы этот подход начинает давать сбои. Почему я так считаю?

Потому что часы не отражают ценность.

Простая иллюстрация: две команды, один результат

Предположим, перед компанией стоит задача интеграции с внешней системой.
• Команда А из трёх человек без профильного опыта берёт 1500 ₽/час, работает 30 часов.
• Команда B из одного эксперта берёт 6000 ₽/час и справляется за 5 часов.

Обе команды решают задачу. Но первая стоит 45 000 ₽, а вторая — 30 000 ₽. При этом:

• во втором случае меньше рисков,

• выше уверенность в результате,

• лучше качество кода и архитектурные решения.

Вопрос: почему в первом случае это кажется «нормальным», а во втором — «дорогим»?

Парадокс......: за скорость в наших реалиях наказывают!

Часто наблюдаемая ситуация:
опытный специалист за счёт глубокой экспертизы и гибкого мышления в предметной области решает проблему за 10–15 минут. Заказчик видит счёт за «0.25 часа» по высокой ставке — и испытывает диссонанс. «Разве 15 минут работы могут стоить 2000 рублей?»

Но именно этот специалист:
а. Быстро нашёл суть проблемы,
б. Избежал лишних проверок,
В. Дал результат с минимальным риском.

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

И здесь у меня возникает вопрос к модели оценки: мы платим за время или за устранение проблемы?

Попытаюсь формализовать проблему

Можно попробовать представить это в виде уравнения:

Стоимость услуги = Время × Ставка = f(Опыт, Сложность, Риски, Надёжность, Ценность результата)

Где:
а. Опыт влияет на ставку,
б. Сложность влияет на необходимое время,
в. Риски определяют ценность правильного выполнения,
г. Ценность результата — это влияние решения на бизнес.

Такое представление ближе к реальности, чем просто «часы × ставка». Но оно требует зрелости с обеих сторон:
— заказчику нужно понимать, за что он платит,
— исполнителю — аргументировать подход и результат.

Разберем теперь позиции обеих сторон

Я намеренно собрал мнения из разных обсуждений на форумах и в профессиональных чатах. Ниже представлены два полярных взгляда.

Позиция 1: опыт должен стоить дороже, потому что он даёт эффективность

«Если человек решает задачу за 10 минут благодаря 10 годам опыта, он должен получать больше, а не меньше. Это не „быстрое выполнение“, это капитализация знаний.»

Позиция 2: важно учитывать трудозатраты и трудоёмкость

«Стоимость должна быть результатом оценки времени и сложности. Если задача простая — вне зависимости от того, сколько опыта у исполнителя — её не нужно переоценивать.»

Как по мне эти обе позиции имеют рациональное обоснование. И проблема как раз таки возникает тогда, когда стороны используют разные модели оценки и не договариваются на старте проекта.

Но можно использовать и «Альтернативный подход»: оплата за результат

Некоторые компании и подрядчики переходят на модель оплаты за результат, а не часы. В этой модели:
а. Составляется техническое задание,
б. Фиксируется итоговая цель (например, рабочая интеграция, реализованная фича),
в. Устанавливается стоимость, не зависящая напрямую от времени + нужно учесть иные факторы (изменение ТЗ, в процессе анализа можно выявить подводные камни реализации задачи и тд.).

Плюсы этой модели такие:
а. Ясность для обеих сторон,
б. Предсказуемый бюджет,
в. неважно, кто и как быстро выполняет.

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

А теперь о моем подходе в работе

Как человек, который регулярно работает на стыке бизнеса и ИТ, я часто предлагаю комбинированную модель:

1. крупные блоки оцениваются как результат,

2. мелкие доработки — по времени, с шагом 15 или 30 минут,

3. всё, что требует отдельного проектирования — обсуждается индивидуально.

Такой подход позволяет сохранить гибкость, не отпугнуть клиента ценой «за 15 минут», при этом не демпинговать экспертную работу.

Подводя итоги

ИТ‑отрасли пора выйти за рамки модели «цена = часы × ставка». Опыт и системность специалиста часто позволяют сэкономить десятки часов другим. Это не повод платить меньше — это повод задуматься, что именно мы покупаем?: время или результат.

Со стороны исполнителя, на мой взгляд, зрелая ИТ‑команда (внутренняя или внешняя) должна:

• уметь аргументировать свою ставку и подход к ценообразованию,

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

• уходить от скрытых ожиданий и «интуитивного» представления о справедливости.

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

Если у вас был опыт, когда высокая ставка оказалась выгоднее, или наоборот — дешёвый подрядчик стал дорогим из‑за переделок — напишите в комментариях. Хочу собрать практические кейсы и мнения в продолжение темы.

Матфей Майоров Аналитик 1С / Telegram: @MayorovMatfey
Поддержи мой канал, если тема была полезна: t.me/MayorovMatfey