Кастомизация опасна не сама по себе, а тем, что её стоимость платится не в момент продажи, а через два года — при каждом обновлении, каждой миграции и каждом уходе разработчика, который её писал. Решение принимается по трём осям: обобщается ли требование, кто платит за поддержку и где физически живёт код. Если требование не обобщается, поддержку никто не оплачивает, а код лежит в основной ветке — соглашаться нельзя ни за какие деньги.
Три вида доработки, которые путают между собой
| Вид | Где живёт | Кто платит за поддержку | Когда уместно |
|---|---|---|---|
| Настройка | В продукте, через интерфейс или конфиг | Никто, это штатная функция | Всегда — к этому и надо стремиться |
| Расширение | Отдельный модуль или интеграция на публичных точках подключения | Заказчик или партнёр, разово и за обновления | Требование специфичное, но продукт его допускает |
| Форк | Изменённая копия основного кода | Вы, вечно, и дороже, чем думаете | Практически никогда |
Большинство споров возникает потому, что продажа обещает «настройку», разработка слышит «расширение», а в итоге получается форк.
Порядок принятия решения
- Перевести требование в задачу. Заказчик просит поле в карточке — выясните, что он с этим полем собирается делать. В половине случаев задача решается уже имеющимися средствами, просто про них не рассказали на демонстрации.
- Проверить обобщаемость. Спросите себя: продадим ли мы это следующим трём клиентам как преимущество? Если да — это продукт, и платить за него разработкой нормально.
- Посчитать стоимость владения, а не разработки. К оценке разработки прибавьте сопровождение при каждом релизе на горизонте трёх лет. Обычно это удваивает цифру.
- Выбрать место в архитектуре. Публичная точка подключения — расширение, приемлемо. Правка ядра — форк, отказ.
- Оформить деньгами. Разовая оплата не покрывает сопровождение. Либо доработка входит в продукт и оплачивается подпиской всех, либо у неё есть отдельная строка обслуживания.
- Записать решение. Кто попросил, что решили, почему, кто платит. Через год этот список — самый ценный документ при планировании версии.
Практическое правило для узкого рынка: доля выручки от одного заказчика выше тридцати процентов означает, что вы уже не продуктовая компания, а подрядчик этого заказчика. Это не приговор, но модель другая — и цены, и договор, и планирование строятся иначе.
Как отказывать, не теряя сделку
Отказ проходит легче, когда вместо «мы этого не делаем» звучит альтернатива и срок. Три формулировки, которые работают:
- Обходной путь сейчас, продукт потом. «Сегодня это решается вот так — не идеально, но работает. В плане на следующий квартал стоит нормальная поддержка, покажем в бета-версии.»
- Отдельный проект с ценой. «Мы это сделаем, но это работа, а не настройка. Оценка — столько-то, сопровождение — столько-то в год. Решайте, стоит ли.»
- Честная граница. «Мы этого делать не будем, потому что это ломает продукт для остальных. Если это критично — вам нужен другой класс решения, и мы скажем какой.»
Третья формулировка теряет часть сделок и сохраняет продукт. На дистанции она выгоднее.
Что смотреть в договоре
Доработка под заказчика почти всегда всплывает в юридической части, и там обычно и происходит потеря денег.
- Кому принадлежит результат. Если права на доработку уходят заказчику, вы не сможете продать её следующему. Формулировка «исключительные права заказчику» на модуль продукта — типичная и дорогая ошибка.
- Обязательство по срокам. Дата в договоре превращает продуктовую задачу в неустойку.
- Условия обновления. Кто и за чей счёт переносит доработку на новую версию — это надо назвать до подписания, а не через полтора года.
Связанное
- Управление жизненным циклом продукта
- Ценообразование и упаковка
- Модель Кано
- Роль: руководитель внедрения
- Роль: пресейл
Три вопроса до согласия: обобщается ли требование, кто платит за сопровождение, где живёт код. Настройка — да, расширение — за деньги и с условиями, форк — нет.
Материал обновлён 30 сентября 2026