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

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

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

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

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

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

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

Хорошая проверка — следующий общий запрос. Допустим, теперь принятую работу разрешено возвращать на доработку. Кто вправе сделать это в каждом варианте? Что произойдёт во внешней системе? Как показать историю? Если ответы требуют отдельного исследования для каждого клиента, эту стоимость нужно учитывать при продаже.

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

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

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

Полная статья: https://labs.arktelos.dev/ru/articles/one-product-many-clients/

ArkTelos: https://arktelos.dev/ru Журнал: https://labs.arktelos.dev/ru Версия EN: https://labs.arktelos.dev/en/articles/one-product-many-clients/ Lab RU: https://t.me/arktelos_lab_ru Lab EN: https://t.me/arktelos_lab ArkTelos RU: https://t.me/arktelos_ru ArkTelos EN: https://t.me/arktelos