Всем привет! В прошлый раз я, как Product Owner клиентского мобильного приложения Первой грузовой компании (ПГК), рассказала о формировании нашей продуктовой команды. Спасибо всем, кто оставил комментарии под текстом. Благодаря вашим сообщениям появился этот материал. Сегодня поделюсь с вами опытом, как мы сформировали матрицу компетенций, и как коллеги развивали свои скилы во время прототипирования и проектирования сервиса.

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

Как собирали команду

Мы пригласили в команду представителей разных сфер бизнеса. В нее вошли коммерческие специалисты (продажи) – люди, непосредственно работающие с клиентами, принимающие их заявки и понимающие, что им нужно. Они — «первая линия» по сбору обратной связи о некачественных вагонах. Еще позвали представителей вагонного блока – тех, кто отвечает за ремонт вагонов, специалистов движенческого блока, оформляющих документы на отправку вагона в депо, и ИТ-экспертов, которые воплощают в жизнь пожелания бизнеса и клиентов. Отмечу, что мы выбирали и профильных специалистов, и руководителей.

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

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

В проект были приглашены 10 человек.

Как формировался набор компетенций продуктовой команды

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

• Клиент

• Стратегия

• Анализ данных

• Контроль динамики изменений

• Работа в команде

• Коммуникации

Затем сформировали набор компетенций для членов продуктовой команды «Мобильного репортера». Он подвижный, мы продолжаем его доработку. Тем не менее, хочу поделиться полученным результатом:

• Умение оценить рынок, конкурентов, партнеров

• Владение методиками стратегического анализа

• Понимание бизнес-методологий и умение применить их к своему продукту

• Понимание ЦА и умение ее сегментировать

• Умение выявлять «боли» клиентов и бизнес-заказчиков

• Умение формулировать УТП

• Владение ключевыми бизнес-метриками

• Знание основных методик качественных и количественных исследований

• Умение проводить интервью, анализировать информацию и формулировать выводы

• Умение формулировать гипотезы и знать способы их проверки

• Понимание юнит-экономики и ее связи с продуктовыми показателями

• Умение приоритизировать бэклог

• Готовность к запуску пилотных продуктов

• Видение дальнейшего развития продукта

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

Как мы работали и учились вместе

На первом этапе мы проанализировали «боли» клиентов и ПГК, то, как можем с ними справиться. Перед нами стояла задача – разработать алгоритм мониторинга состояния вагонов. Для клиента подача некачественного вагона чревата задержками поставок товаров, для ПГК — потерей лояльности партнера, временными и финансовыми затратами на то, чтобы выяснить, кто виноват в повреждениях, отправить вагон в ремонт, найти замену. В результате появилась идея сделать простое мобильное приложение, которое позволит максимально ускорить и упростить этот процесс. Поскольку продукт был экспериментом, сроки на изготовление прототипов и запуск рабочей версии с базовыми функциями были максимально сжатыми.

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

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

На следующем этапе приступили к отрисовке Scetchflow основных экранов. Начали разработку на бумаге, поскольку это быстро, не требует вложений, включиться может каждый член команды, который ранее никогда не разрабатывал прототипы приложений. Проявить себя могли все. Каждый специалист мог не только рассуждать в рамках своей экспертной области, но и участвовал в проработке логики действия будущего приложения. Отрисовку реальных экранов мы выполняли в Axure. По итогу все прототипы были проработаны в Figma. Бизнес-заказчик увидел, как предложенная идея может быть реализована. Кроме того, мы сформировали перечень доработок, которые позволят сделать  предложенную модель сквозной.

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

Предложенная модель проходила UX-тестирование у клиентов. Для специалистов по ремонту вагонов и ИТ-экспертов опыт общения с партнерами ПГК был чем-то совершенно новым. Это помогло им развить навыки деловой коммуникации с конечным потребителем. Благодаря обратной связи от клиентов провели UX-донастройку прототипа в соответствии с их пользовательским видением.

Что в итоге

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