Я не обещаю функцию для одного клиента, пока не вижу правило для продукта

Просьба важного клиента добавить в SaaS отдельную функцию почти всегда звучит убедительно. Клиент платит, хорошо знает свой процесс и говорит конкретно: «Нам не хватает вот этого шага». Самый простой ответ — пообещать. Я стараюсь так не делать, пока не понимаю, какое правило для продукта скрывается за этой просьбой.

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

Сначала отделяю задачу от предложенного решения

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

Я спрашиваю: какое решение сотрудник сейчас не может принять? На каком шаге он останавливается? Что делает вручную, пока функции нет? Что случится, если ничего не менять ещё месяц? Иногда за запросом на новый статус стоит реальная потребность видеть, кто ждёт решения. Тогда проблема может быть общей. А иногда новый статус нужен, чтобы сохранить привычную таблицу одного отдела. В таком случае отдельный статус только закрепит обходной путь.

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

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

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

Поэтому я прогоняю запрос через три простых вопроса.

• Сможет ли этим сценарием воспользоваться другой клиент без отдельной настройки и обучения?
• Станет ли понятнее базовый процесс или появится ещё одно правило, которое надо помнить?
• Что перестанет работать или станет сложнее, если через год таких исключений будет десять?

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

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

Не всякая индивидуальность — проблема

Иногда команда, защищая «единый продукт», начинает отказываться от всего нестандартного. Это другая крайность. У компаний правда отличаются роли, порядок согласования, документы и ответственность. SaaS не обязан заставлять всех жить под одну линейку.

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

Я предпочитаю сначала искать настройку, которая честно описывает различие. Например, не добавлять клиенту персональную кнопку «передать на повторное согласование», а дать управляемое правило: при каких условиях заявка возвращается и кому. Тогда команда может проверить логику, а клиент — получить нужный маршрут без тайного исключения в коде.

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

Даю запросу шанс доказать себя

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

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

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

Смотрю на запрос в контексте всего маршрута

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

В такой прогулке часто находится более простое решение. Запрос на «особый экран» превращается в понятную подборку существующих данных. Просьба об отдельной интеграции — в корректное правило экспорта. А бывает наоборот: команда видит, что продукт действительно не умеет поддержать важный тип работы. Тогда просьба одного клиента становится хорошей отправной точкой, но не готовым описанием функции.

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

Обсуждаю не только ценность, но и дальнейшую ответственность

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

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

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

Когда индивидуальная работа честнее общей функции

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

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

Что сказать клиенту без лишней обороны

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

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

Короткий вывод

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