Почему в SaaS я сначала разбираю самое дорогое исключение, а не список новых функций

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

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

Исключение важнее громкой функции

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

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

О том, почему продукт стоит начинать с задачи, а не с кода, я уже писал в статье «Почему хороший IT-продукт начинается не с кода». После запуска принцип остаётся тем же. Меняется только источник наблюдений: вместо гипотез появляются реальные обходные маршруты.

Как отличить дорогую проблему от просто неприятной

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

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

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

Не торопиться с решением — не значит откладывать

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

Это похоже на ремонт в квартире. Если в коридоре постоянно не хватает места, можно купить ещё один шкаф. Но сначала полезно понять, что именно там скапливается: обувь, куртки, коробки или вещи, которым вообще не место в коридоре. Иначе новый шкаф просто унаследует старый беспорядок.

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

Составной пример: особая цена не помещается в обычный заказ

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

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

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

Что я проверяю перед тем, как ставить задачу в развитие

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

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

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

Изменение должно быть заметно в ежедневной работе

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

Переход из пилота в ежедневную работу я разбирал отдельно в статье «Как перевести IT-продукт из пилота в ежедневную работу». Здесь логика похожая: продукт живёт не в презентации и не в списке возможностей, а в повторяющемся действии человека.

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

С чего начать завтра

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

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

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

Кому показывать находку до разработки

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

Я бы принёс на такую встречу один короткий сценарий, а не презентацию с десятком экранов. Вот пользователь, вот его цель, вот точка, где он выходит из сервиса, вот что делает потом. Затем стоит спросить: это действительно повторяется? Какие данные в этот момент недоступны или вызывают сомнение? Как выглядит хороший результат для человека, который будет делать работу завтра утром?

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

Почему нельзя строить решение только для одного «сложного клиента»

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

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

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

Не терять голос поддержки

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

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