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

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

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

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

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

B2B- и B2C-исследования — две большие разницы

Исследования для B2C-разработки проще в плане поиска информантов, продумывания гипотез и общей логики. Потому что в целом понятен конечный пользователь, его задачи и потребности, а продукт чаще всего — коммерция или услуги, все то, что привычно и ежедневно нас окружает. Например, банковские приложения, маркетплейсы и другие сервисы, где понятно, что надо исследовать и кого о чем спрашивать. 

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

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

Переделывать чужое сложнее, чем с нуля пилить свое

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

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

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

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

Заказчиков и пользователей больше, чем кажется на первый взгляд, и они очень разные 

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

• головной офис в Москве — непосредственный и главный заказчик разработки;

• логисты на заводах — пользователи, обеспечивают и контролируют поставки-перевозки с полей на завод;

• механизаторы — пользователи, которые управляют погрузчиками в полях;

• водители — пользователи, которые перевозят на камазах свеклу, мужчины 25-60 лет (чаще 45 и выше).

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

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

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

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

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

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

Итак, у нас были работники в возрасте от 45 до 60 лет, не понимающие, чем приложение может помочь в их водительском деле. Они совершенно не были заинтересованы в приложении, поскольку не верили, что мы можем разработать для них функциональную систему. Они говорили:

Все равно ничего работать не будет. Вы там в своей Москве сидите и ничего не понимаете.

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

В В2В у каждой группы пользователей свои задачи, потребности и отношение к проблемам

Руководство компании-заказчика обозначило: хотим справиться с очередями на погрузке/разгрузке — нужно добиться равномерной загруженности соответствующего пункта на производстве. Это главная проблема, которую они замечали со своей позиции.

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

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

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

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

К интервью нужно готовиться. Что это значит на самом деле?

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

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

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

Можно использовать картирование опыта, например, Customer Journey Map. Это аналитическая модель, таблица или ориентированный граф, отражающий опыт клиента при его взаимодействии с продуктом. Картирование опыта позволяет упаковать результаты исследования в логические схемы, которые можно и представить заказчику, и передать команде разработки. На этом этапе важно не уходить в проработку деталей, а видеть главное и отбрасывать все ненужное.

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

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

С пользователями важно говорить на их языке и в подходящей обстановке

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

В процессе  мы столкнулись с самыми разными реакциями и поведением людей. Но главное — наконец стали понятны их боли. Для водителей мы отметили такие моменты:

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

Еще в поле быстро стало понятно, как образуются очереди на погрузку. В этом процессе много нюансов, которые важно учитывать при планировании и распределении рейсов, но главное другое. С утра водители приезжали сильно заранее, чтобы занять очередь, и толпились в ожидании. Затем они выстраивались в новую очередь, но уже на разгрузке, ведь на заводе погрузка занимает меньше времени, чем разгрузка. Но самое забавное, что часто водители собирались группами и ездили вместе, «чтобы было веселее».

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

Полевые командировки

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

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

Тогда же мы осознали масштаб влияния внешних факторов на общий процесс и работу системы. В первый день командировки шел сильный дождь, и землю в поле размыло настолько, что после загрузки приходилось тянуть каждый КАМАЗ трактором до асфальтированной дороги. Естественно, это удлиняло время доставки груза до завода. Также, как и железнодорожный переезд, который находился на пути на завод на одном из маршрутов. Можно ли увидеть такие нюансы, сидя в офисе?

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

Только физически побывав в поле, мы обнаружили ошибку, о которой не догадывались — неправильный расчет ежедневных квот по поставкам продукции с полей на переработку. Изначально мы рассчитывали квоту, то есть суточный объем привезенной продукции, из расчета времени работы завода — с 7 до 7 утра. А надо было с 12 до 12, потому что так отсчитывает сутки и обновляется 1С. Этот нюанс вскрылся, только когда мы самостоятельно прошли весь путь пользователя.

Главные выводы из наших приключений

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

По исследованиям

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

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

Чтобы получилась действительно полезная для бизнеса и его сотрудников IT-система, важно рассматривать задачу со всех сторон: и со стороны конечного пользователя, и со стороны бизнеса (у нас же B2B). Важно найти баланс между бизнес-интересами и интересами пользователей — часто это получается не сразу.

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