Блог NAUMEN
Все записи

Опыт решения большой аналитической задачи

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

35afce076bd384ee494aa9f02cc22dab.png

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

  • обхода предприятий и оборудования; инвентаризации;
  • выездного и внутреннего обслуживания; повышения качества выполнения процессов;
  • отслеживания работы подрядчиков;
  • плана на день;
  • работы в веб-интерфейсе и в мобильном приложении.
c65e9acb7b9b9ee081ec0520de057f98.png

be4f14bfdbd7c8dc605066d161dee631.png

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

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

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

558da3a9086f3d22d3ecc749618baec1.jpg

Где я ошибся?

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

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

9c2d1c61515ea6b543fd4a36fceb14c4.png

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

8ba6de125074457062b6f6c6c8c505a6.jpg

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

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

baf477185d43c889c68e8fdba6598fa7.png

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

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

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

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

15e3aab758a31eff507118db39dbe9d8.png


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


5ac7b76999b0cb7895c348d019d552cd.png


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


fea0c6d91552ec07c1535b77f38421ce.png

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

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

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

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

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

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

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

5c95215139c0a92cda73b6dfc8ff7219.png

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

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

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

2ba5f532d96bfb71ed29ccda8afe99b1.jpg


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

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

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

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

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

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

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

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

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

Выводы: 

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

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

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

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

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

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

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

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

Похожие новости

Red flag: пять неудачных вопросов работодателю

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

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

Сила продуктового мышления: как быть полезным для всех клиентов сразу

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

Нашим коллегам Александру Николаеву из практики BPM и Наталье Ждановой из практики LowCode удалось прокачать два этих паттерна — продуктовый и проектный. В статье они рассказали, в чем видят пользу каждого из типов мышления и как их развить.

Как я из маркетинга перешла в бизнес-анализ

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

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

Все новости