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

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

Привет, Хабр! Меня зовут Шамиль Зигантдинов, я директор по продуктам экосистемы ИТ-продуктов «Лукоморье». Под катом расскажу о нашей системе работы с клиентскими запросами: что мы берем в дорожную карту продукта, что закрываем скриптами и настройками, а что отдаём партнерам в виде плагинов. А также разберем, из чего складывается настоящая цена «фичи на месяц».

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

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

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

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

Мы стараемся сначала отойти на шаг назад и разобраться, зачем клиенту понадобился X. Это особенность его внутреннего процесса или такая потребность есть и у других компаний? Встречалась ли она раньше, попадается ли в тендерах, спрашивают ли о ней потенциальные клиенты, есть ли похожий сценарий у конкурентов?

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

• продуктовые исследования и discovery;

• обратная связь от текущих клиентов;

• запросы потенциальных заказчиков;

• опросные листы;

• открытые тендеры;

• проекты импортозамещения и миграции с других решений;

• продажи и внедрение;

• конкурентный анализ.

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

Когда запрос клиента должен попасть в дорожную карту продукта

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

Похожая история с дорожками (swimlanes) на канбан-досках. Пока возможность нужна одному подразделению одного клиента, повода включать ее в продукт нет. Когда о ней просят разные компании, а сама она встречается у конкурентов, в тендерах и исследованиях, вес сигнала становится совсем другим.

Здесь легко впасть в противоположную крайность и начать превращать каждый подтвержденный запрос в отдельную функцию. Иногда правильнее сделать универсальный механизм.

Один механизм на целый класс задач

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

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

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

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

Сами по себе такие задачи продукту не вредят, проблемы начинаются, когда они незаметно заполняют всю дорожную карту. Здесь хорошо подходит мем This is fine, только вместо горящей комнаты вокруг продуктовой команды «небольшая доработка для клиента», «еще одна маленькая доработка», «тут буквально поле добавить». Квартальная продуктовая стратегия тем временем тихо выходит из комнаты. Чтобы до этого не доходило, мы заранее делим доступную мощность команды.

Дорожная карта проекта как набор квот

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

Поэтому нам ближе подход, при котором доступная мощность команды заранее распределяется между несколькими типами работ. У нас это выглядит  так:

• Развитие продукта. Все, что подтверждается рынком и соответствует продуктовой стратегии.

• Клиентские доработки. Отдельная квота на специфичные запросы заказчиков.

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

• Поддержка и дефекты. Ресурс на проблемы, которые возникают в эксплуатации.

• Крупные обязательные проекты. Безопасность, регуляторика, инфраструктурные изменения и другие заранее известные направления.

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

Команда клиентских решений

Когда компания дорастает до определенного масштаба, клиентскую квоту можно отдать отдельному направлению Customer Engineering. По-русски я бы называл его командой клиентских решений. Это не обязательно департамент со своим директором: модель может начаться с нескольких выделенных разработчиков или фиксированной доли доступной мощности команды. Важнее всего разделить ответственность: основная продуктовая команда развивает продукт для рынка, а команда клиентских решений берет задачи, которые важны конкретным заказчикам и экономически оправданы, но не должны автоматически попадать в ядро продукта.

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

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

Третий путь: плагины

Бывает, что потребность есть у нескольких клиентов, при этом в коробке ей все равно не место. Функция может оказаться слишком отраслевой или завязанной на конкретную внешнюю систему, она может понадобиться пяти компаниям из ста, перегрузить интерфейс или просто не вписаться в стратегию продукта. Долгое время у команды в таких случаях было два варианта: делать самим или не делать. У платформенного B2B-продукта со временем появляется третий — плагин.

Сейчас мы запускаем MVP механизма плагинов для Яги, и одна из задач, которые он должен решить, как раз связана с кастомизациями. В бэклоге плагинов уже набралось много подходящих запросов, например, специализированные интеграции с 1С или GitLab, а еще функции, похожие на популярные расширения для Jira: Planning Poker, дополнительные инструменты для тестирования, нестандартные отчеты и другие нишевые сценарии. Отдельным заказчикам они нужны, и все же тащить каждую такую возможность в дорожную карту Яги мы не хотим.

Схема задумана так: конкретный сценарий из бэклога берет партнер или сам заказчик и пишет под него расширение. Дальше становится интереснее. Допустим, партнер написал плагин для одного клиента, через какое-то время оказалось, что то же самое нужно еще трем компаниям. Тогда готовое расширение можно тиражировать. Для этого мы развиваем Ярмарку, маркетплейс плагинов и приложений для продуктов Яги. Через нее партнеры смогут распространять свои решения, в перспективе и за деньги. Получается цепочка: потребность одного клиента → плагин → решение для нескольких клиентов → самостоятельный продукт партнера.

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

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

Мы пока только запускаем MVP, так что говорить о работающей партнерской экосистеме рано, но развивать модель мы хотим в эту сторону.

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

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

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

Поэтому при оценке клиентского запроса я бы задавал минимум три вопроса:

1. Сколько стоит это разработать?

2. Во что обойдется владение этим в ближайшие несколько лет?

3. Что команда не сделает, пока занимается этим?

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

Маршрут одного запроса

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

• если потребность подтверждают другие клиенты, исследования и тендеры и она вписывается в стратегию, запрос идет в продуктовый бэклог и развивается ключевой командой;

• если проблема общая, но сценарии решения у всех разные, ищем универсальный механизм: настройку, скрипт, API;

• если это специфика конкретного заказчика, запрос уходит в бэклог команды клиентских решений и расходует клиентскую квоту;

• если сценарий потенциально тиражируемый, но в коробке ему не место, он отправляется в бэклог плагина;

• если стоимость владения выше ценности, запрос остается в категории «не делать сейчас».

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

В заключение

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

Кастомизации есть почти в любом живом B2B-продукте. Как мне кажется, здоровым его делает то, что команда в любой момент может ответить на вопрос: мы сейчас развиваем продукт или решаем частную задачу клиента? Оба ответа нормальные, плохо, когда разницу между ними перестают замечать.