Почему IT-компании продают часы, хотя клиент покупает результат

Заказная разработка привыкла продавать специалистов, ставки и количество часов. Это удобно для расчётов, договоров и управления производством. Но клиент приходит не за часами разработчика. Ему нужно запустить продукт, увеличить выручку, сократить издержки, проверить гипотезу или решить другую конкретную бизнес-задачу.

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

В подтексте это часто звучит примерно так:

«Мы вам и так даём крутую выделенную команду. Что вы ещё от нас хотите?»

Это сарказм, но он довольно точно отражает действительность.

Коротко

• Часы — нормальная единица расчёта, но слабый sales point.
• Клиент оценивает не только ставку. Он пытается понять, какой подрядчик глубже разобрался в задаче, предложил более разумный путь к цели и способен снизить риски проекта.
• Чем меньше продавец понимает бизнес-задачу, тем быстрее разговор сводится к стоимости часа.
• Сильный пресейл соединяет коммерцию, аналитику, производство и понимание предметной области.
• Продажа ценности начинается не с обещаний роста выручки, а с ясной логики: что мы меняем, зачем это делаем, как проверим результат и где заканчивается наша ответственность.

Содержание

1. Почему рынок привык продавать часы
2. Что на самом деле покупает клиент
3. Почему поставщики становятся взаимозаменяемыми
4. Как выглядит сильный пресейл
5. Как перестроить продажу и коммерческое предложение

Почему рынок привык продавать часы

Заказная разработка исторически строится вокруг ресурсов.

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

В этом нет ничего плохого.

Хотя некоторые убеждены, что договор T&M автоматически отпускает все грехи. Не отпускает.

Проблема начинается в тот момент, когда внутренняя производственная логика без изменений переносится во внешний разговор с клиентом.

Коммерческое предложение превращается в таблицу:

• аналитик — столько-то часов;
• дизайнер — столько-то;
• разработчик — столько-то;
• тестировщик — столько-то;
• итоговая стоимость — такая-то.

Компания хорошо объяснила, из чего состоит стоимость её предложения, но практически ничего не сказала о том, почему клиенту следует купить именно её.

В результате поставщики выглядят одинаково. У всех есть аналитики, разработчики, контроль качества, Scrum — прости господи, — Git, CI/CD и опытная команда.

После этого заказчику остаётся сравнивать то, что сравнить проще всего: ставку часа и общую стоимость.

Так IT-компания становится очередным безликим подрядчиком в длинной сравнительной таблице.

Что на самом деле покупает клиент

Формально предметом договора действительно могут быть работы, услуги или выделенная команда. Но бизнес-задача почти всегда находится уровнем выше.

Клиент может хотеть:

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

Клиент покупает не разработчика на 160 часов. Он покупает изменение своего текущего положения.

Разработка — это способ добиться этого изменения.

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

Сильная продажа начинается с нескольких вопросов.

Зачем проект нужен бизнесу

Что стало причиной запроса именно сейчас? Почему компания не может оставить всё как есть? Какова стратегия этого цифрового продукта?

Без ответа на эти вопросы невозможно понять, что именно нужно разрабатывать и почему выбранное решение вообще имеет смысл.

Кто заинтересован в результате

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

У каждого из них свои критерии:

• бизнес ожидает экономического эффекта;
• IT оценивает архитектуру и безопасность;
• пользователи хотят удобный инструмент;
• закупки сравнивают условия;
• руководитель проекта боится сорвать срок, не выполнить личный KPI, затормозить свой карьерный трек и остаться без годовой премии.

Предложение, написанное только для одного участника, может проиграть внутри организации клиента.

Как выглядит успех

Фраза «запустить приложение» недостаточна.

Запустить к какой дате? Для какой аудитории? С каким набором функций? Что будет считаться успешной проверкой? Какие показатели должны измениться? Что произойдёт после пилота?

Чем яснее критерий успеха, тем точнее можно определить первый этап и попасть в ожидания.

Это важно, потому что можно полгода разрабатывать два разных продукта: вы — один, как вы его понимаете, а заказчик — другой, как его понимает он.

Нетрудно догадаться, что будет в конце.

Что произойдёт в случае ошибки

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

Срыв срока может привести к репутационному ущербу. Ошибка в интеграции — остановить операционный процесс. Неудачный запуск — уничтожить доверие к инициативе внутри компании.

Понимание цены ошибки меняет и архитектуру решения, и уровень контроля, и необходимый состав команды.

Почему поставщики становятся взаимозаменяемыми

Я много лет работал в заказной разработке и видел один и тот же сценарий.

Клиент присылает запрос. Продавец быстро уточняет стек, примерный функционал, сроки и бюджет. Затем передаёт задачу производству, получает оценку и возвращается с предложением.

Снаружи процесс выглядит организованным. Но в нём пропущен главный вопрос:

Что должно измениться в бизнесе клиента после завершения проекта?

Без ответа на него компания не может обосновать ни архитектурное решение, ни состав команды, ни этапность, ни бюджет.

Она может только сказать:

«Мы сделаем перечисленные функции за такое количество часов».

После этого заказчик закономерно спрашивает:

«А почему у другой компании час стоит меньше?»

И это не всегда попытка торговаться. Часто поставщик просто не дал клиенту других оснований для сравнения.

На зрелых B2B-продажах клиент оценивает не только стоимость производства.

Он оценивает:

• вероятность уложиться в срок;
• качество управления;
• способность команды увидеть проблему заранее;
• глубину понимания отрасли;
• стоимость возможной ошибки;
• способность поставщика говорить с бизнесом на его языке;
• объём времени, который придётся потратить самому заказчику.

Компания с более высокой ставкой может оказаться экономически выгоднее, если она:

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

И ДАЖЕ ОТКАЖЕТСЯ ОТ ПРОЕКТА, ЕСЛИ УВИДИТ, ЧТО ОН НЕЖИЗНЕСПОСОБЕН.

Высокая ставка не гарантирует качества. Но и более низкая ставка сама по себе не означает экономии.

Клиенту важна не минимальная стоимость единицы ресурса, а совокупная стоимость достижения цели — вместе со сроками, рисками и последствиями неверных решений.

Как выглядит сильный пресейл

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

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

В пресейл могли включаться:

• бизнес-аналитик;
• руководитель проектов;
• технический директор;
• руководители разработки;
• дизайнер или арт-директор;
• специалисты по отдельным платформам и технологиям.

Это не означает, что вся команда должна участвовать в каждом звонке. Состав зависит от задачи.

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

Хороший пресейл помогает ответить на вопросы:

• действительно ли клиенту нужен заявленный объём;
• что необходимо сделать на первом этапе;
• какие зависимости могут сорвать запуск;
• какие решения можно отложить;
• где находится основная техническая неопределённость;
• какие данные потребуются;
• кто со стороны клиента должен участвовать в работе;
• как проверить гипотезу с меньшими затратами.

Именно здесь IT-компания перестаёт продавать руки и начинает продавать способность разобраться в задаче.

При этом ценность — это не красивое слово, которое можно написать поверх обычной сметы.

Она появляется, когда поставщик способен:

• показать причинно-следственную связь между решением и задачей бизнеса;
• разделить факты, предположения и неизвестные;
• предложить способ проверки гипотезы;
• назвать риски;
• обозначить границы ответственности;
• определить измеримый результат конкретного этапа.

Подрядчик не всегда может гарантировать рост продаж. Он не управляет маркетингом, поведением пользователей, продуктовой стратегией клиента и десятками внешних факторов.

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

Это уже не продажа часов. Это продажа управляемого шага к результату.

Как перестроить продажу и коммерческое предложение

Хорошее коммерческое предложение не должно начинаться с рассказа о компании.

Сначала клиент должен увидеть, что его поняли.

1. Контекст и стратегия

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

2. Первый измеримый результат

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

Первым результатом может быть:

• исследование;
• прототип;
• пилот;
• MVP;
• интеграционный контур;
• автоматизация одного процесса;
• запуск на ограниченной группе пользователей.

3. Логика решения

Объяснить, почему выбран именно такой путь, а не просто перечислить функции.

Что мы проверяем? Почему начинаем именно с этого этапа? Что станет понятно после его завершения?

4. Риски, зависимости и критерии успеха

Показать, какие данные, специалисты, доступы и решения потребуются со стороны заказчика.

Зафиксировать, что именно будет считаться выполненной работой и по каким признакам обе стороны поймут, что этап завершён успешно.

Это не ослабляет предложение. Наоборот, демонстрирует зрелость.

5. Команда, сроки и стоимость

И только после этого имеет смысл показывать роли, сроки, часы и бюджет.

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

Когда компания начинает глубже разбираться в задачах клиента, меняется не только презентация.

Меняется вся коммерческая система.

Продавцы учатся квалифицировать запросы и отказываться от неподходящих проектов. Производство раньше включается в проверку решений. Клиент видит в подрядчике не очередной источник разработчиков, а команду, способную участвовать в принятии решений.

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

• средняя ставка часа выросла примерно на 40%;
• средний срок жизни клиента увеличился с девяти до восемнадцати месяцев;
• нас постепенно перестали воспринимать исключительно как мобильную студию и начали приглашать в более широкие IT-задачи.

Эти результаты появились не из-за одной новой презентации или удачной формулировки.

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

Итог

Часы никуда не исчезнут из заказной разработки. Они нужны для оценки, планирования, контроля загрузки и расчёта себестоимости.

Но клиент не обязан покупать внутреннюю систему учёта подрядчика.

Он покупает движение из текущей точки в желаемую: запуск, проверку, автоматизацию, снижение риска или изменение бизнес-показателя.

Поэтому зрелая IT-компания умеет делать две вещи одновременно:

• внутри считать работу в часах;
• снаружи объяснять её через ценность, результат и управляемость.

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