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

Почему сметы часто идут не так

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

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

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

Урон проявляется позже, а не в первый день. Через пару недель после запуска клиент просит небольшие изменения, дополнительную поддержку или обработку крайних случаев, о которых в смете никто не говорил. Каждый запрос сам по себе кажется разумным. Вместе они превращают здоровый проект в медленную утечку денег.

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

Oleg Sotnikov часто видит такой сценарий в работе Fractional CTO со стартапами. Команда выигрывает кастомную сделку, быстро запускает решение, а потом месяцами поддерживает код, который помогает одному клиенту и замедляет всех остальных. Проблема была не в поставке. Проблема была в смете. В ней смешали инвестиции в продукт и работу под клиента, будто это одно и то же.

Разделите продуктовую работу и работу под клиента

Прежде чем кто-то начнёт считать часы, разложите все задачи по двум корзинам.

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

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

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

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

Работает простое правило:

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

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

Четыре вопроса до оценки

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

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

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

В-третьих, можно ли переиспользовать больше, чем просто код? Повторно использоваться могут тесты, UI-паттерны, шаги развёртывания, документация для поддержки и процесс, который команда повторит в следующий раз. Функция может звучать кастомно, но потом превратиться в переиспользуемый модуль. И наоборот: функция может казаться общей, но затем создать длинный хвост из особой поддержки и ручных исправлений.

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

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

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

Превратите ответы в правила ценообразования

Само правило должно оставаться простым: клиент платит за работу, которая появилась из-за него, а компания — за работу, которую она и так хотела бы делать.

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

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

Смешанные задачи нужно делить по-настоящему, а не «на глаз». Если интеграция занимает 6 часов из-за странного сопоставления полей одного клиента и ещё 14 часов уходит на улучшение общего импортного движка, выставляйте счёт за 6 клиентских часов, а 14 продуктовых часов оплачивайте изнутри. Ни одно разделение не идеально, но это намного лучше, чем спорить об этом после срыва сроков.

Помогает простой шаблон ценообразования:

• Работа только под клиента: 100% в счёт клиента.
• Работа для дорожной карты: оплата из продуктового бюджета.
• Смешанная работа: разделить часы до отправки сметы.
• Неясная работа: сначала продать короткий этап discovery или заложить запас.

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

Добавьте понятный запас — часто 15–30% — или ограничьте первый этап discovery и пересчитайте стоимость, когда неизвестных не останется. Клиенты обычно соглашаются, если вы ясно объясняете логику: они платят за то, что уникально для них, а вы инвестируете в части, которые улучшают продукт для всех остальных.

Сделайте смету, которую клиент сможет понять

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

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

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

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

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

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

Именно здесь основателям часто помогает внешний специалист. Чистая структура сметы кажется простой, но нужна дисциплина, когда сделка уже идёт и все хотят сказать «да».

Пример из раннего стартапа

Небольшой SaaS-стартап продавал инструменты для управления запасами независимым магазинам. Один магазин попросил кастомный процесс учёта: загрузку таблиц поставщиков, сопоставление старых форматов SKU и ночную отправку обновлений остатков на дашборд.

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

После короткого разбора разделение стало понятнее. Общий импортный движок был продуктовой работой. Он разбирал кривые CSV-файлы, сопоставлял столбцы, находил битые строки и сохранял правила импорта, которыми потом смогли бы пользоваться и будущие клиенты. Необычный еженедельный отчёт о потерях запасов был работой под клиента, потому что никому другому такой формат не был нужен. Настройка и тестирование на примерах файлов этого магазина тоже относились к клиентской работе.

Цифры быстро изменились. На импортный движок ушло около 70 часов. На кастомный отчёт и настройку — 18 часов. Если бы стартап выставил магазину счёт за все 88 часов, смета вышла бы слишком высокой и отпугнула бы клиента.

Когда команда разделила работу, 18 клиентских часов оформили как услуги, а 70 продуктовых часов вернули в дорожную карту. Новое предложение стало легче защищать. Магазин платил за отчёт, настройку и работу, связанную именно с его процессом. Стартап сам оплатил импортный движок, потому что рассчитывал использовать его в будущих сделках.

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

Вот в этот момент и защищается маржа. Клиент платит за то, что нужно только ему. Ваша компания финансирует то, что планирует продавать снова.

Ошибки, которые убивают маржу

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

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

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

Третья ошибка — бесконечная поддержка. Основатель говорит: «Мы какое-то время будем закрывать мелкие исправления». Клиент слышит постоянный доступ. Инженеры слышат случайные отвлечения на месяцы вперёд. У поддержки должен быть стоп-сигнал: сколько она длится, что считается багом, как быстро вы отвечаете и что превращается в новую оплачиваемую работу.

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

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

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

Проверьте предложение перед отправкой

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

Перед отправкой сделайте короткую проверку:

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

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

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

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

Что делать со следующей сделкой

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

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

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

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

Если объём работ всё ещё кажется туманным, попросите ещё одну пару глаз до того, как вы на что-то согласитесь. Oleg Sotnikov на oleg.is работает со стартапами над архитектурой, поставкой и поддержкой Fractional CTO, и именно в такой проверке сметы часто всплывает скрытая кастомная работа ещё до того, как её оценят слишком дёшево.

Сделайте это один раз на реальной сделке. Живая смета заставляет принимать чёткие решения, а чёткие решения защищают маржу.