Разработка B2B-продуктов: как построить отношения между пользователем и командой продукта
В крупных B2B-продуктах удобство нельзя оценивать только по интерфейсу. За привычным экраном пользователя часто стоит сложная платформа, десятки взаимосвязанных компонентов и команды, которым нужно не только развивать продукт, но и поддерживать его стабильность в реальных клиентских сценариях. Поэтому при разработке корпоративных решений важно учитывать не только путь конечного пользователя, но и опыт внутренних команд — продуктовых групп, внедрения и эксплуатации.
О том, где в таких продуктах чаще всего возникают скрытые сложности и как найти баланс между потребностями бизнеса, пользователей и разработчиков, рассказала Наталья Буйлина, лидер стрима ITSM платформы производства ПО «Сфера» (входит в ИТ-холдинг Т1).
Корень большинства проблем лежит глубже — в логике сценариев и архитектуре. Интерфейс лишь отражает то, насколько хорошо продуманы пользовательские пути. В продуктах, работающих внутри платформы, главная боль — скрытые зависимости от сервисов и сценарии, которые «ломаются» при любых изменениях в базовой инфраструктуре. При этом человек уверен, что работает с одним продуктом, хотя за ним стоят 5–10 компонентов.
Внутренние команды: пользователи, о которых забывают
Особенность B2B-сегмента в том, что каждый сервис рассчитан сразу на несколько категорий потребителей. Помимо конечных клиентов есть службы эксплуатации, специалисты по внедрению и продуктовые группы, встраивающие компоненты платформы в свои решения. Буйлина подчеркнула, что внутренним командам почти всегда приходится сложнее, хотя со стороны это и незаметно — трудности скрыты за фасадом процессов разработки.
Продуктовые группы быстро обнаруживают, что воспроизвести реальные клиентские сценарии непросто: часть логики находится в коде, часть — в конфигурации, а изолированная среда для тестирования может отсутствовать. В службах поддержки подход еще прагматичнее: когда процесс нужно восстановить здесь и сейчас, команда не ждет штатного решения, а правит данные в базе вручную или обходит стандартные процедуры. Если подобных обходных сценариев накапливается слишком много, это верный признак того, что платформа еще не полностью сформирована.
No-code и low-code: гибкость, которая может стать ловушкой
Отдельного внимания заслуживает работа команд внедрения в no-code- и low-code-среде. Такие инструменты ускоряют запуск новых сценариев, но конфигурация нередко выходит за пределы системы: появляются Excel-файлы с настройками, ручное копирование параметров между клиентами, внешние скрипты.
Поначалу кажется, что подобная гибкость — это безусловное преимущество. Однако со временем набор настроек становится сложнее кода, между элементами возникают неочевидные связи, а разобраться в работе конкретной инсталляции все труднее. К этому добавляется нарастающая хаотичность ролей и прав доступа: временные решения превращаются в постоянные, что напрямую влияет на безопасность всей системы.
Архитектура как точка баланса
Самым важным при проектировании корпоративных платформ являются вопросы функционального дизайна и системной архитектуры. Именно они объединяют все компоненты продукта и определяют его зрелость и применимость в реальном бизнесе.
Продукты не должны сдерживать развитие платформы, а платформа — тормозить продуктовые команды.
