Сейчас явно прослеживается тенденция на очеловечивание сухих интерфейсов. Это говорит о том, что меняется подход к разработке IT-продуктов даже в тех компаниях, которые считались консервативными. Клиент повсеместно стал более требователен и разборчив. Что бы оставаться конкурентоспособными, компаниям важно ориентироваться на пользователя, его нужды и пожелания. Меня зовут Дмитрий Бохан, в ПГК руковожу проектом «Личный кабинет клиента». Недавно на одном вебинаре рассказал о том, как превратить сухую бизнес-идею в «живой» интерфейс. Хочу поделиться и с вами. Надеюсь, этот опыт будет полезен.

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

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

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

Над проектом «Личный кабинет клиента ПГК» мы работаем с 2017 года. Нашим партнером по разработке выступает компания Ареал. В настоящее время сервисом пользуются более тысячи компаний (в основном это крупные b2b компании), и он продолжает активно развиваться. Для тех, кому может показаться, что тысяча компаний – не такое большое число, добавлю, что уже сейчас через ЛКК к нам поступают заказы на вагоны для перевозок объемом более чем 3 млн тонн в месяц. Мы используем машинный интеллект для прогноза прибытия вагонов, клиент может отслеживать перевозку своих грузов на карте в режиме реального времени и получать аналитические данные для дальнейшего планирования грузовых операций.

Бизнес и IT- команда должны слышать друг друга

Поговорим о рабочих процессах по взаимодействию бизнеса и IT- команды на примере создания в Личном кабинете клиента ПГК онлайн-заявки на перевозку груза. Подача заявки – это сервис, который важен как для наших клиентов, так и для наших менеджеров. Не так давно UBER изменили сферу такси, внедрив подачу заявки онлайн!

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

Однако, сама форма заявки изначально получилась сложной. Она состоит из 5 шагов, и если ты не погружен в процесс жд перевозок, то почти невозможно представить, какое огромное количество вариаций нужно учесть при ее заполнении.

Много вопросов также возникало по интеграции сервиса с внутренней IT-системой SAP. Подача заявки – не просто форма, это сквозной процесс, который делает работу прозрачнее и требует изменений. Чтобы получить тот продукт, который будет востребован рынком, уже на этапе разработки потребовалась синхронизация между коммерсантами и IT-специалистами.

Разбираем процесс по этапам

1. После того, как определена верхнеуровневая задача, проводится установочная кик-офф встреча (от англ. Kickoff meeting) — это первая встреча с участниками проекта и бизнес-экспертами. На ней нужно определить основные функции/фичи проекта, собрать бизнес-требования и определить мероприятия по планированию.

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

3. После того, как прототип утвержден, формируется техническое задание (ТЗ) с описанием структуры и бизнес-логики. Часто на моменте согласования ТЗ и дизайна мы получаем новые требования: так, после большого количества итераций рождается тот интерфейс, который становится идеальным для клиента.

Спрячьте лишнее в справочник

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

Это бесконечный процесс. Даже если ваш продукт уже работает на рынке, всегда есть, что улучшить. Для примера: изначально в заявке клиент ПГК должен был заполнить несколько полей формы, чтобы указать станцию. Помимо названия станции обязательно нужно было вписать название страны, ввести другие дополнительные данные. Теперь при создании электронной заявки на перевозку клиенту ПГК достаточно указать станцию – система сама подтянет всё необходимое.

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

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

У нас за каждое поле буквально шла война с заказчиком. Где-то побеждали мы, где-то – заказчик отстаивал позиции с точки зрения правил РЖД или законодательства. После таких внутренних сражений мы проводили CustDev-интервью с потенциальными пользователями системы. Именно в такой плотной работе с будущими пользователями рождается современный и качественный дизайн интерфейса.

Первые шаги по созданию продукта

1 – is-is – от решения на бумаге в цифру, определение с бизнес требованиями

2 – создание прототипа

3 – схемы БП и пользовательские истории

4 – дизайн

5 – аналитика и решение о дальнейшей оптимизации

Как продуктивно проводить встречи

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

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

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

Как понять, что вы сделали действительно хороший продукт?

Мы сравнивали весь процесс заполнения заявки на перевозку в ЛКК не только на уровне клиента, но и на уровне менеджера. В результате сейчас документ формируется в 3-4 раза быстрее, повысилась прозрачность процесса.

В текущей версии пользователь может скопировать заявку на основании предыдущей. Мы убрали все отнимающие время бумажные процессы – печать, сканирование, сбор подписей. И сейчас руководитель может в свободную минуту зайти в ЛКК, чтобы подписать заявку.

Для коммерческого блока ПГК удобны стратегические возможности. Наши менеджеры видят воронку, сколько клиентов запросило перевозку, куда, в каком объеме, всю аналитику. Значительно упростилась работа специалистов: не нужно вбивать материал вручную для того, чтобы потом сделать выводы. Актуальные данные всегда под рукой.

Синхронизация команд

Так как мы имеем функционал, который требует интеграции нескольких систем, важно коллективно разобрать (с представителями от каждой из систем) техническое задание. Требуется полноценная проработка сервисов. Важно определиться – синхронный или асинхронный интерфейс, описать интерфейсы обмена, перечень и тип данных.

В нашем проекте в процессе написания ТЗ участвовали представители нескольких команд. Мастер-система SAP TM – это одна команда, вторая – шина данных, третья – SAP​. Отдельно над микросервисами и бэкендом ЛКК работает команда Ареал.

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

Как не перейти от проекта к процессу?

После первичного согласования ТЗ мы фиксируем объем работы, а в дальнейшем, при возникновении новых требований, оформляем их отдельными дополнительными блоками. Это позволяет контролировать объем трудозатрат и бюджет проекта. Хорошей практикой является, когда кроме плана (декомпозиция задач) вы строите прогнозную модель по расходам в рамках бюджета.

Что касается формата финансовых взаиморасчетов – сейчас мы работаем с партнером «Ареал» в формате Time&Materials (ТМ). Да, работать по фиксированному заказу в какой-то мере проще, однако, действующая форма удобнее с точки зрения скорости создания итогового продукта и оперативного внесения изменений. Нам, как заказчику, не нужно ждать, пока будет выполнен весь функционал, который мы согласовали ранее, чтобы внести правки, которые рынок требует уже сейчас.

Да, есть риск потратить все деньги на изменения, но так и не получить итоговый продукт. Но этот риск всегда можно минимизировать.

Мы начали вести ежедневные 15 минутные Stand Up встречи, на которых одновременно присутствуют бизнес и IT, и нам этого хватает. Если на вопрос нельзя ответить за 30 секунд, он выносится в персональное обсуждение. Проводим раз в две недели демо с демонстрацией проделанной работы, а также встречи по планированию, которые позволяют выкинуть все лишнее и сосредоточиться на актуальных задачах.

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

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