Как клиентские доработки превращаются в продуктовый долг в B2B-SaaS
Причем на этапе согласования такая доработка чаще выглядит как ограниченное изменение. А вот уже после запуска она становится частью продукта, а значит ее нужно поддерживать, тестировать, документировать и учитывать в следующих релизах
Долг раскрывается не сразу
Технический долг обычно описывают как будущую стоимость быстрых или неоптимальных решений. В SaaS-продукте он возникает не только в коде. Клиентская доработка может затронуть продуктовую логику, интерфейс, роли пользователей, тарифы, договоренности с клиентом, работу поддержки, аналитику, документацию и внедрение
Сама по себе разработка — это только первый этап. Дальше появляются регулярные расходы, типа проверка сценария при обновлениях, поддержка нестандартного поведения, обучение продаж и поддержки, обновление инструкций, сопровождение интеграций, настройка событий аналитики и контроль совместимости с новыми функциями
Еще сжатые сроки сделки/внедрения часто приводят к коротким техническим путям: хардкод, ручные операции, временные обходы, слабая документация, минимальные тесты, отдельная логика без связи с общей моделью продукта. Такие решения могут пройти приемку, но создают ограничения для следующих изменений. Проблемы вылезут при обновлении интерфейса, переработке прав, изменении тарифа, миграции данных, развитии API или запуске новой функции поверх старой доработки
Продуктовый долг виден не по самому факту кастомизации, а по последствиям. Если доработка требует отдельных регрессионных проверок, инструкций, условий в поддержке, объяснения продажам и учета при релизах, она прямо влияет на стоимость развития продукта
Про исключения из стандартной модели продукта
Долг быстрее растет, если доработка сделана как исключение из базовой модели. К таким исключениям относятся отдельное правило для конкретного клиента, ручная настройка, нестандартная роль, особое условие в тарифе, индивидуальный отчет, отдельная логика доступа или интеграция, которая не укладывается в общую архитектуру
Перед отдельной разработкой стоит внимательно проверить, можно ли закрыть запрос существующими механизмами продукта: настройкой, ролями, правами, шаблонами, параметрами, API, интеграцией или готовым модулем. Поддерживаемость системы тесно связана с использованием стандартной функциональности там, где это возможно. Кастомизация должна расширять или адаптировать возможности продукта, а не дублировать то, что уже можно решить штатными средствами
Статус доработки должен быть одинаково понятен всем участникам
Костыльные решения несут тем больше риска, чем хуже зафиксированы статус, владелец, ограничения и правила поддержки. Участники процесса могут понимать одну и ту же доработку по-разному: клиент — как постоянную возможность продукта, продажи — как аргумент для новых сделок, разработка — как частное исключение, поддержка — как еще один сценарий обращений. И это в лучшем случае! В худшем — половина из перечисленных вообще будут не в курсе
В кастомизации могут участвовать клиент, продажи, продукт, разработка, внедрение, поддержка, безопасность, юристы и закупки. У каждой стороны свой критерий результата: закрытая сделка, срок внедрения, архитектурная устойчивость, безопасность, обязательства, нагрузка на сопровождение. Если статус решения не зафиксирован, значит, доработка живет через переписки, устные договоренности и знания отдельных сотрудников — сами понимаете, чем это грозит
Аналитика должна подтвердить ценность доработки
Отдельный риск — отсутствие данных по использованию. В отчете одной зарубежной компании я наткнулся на интересную статистику, что 12% функций генерируют 80% среднего ежедневного использования, а 80% функций используются редко или никогда. В бенчмарках последних 2 лет я и сам вижу, что небольшая доля функций получает основную часть кликов
Факт оплаченного или согласованного запроса не подтверждает, что функция будет регулярно использоваться после запуска. Как ранее писал, для любой функции нужны данные: кто ей пользуется, как часто, в каких ролях, доходит ли пользователь до целевого действия и влияет ли функция на удержание, расширение тарифа, снижение обращений или скорость клиентского сценария. С кастомными фишками это все сохраняет актуальность в полной мере
Редфлаги технического/продуктового долга
Кастомизация становится долгом, когда клиентская доработка начинает жить отдельно от стандартной модели продукта и усложняет дальнейшие изменения
Основные признаки:
- В коде или настройках появляются клиентские исключения. Логика работает по отдельным условиям для конкретного клиента, договора, тарифа, роли, региона или интеграции
- Сценарий нельзя масштабировать на других клиентов без переработки. Доработка решает частный процесс, но не превращается в универсальную настройку, модуль, параметр или стандартную функцию
- Кастомизация обходит штатные механизмы продукта. Вместо существующих ролей, прав, шаблонов, API или настроек появляется отдельная логика, которая работает параллельно основной системе
- Изменения в базовом продукте требуют проверки клиентского исключения. При обновлениях чего бы то ни было нужно отдельно проверять, не сломался ли кастомный сценарий
- Поддержка сценария зависит от контекста конкретной сделки. Чтобы разобраться в поведении функции, нужно поднимать переписки, условия допок, старые задачи или уточнять детали у сотрудников, которые участвовали во внедрении
- Кастомная логика создает отдельную ветку сопровождения. Для нее нужны отдельные инструкции, проверки, ограничения или маршруты эскалации, которые не подходят к остальным клиентам
- Клиентское исключение нельзя безопасно удалить или изменить. Неясно, кто и как использует доработку, какие обязательства с ней связаны и что сломается при ее отключении
- Похожие запросы нельзя закрыть тем же решением. Если следующий клиент просит похожую возможность, но команда снова вынуждена делать отдельную доработку, значит решение не стало универсальным продуктовым механизмом