Снова про Saas: поэтапно оцениваем кастомный запрос до старта разработки
Любые кастомные запросы в саасах нельзя оценивать лишь по часам разработки
В оценку еще входят дальнейшая поддержка, тестирование, документация, аналитика, обучение внутренних команд, сопровождение клиента, влияние на архитектуру, тарифы, будущие релизы. Но лучше есть мамонта по частям, а именно:
Первый этап оценки — проверка уже имеющихся возможностей продукта. Потому что использовать стандартную функциональность вместо кастомной там, где это возможно — это прекрасно. Т.е. закрывается ли запрос настройкой, ролью, правами доступа, шаблоном, параметром, API, интеграцией или существующим модулем. Если некий механизм уже есть, то кастомизация должна быть реализована как расширение или адаптация, а не как дублирование существующей функции
Второй этап — описание клиентского сценария. Нужно зафиксировать, какой бизнес-процесс клиент хочет изменить, кто будет использовать функцию, кто принимает решение о внедрении, что за роли участвуют в настройке, какой результат должен быть достигнут
Третий этап — описание объема изменений. Кастомизация может затронуть интерфейс, модель данных, права доступа, интеграции, отчеты, тарифы, роли пользователей, настройки администратора, API, уведомления, документацию и процессы поддержки
Четвертый этап — расчет стоимости владения. По-хорошему, погашение технического долга завязано на все три столпа разработки: рефакторинг, отладку, поддержку. Для кастомизации это означает учет всех работ после запуска: исправления, консультации ТП, обновление инструкций, регрессионные тесты, сопровождение интеграций, проверка совместимости с новыми релизами
Пятый этап — согласование ожиданий между сторонами. И тут сильно роляют технические знания участников, коммуникация плюс мотивация. Поэтому особо важно до разработки фиксировать ограничения, ответственность, статус решения и критерии приемки
Шестой этап — определение бизнес-критериев. Приоритизация долга должна учитывать не только техническую оценку, но и бизнес-процессы, бизнес-ценность, влияние на активы компании, согласование между техническими и бизнес-стейкхолдерами.
До согласования кастомизации стоит зафиксировать:
- Клиентский сценарий, который нужно закрыть: что именно не работает в текущем продукте, какой результат нужен клиенту
- Почему стандартных возможностей недостаточно: все ли штатные настройки, роли, права, шаблоны, API, интеграции или модули уже проверили, почему они не закрывают задачу
- Тип решения на выбор: настройка, доработка существующего механизма, новый модуль, отдельная интеграция или клиентское исключение
- Что изменится в модели продукта: данные, права, роли, интерфейс, тарифная логика, API, отчеты или интеграции
- Ограничения: для каких клиентов, тарифов, ролей, данных, интеграций или сценариев оно работает, а где не применяется
- Стоимость действия и бездействия: что компания получает/теряет, если делает кастомизацию; что получает/теряет, если отказывается от нее или ищет обходной вариант
- Как будет проверяться использование после запуска: какие действия клиента покажут, что доработка действительно используется
- Статус решения: временное исключение, индивидуальная доработка для клиента, пилотная возможность, будущая стандартная функция или часть отдельного тарифа
А после запуска для кастомной доработки стоит заранее определить точку пересмотра: оставить как есть, доработать, перевести в базовую возможность (маловероятно, конечно), уточнить область применения, заменить настройкой или вывести из продукта. Хотя можно ограничиться просто последними двумя пунктами, но для поста я стараюсь охватить все варианты
И как ранее уже писал, но считаю важным повторить, значительная часть функций в ПО используется редко или никогда, а основное использование концентрируется в небольшой доле функций. Поэтому кастомный запрос должен будет проверяться в том числе поведением пользователей после запуска
Подытоживая:
- Оценка кастомизации до разработки должна покрывать стандартные возможности продукта, объем изменений, стоимость владения, согласование ожиданий, бизнес-критерии, аналитику использования и правила дальнейшего сопровождения
- Кастомизация, которая остается в продукте, должна иметь владельца, описание сценария, ограничения, документацию, правила поддержки, тестовые сценарии, события аналитики и дату пересмотра
Без этих элементов любая доработка будет неуправляемым исключением ака генератором рисков