Блог 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 войдут не все кейсы, но их надо будет закрывать в дальнейших версиях. Заложите развитие еще до начала разработки и в дизайне и в коде, чтобы потом не пришлось переделывать архитектуру, а также снизить стоимость доработок и ускорить их реализацию в будущем.

Выводы: 

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

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

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

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

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

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

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

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

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

Как переработать образовательный курс и сохранить баланс между работой и семьей

Даша Портнова — системный аналитик и программный директор курса «Профессия аналитик в IT» от Naumen. Образование и развитие других — важная часть ее жизни. Когда Даша ушла в декрет с младшей дочкой, она решила не откладывать карьерные цели и полностью погрузилась в переработку нашего курса для аналитиков. Ей хотелось сделать его максимально полезным для студентов. 

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

Приемы «захвата» внимания слушателей

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

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

Как сотрудники Naumen покоряют горные вершины

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

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

Сейчас в турклубе 77 человек, а регулярно в походы отправляются 11–16 туристов. За 2 года они покорили пять вершин, придумали четыре лайфхака для путешествий и накопили кучу локальных шуток. Этим туристическим «багажом» делимся с вами в статье.

Все новости