Я считаю функцию частью продукта только после вопроса: какое решение она уберёт из переписки
Новую функцию легко защитить словами «клиенты постоянно об этом спрашивают». Но я считаю её частью продукта только после другого вопроса: какое решение она уберёт из ежедневной переписки? Если функция просто переносит тот же спор из чата на экран, продукт не становится полезнее. Он получает ещё одну кнопку и ещё один повод спросить: «А как здесь правильно?»
В B2B это особенно заметно. Люди редко приходят в систему ради самой системы. Они хотят закрыть заказ, согласовать цену, передать задачу, увидеть отклонение или не забыть обязательство. Всё, что не помогает принять такое решение яснее и быстрее, обычно живёт недолго.
Переписка — хороший, но коварный источник задач
Представим обычную ситуацию. Менеджер пишет в чат: «Можно ли отгрузить этому клиенту товар с отсрочкой?» Руководитель смотрит лимит, бухгалтер напоминает о просрочке, склад уточняет резерв. В ответе есть решение, но его логика осталась в головах трёх людей и в переписке, которую завтра никто не найдёт.
Первый соблазн — добавить кнопку «Разрешить отсрочку». Она может быть правильной, но только если мы понимаем правило. Кто имеет право её нажать? Какие данные видит? Когда решение нужно пересмотреть? Что происходит с уже собранным заказом? Без ответов функция закрепляет не порядок, а случайный способ договориться.
Поэтому я не начинаю с экрана. Сначала разбираю одно повторяющееся сообщение до конца. Что стало поводом? Какие факты нужны для ответа? Кто несёт риск? Каким будет следующее действие? Это похоже на разбор узла на дороге: не надо сразу строить развязку, пока не ясно, кто и куда там поворачивает.
У хорошей функции есть снятое решение
Фраза «снять решение» не означает убрать человека из процесса. Часто решение остаётся за руководителем, но продукт собирает контекст и делает его видимым. Вместо пяти сообщений человек получает карточку: сумма, срок, история оплат, причина исключения и понятные варианты действия. Он всё ещё отвечает за выбор, но не собирает его вручную.
Я проверяю будущую функцию четырьмя вопросами.
- Какое решение повторяется? Не «нужен отчёт», а «руководитель каждую пятницу решает, кому дать дополнительный лимит».
- Что сегодня приходится искать или спрашивать? Если данных нет в системе, новый переключатель их не создаст.
- Как выглядит правильный следующий шаг? У решения должен быть результат: согласовано, отклонено, передано, отложено с причиной.
- Кому станет легче работать завтра утром? Не абстрактному рынку, а конкретной роли в конкретный момент.
Если на эти вопросы нельзя ответить коротко, функция пока не сформировалась. Это не провал. Иногда честнее оставить запрос заметкой и сначала посмотреть ещё несколько рабочих дней.
Не всякую переписку надо прятать в продукт
Есть решения редкие, дорогие или слишком неоднозначные. Например, разовый выбор поставщика для нестандартной поставки. Пытаться описать его десятком полей — значит сделать интерфейс тяжёлым и всё равно оставить людей в чате. Здесь продукту полезнее хранить контекст и результат, а обсуждение не имитировать.
Другая крайность — строить функцию под один громкий запрос. Один клиент может просить отдельный статус, потому что у него временный процесс. Если сделать его общим правилом, через полгода остальные пользователи будут обходить непонятное поле. В похожей ситуации важно отделить потребность от формулировки: клиенту нужен не «ещё один статус», а уверенность, что его исключение не потеряется.
Иногда достаточны заметка с причиной, напоминание и явный владелец. О том, почему настройка должна делать правило понятнее, а не просто расширять список опций, я уже писал в статье «Я добавляю настройку в продукт только там, где она делает правило понятнее».
Сначала наблюдение, потом обещание
Полезная привычка — не обещать функцию сразу после разговора. Я бы зафиксировал три-пять одинаковых эпизодов: кто начинает диалог, какие данные каждый раз всплывают, где появляется задержка, что люди делают в обход системы. Это не бюрократия. Так мы отличаем реальный повторяющийся сценарий от свежей эмоции после одного сложного дня.
Например, команда может просить «автоматическое согласование скидки». После наблюдения окажется, что 80% скидок одинаковы и укладываются в правило, а остальные 20% требуют осмысленного исключения. Тогда продукту не нужна кнопка «согласовать всё». Нужны прозрачное правило для обычных случаев и удобный маршрут для исключений.
Функция готова не в тот момент, когда макет выглядит убедительно. Скорее тогда, когда можно описать её на одном рабочем языке: «если происходит это, система показывает это, человек принимает вот такое решение, дальше запускается вот это действие». О признаках того, что функция уже изменила чей-то рабочий день, полезно прочитать отдельно: «Я не называю функцию готовой, пока не вижу её в чужом рабочем дне».
Цена функции — не только разработка
У любой новой возможности есть продолжение после релиза. Её нужно объяснить в интерфейсе, включить в поддержку, учесть в правах доступа, проверить при обновлениях и однажды изменить вместе с соседними правилами. Поэтому я смотрю не только на цену создания. Вопрос проще: станет ли после этой функции один рабочий путь короче и понятнее настолько, чтобы она оправдала постоянное место в продукте?
Допустим, команда добавляет возможность вручную менять этап сделки. На демонстрации это выглядит как гибкость. В эксплуатации она может превратиться в проблему: один менеджер меняет этап после звонка, другой — после договора, третий исправляет его задним числом. Отчёт руководителя становится спором о трактовке. Иногда правильная функция — не дать больше свободы, а предложить два ясных пути: «клиент подтвердил» и «нужно уточнение», с разными последствиями.
Такие решения не всегда радуют всех в моменте. Зато они делают поведение продукта предсказуемым. Пользователь понимает, почему система не даёт перейти дальше. Руководитель видит, где действительно застревает работа. Команда поддержки не гадает, является ли случай ошибкой или допустимым вариантом.
Как проверить гипотезу без большого релиза
Если сценарий понятен, не обязательно сразу строить целый раздел. Иногда достаточно добавить в существующую карточку понятный признак, журнал решения и один маршрут уведомления. Ограниченная группа пользователей проходит с этим несколько реальных эпизодов, а команда наблюдает, уменьшились ли уточнения и исчезла ли необходимость пересылать контекст.
Здесь важно не мерить успех количеством нажатий. Люди могут часто пользоваться функцией, потому что она запутывает их или потому что без неё уже нельзя исправить ошибку. Гораздо полезнее спросить: сколько раз решение приняли без дополнительного сообщения? Сколько исключений ушло по правильному пути? Нашёл ли следующий участник процесса причину сам?
Если после проверки стало ясно, что правило всё ещё меняется каждый день, продукт не обязан делать вид, что оно устоялось. Можно оставить решение человеку, но сохранить историю и обозначить срок пересмотра. Так продукт не обещает автоматизацию там, где бизнес ещё только учится формулировать собственный порядок.
Что меняется в разговоре с командой
Этот подход меняет и постановку задачи. Вместо «сделайте поле и фильтр» появляется разговор о решении: «Как менеджер поймёт, что заказ нельзя запускать? Что увидит руководитель? Как мы объясним отказ клиенту?» У дизайнера, разработчика и владельца процесса появляется одна предметная точка, а не три версии запроса.
Так меньше риск построить красивую, но необязательную вещь. В B2B-продукте ценность часто возникает не в эффектной демонстрации, а в спокойном моменте, когда человеку не пришлось искать коллегу, сверять таблицы и гадать, что делать дальше. Именно тогда продукт становится привычным рабочим инструментом, а не витриной возможностей.
Если вы разбираете развитие своего сервиса, начните не со списка «хотелок». Возьмите один длинный рабочий диалог. Выпишите решение, которое люди пытались принять, и условия, без которых они не решались двигаться дальше. Это хороший материал и для следующей функции, и для честного отказа от неё. А когда продукт начинают обходить параллельными таблицами, стоит отдельно проверить, какой рабочий ритуал система пока не поддержала.
Обсудим?