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

Почему время на разработку скрывает реальную стоимость

Большинство оценок фичи заканчиваются на запуске. Это та часть, которую все видят: придумать, сделать, протестировать, выпустить. Дорогая часть начинается позже.

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

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

К обновлениям добавляется ещё один слой. Фича, которая отлично работала в первой версии, может сломаться, когда изменится продукт, сторонний API или схема базы данных. Даже если ничего не сломалось, кто-то всё равно должен проверить, что фича работает после каждого релиза.

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

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

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

Что нужно посчитать до согласия

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

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

• Сколько обращений в поддержку это создаст в обычный месяц?
• Какие части продукта, скорее всего, сломаются, если изменится приложение, API или зависимости?
• Понадобится ли кому-то вручную исправлять данные, заново запускать задачи, пересылать файлы или менять настройки?
• Кто будет владельцем фичи после запуска?
• Это короткое исключение или то, что компания может поддерживать годами?

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

Потом посмотрите на риск обновлений. Кастомная логика, связанная с экспортом, правами доступа, правилами биллинга, сторонними API или устаревшими клиентскими сценариями, часто ломается, когда меняется основной продукт. Если фича зависит от уязвимого участка системы, лучше сразу заложить время на поддержку, чем удивляться позже.

Ручная работа тоже заслуживает отдельной строки. Если кто-то должен перезапускать задачу, чистить плохие записи, проверять логи или вручную исправлять настройки, эта работа будет повторяться. Даже 30 минут в неделю — это примерно 26 часов в год.

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

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

Как оценивать поддержку шаг за шагом

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

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

Только после этого инженерия должна оценить время на разработку. Сначала держите эту цифру отдельно. Она должна покрывать проектирование, написание кода, тестирование и выпуск.

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

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

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

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

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

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

Используйте простую таблицу оценки

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

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

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

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

Допустим, кастомный отчёт получил средний уровень поддержки, хрупкий риск обновлений и редкую ручную работу. По таблице выше это будет 8 + 16 + 4 = 28 часов поддержки. Если ваша полная ставка — $120 в час, оценка поддержки составит $3,360. Поставьте это рядом со временем на разработку, а не ниже как второстепенную мысль.

Именно здесь многие команды ошибаются. Они называют 30 часов на разработку, выигрывают сделку, а потом только через время замечают, что фича потребует ещё 28 часов в течение года, чтобы продолжать работать и отвечать на тикеты. Фича казалась дешёвой. Это было не так.

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

Реальный пример: кастомный экспорт для одного клиента

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

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

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

Если считать только разработку, оценка может выглядеть так:

• Сделать логику экспорта: 8 часов
• Протестировать файл на примере данных: 2 часа
• Выпустить и провести внутреннюю проверку: 2 часа

Итого 12 часов. На вид недорого.

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

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

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

Теперь реальная стоимость выглядит так:

• Изменения формата после запуска: 6 часов
• Повторные проверки во время обычных релизов: 9 часов
• Тикеты поддержки и ручные исправления: 18 часов
• Ежемесячные проверки данных: 12 часов

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

Ошибки, которые команды допускают при оценке кастомной работы

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

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

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

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

Короткий список помогает заметить скрытую работу:

• Посчитайте ожидаемые тикеты поддержки за первые 90 дней.
• Добавьте время на будущие обновления и регрессионные проверки.
• Включите обучение, заметки для передачи и объяснения клиенту.
• Назначьте одного владельца после запуска.
• Поставьте дату пересмотра, чтобы сохранить фичу или убрать её.

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

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

Короткая проверка перед тем, как продажи дадут обещание

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

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

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

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

Следующая ловушка — проверка обновлений. Если фича затрагивает биллинг, отчёты, выход API, права доступа или экспорт, любое изменение продукта может её сломать. Это значит, что понадобятся время инженеров, время QA и иногда время customer success. Если сейчас это не посчитать, маржа по сделке — фикция.

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

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

Простое правило для одобрения

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

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

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

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

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

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

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

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

Это меняет и то, как продажи говорят «да». Хорошая передача между sales engineering — это не просто спецификация. Это общее понимание того, что команда будет нести в течение следующего года.

Если нужен внешний взгляд, Oleg Sotnikov на oleg.is помогает стартапам и небольшим компаниям точнее выстраивать этот участок передачи в рамках своей работы fractional CTO и advisory. Второе мнение бывает полезно, когда кастомная работа продолжает приносить сделки, но тихо выматывает команду потом.