Меня зовут Саша и я аналитик SMP Mobile. Это мобильное приложение, с помощью которого коллеги могут, например, зарегистрировать заявку по QR коду в офисе и не только.

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

Мне нужно было создать чек-листы для разных целей:

• обхода предприятий и оборудования;

• инвентаризации;

• выездного и внутреннего обслуживания;

• повышения качества выполнения процессов;

• отслеживания работы подрядчиков;

• плана на день;

• работы в веб-интерфейсе и в мобильном приложении.

Почему это большая задача?

• Много стейкхолдеров — задача нужна как для внутренних сервисов и продуктов, так и для внешних заказчиков.

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

• Востребованность кейсов для разных ролей — исполнитель, руководитель, заказчик, диспетчер и так далее.

• Задача требует новых решений на трех уровнях: UI, логики и объектной модели.

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

Где я ошибся?

Неправильно использовал карту эмпатии

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

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

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

Зато был перенасыщен блок «Что они делают» — он очень разнообразен по специфике и общей картины тоже не складывается. В итоге по карте эмпатии было ничего не понятно.

В чем была проблема?

1. Я не провел интервью с реальными пользователями. Когда в B2B мы проводим интервью, то, как правило, общаемся не с конечными пользователями, а с ЛПР, руководителями и так далее. Из-за этого мы не можем понять, что слышат, хотят или что «болит» у пользователя.

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

Не остановился вовремя

Когда мы хотим из потенциальной функциональности выделить MVP, все кейсы в первую версию, конечно, не попадут. Мы решили применить трассировку требований : составить схему-кейс → Job Story → функциональность.

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

Как получилось в итоге:

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

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

Делал два дела одновременно

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

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

Был чересчур уверен в дизайне

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

Вывод: тестируйте дизайн всегда, даже если вы в нем уверены на все 100%.

Что я все-таки сделал хорошо 

Думал об удобстве партнеров

Аналитики берут огромный объем информации, чтобы переработать его и затем пустить в разработку, дизайн и так далее. Чтобы вас быстро и правильно поняли, результат аналитики должен быть понятен для тех, кто будет с ним работать. Когда готовите требования, учитывайте, для кого вы их готовите. Я думал, будет ли удобно разработчикам работать с этой информацией. Например, делал графические схемы, составлял Json, писал понятные и удобные постановки и так далее. 

Использовал чужой опыт

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

Просил совета у опытных коллег

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

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

Лучше заранее подготовить список вопросов и следовать сценарию дискуссии. Если есть возможность – запишите встречу, это тоже поможет не потерять важные детали. 

Думал о будущем развитии задачи

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

Выводы: 

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

• Проверяйте методы на небольшой части данных, если вы в них не уверены.

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

• Тестируйте дизайн!

• Ведите историю задачи для ретроспективы.

• Думайте о тех, кто будет работать с вашей аналитикой и предоставляйте им данные в удобном виде.

• Используйте опыт других продуктов и не стесняйтесь просить совета у опытных сотрудников.

• Закладывайте дальнейшее развитие при разработке первой версии