Продуктовый подход к созданию цифровых продуктов на примере личного кабинета «Mascoglass»

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

— про успешную доработку личного кабинета для известной федеральной компании;

— про то, как приручить ERP-систему;

— про то, что делать бизнесу, если в 2023 году у компании нет доступной мобильной версии ЛК.

Завязка кейса началась немного нестандартно — обычно все сразу говорят о клиенте, а потом о задачах, которые были решены. Но мы попробуем по-другому, поделимся своим видением того, почему к нам приходят такие крутые клиенты, ведь это неспроста.

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


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

— Есть функциональные команды — это группа разработчиков, кружок тестеров, курилка аналитиков, чат с маркетологами, обособленные тигры в полосатом виде архитекторов и, возможно, менеджеры;

— А есть кросс-функциональные команды, когда в одной группе находятся представители каждого департамента.

В первом варианте у каждой команды единый набор компетенций в своей области, даже если грейд всех участников разный. Представьте, сидят себе тестеры и не понимают, зачем проекту какие-то сложные метрики. Во втором варианте ситуация более интересная, ведь здесь команда сформирована из разных сотрудников со своей специализацией. В «Логеме» мы заинтересованы в том, чтобы каждая команда занималась развитием и поддержкой продукта на максимальном уровне своих возможностей, а значит… Состав кросс-функциональной команды определяется исходя из того, что необходимо продукту. 

Про сильные матрицы, двойственность управления командами и смешанный стиль поговорим как-нибудь в другой статье, если это будет вам интересно. 

В чем плюсы нашего подхода и такой команды:

— Присутствие разработчика на самых ранних этапах (или члена команды с компетенциями разработчика) может привести к внедрению решения по принципу Парето. Иными словами, когда нужно MVP, команда это решение предложит и 80% бизнес-эффекта можно будет визуализировать сразу.

— Рефакторинг — это не просто обновление кода ради самого кода, а стремление улучшить бизнес-процессы. Например, в этом кейсе нам удалось автоматизировать отправку нотификаций пользователям личного кабинета на основе обновленного статуса заявок, а могло быть и наоборот: просто взяли бы у клиента список из 5 вариантов и в продакшн!

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

— Дополнительная мотивация сотрудников. Когда делаешь реальные крутые вещи и параллельно решаешь задачу бизнеса, чувствуешь себя полезным.

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

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

«Mascoglass» — федеральная компания-производитель стеклопакетов и архитектурного стекла. В активе компании восемь производственных площадок, оснащенных высокотехнологичным оборудованием от мировых лидеров отрасли, таких как LISEC (Австрия), TAMGLASS (Финляндия), INTERMAC (Италия), CEFLA (Италия) и LGM-3000 (Китай). 16 производственных линий выпускают до 1 000 стеклопакетов в час и более 500 000 кв.м архитектурного стекла в год. С таким объемом продукции у любой компании будет внушительный штат менеджеров, которым нужны удобные инструменты для обработки заказов и входящих запросов. 

Клиенты «Mascoglass» — крупный и средний бизнес, предприниматели и компании, которые могут заказать любой объем стеклопакетов через личный кабинет на сайте. Каждый клиент ценит время, которое можно сэкономить на оформлении заявки, а также комфортный процесс заказа: если ничего не висит, все интуитивно-понятно, можно использовать ЛК с мобильного — всем хорошо. Но синхронизация данных между кабинетом на сайте и ERP-системой была реализована таким образом, что любая информация из ЛК мгновенно отправлялась в ERP, серьезно нагружая ресурсы. За такое время отклика приходилось «платить»:

— если ERP была по какой-либо причине недоступна, войти в ЛК было невозможно; 

— отправка запросов на авторизацию, при должной сноровке, могла спровоцировать DDos ERP; 

— устаревшая версия ЛК не позволяла вносить изменения в код, чтобы все поправить или хотя бы подключить мобильную версию.

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

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

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

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

1. Выбор владельца продукта (Product Owner) внутри компании

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

2. Сбор кросс-функциональной команды

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

3. Формулировка метрик продукта и их регулярный сбор

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

4. Формулировка гипотез, направленных на рост метрик

Выращивать нужно правильные метрики, а неправильные метрики выращивать не нужно. Гипотезы должны помогать вам анализировать текущее состояние MVP и выявлять потенциальные точки роста. Смысл этого процесса в том, чтобы команда понимала, какие гипотезы могут положительно повлиять на метрики продукта.

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

Мы расширили функциональность личного кабинета, присвоив некоторым заказам отметку «договор отсутствует» и выдвинув города, в которых такой договор не заключен, на первое место в dropdown list. Это повысило удобство кабинета для клиентов и обеспечило более эффективную работу с информацией. ❜❜

В ЛК у заказов, которые обрабатывает менеджер статус «Обработка менеджером». При автоматическом создании заказа можно сразу подтвердить его в ЛК и скачать счет.

Пользователь при выборе города доставки видит, когда заказ формируется автоматически, а когда — после звонка менеджера (напротив города появляется пометка «договор отсутствует»).

5. Внедрение гипотез

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

Команда работала над кейсом с мая по октябрь 2023 года. Поскольку клиент не мог развивать старую систему, мы предложили все снести и построить заново. Выбор пал на Laravel+Vue+Vuetify+Docker — с таким набором сможет работать любая команда в будущем, с поддержкой системы или доработками не будет проблем. К тому же, у нас все равно не было доступа к исходному коду.

Что сделали?

1. Выбрали современный технологический стек;

2. По результатам аналитики и тестов, собрали MVP и получили обратную связь от клиента;

3. Исходный код разместили на нашем сервере;

4. Начали внедрять доработки на основе гипотез о том, каких фич не хватает личному кабинету, чтобы процесс заказа стал удобнее. Зарелизили:

— сбор Email-адресов клиентов;

— возможность восстановления доступа в ЛК без участия менеджера.

— добавление заказов вручную, а не только через файл;

— возможность работы одного пользователя от нескольких юр. лиц (мультиаккаунтинг);

— заказ и получение УПД в ЛК;

— отправка рекламаций в ЛК;

— удобная фильтрация заявок;

— информирование клиентов о смене статуса заявки;

— возможность загружать дополнительные файлы при создании заявки (чертежи, дополнительная информация);

— просмотр списка всех заявок;

— получение обратной связи от клиентов через ЛК.

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

Команда «Логемы» предложила реализовать асинхронное взаимодействие ЛК и ERP.

Теперь нагрузка на ERP практически нулевая, а неавторизованные пользователи не взаимодействуют с ERP вовсе, потому что 90% возможностей ЛК доступны без ERP. 

Последним этапом проработали мобильную версию.

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

— Отслеживание статусов заявок; 

— Получение счетов; 

— Подтверждение заявки; 

— Получение УПД; 

— Формирование актов сверки.

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

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

❛❛ Продуктовый подход позволил не только добиться результата, но и здорово прокачал команду. Я выступал в этом проекте в роли SRM/SDM, поэтому изнутри смотрел на работу специалистов. Приятно видеть, как с каждой решенной задачей растут софт-скилы инженеров, тестировщиков и аналитиков. 

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