{"id":13799,"url":"\/distributions\/13799\/click?bit=1&hash=865a89ddf5e1b9e468c75aafc8397c3511c1f5c9a63c9b3d346956d539f26271","title":"\u042d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e \u043f\u0440\u043e\u0434\u0430\u0432\u0430\u0442\u044c \u043d\u0430 \u00ab\u041c\u0430\u0440\u043a\u0435\u0442\u0435\u00bb ","buttonText":" \u041a\u0430\u043a?","imageUuid":"f7affe9f-a742-5820-ac81-04ba4a1a8f84","isPaidAndBannersEnabled":false}

5 татуировок аналитика

Всем привет! Меня зовут Паша, я бизнес-аналитик в компании Thmoon. И сегодня я принес вам лично мои 5 «татуировок» аналитика.

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

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

К типичным задачам бизнес-аналитика можно отнести:

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

Задачи системного аналитика:

  • обрабатывать информацию, представленную в виде ТЗ для разработчиков. Если необходимо — расширять спецификацию требований;
  • описывать Use Cases (сценарии использования), все прочие необходимые для разработчиков требования;
  • взаимодействовать с разработчиками и тестировщиками, проверять соответствие задачи и ее реализации;
  • идти в базу, смотреть логи, актуализировать бэклог и тут тоже до бесконечности в зависимости от проекта.

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

1. Всегда фиксируй требования на бумаге. Даже когда всем всё понятно.

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

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

Во-вторых, даже если вам кажется, что было проведено достаточно встреч и вы не хотите “донимать” заказчика лишними согласованиями (к слову, мне кажется, что любому бизнес-аналитику стоит выключать это чувство. Звоните, пишите и уточняйте все, что вам кажется необходимым), даже если у вас успели сложиться приятельские отношения — счет сохраняет дружбу.

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

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

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

Чем опасно простое следование желанием заказчика? Я могу выделить три проблемы:

  • Вы не решите его проблему. Собственно, ваша основная задача — улучшать продукт. Ваше системное мышление должно нести ценность.
  • Заказчик не будет доволен результатом. Да, вы выполнили все согласно ТЗ. Но кому от этого приятнее жить? На мой взгляд, работа на “отвали” (замените сами) — это путь в никуда. Особенно для аналитиков. Если у вас нет желания ежедневно (ну или хотя бы еженедельно(:) делать сам продукт лучше — задумайтесь, нужно ли оно вам вообще.
  • Придется переделывать. Если заказчик только после реализации осознает, что ему на самом деле нужно что-то другое — вам не скажет спасибо ни один разработчик. Люди — не роботы, никто не любит по 20 раз перепиливать одну и ту же фичу.

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

3. Знай, с кем общаешься. И с кем должен общаться.

Этот совет может звучать забавно, но я сталкивался и с таким — вы можете прийти не к тому человеку. Особенно это актуально при старте работы над новым проектом/с новой компанией. Давайте представим, что на платформе решили переделать воронку продаж. Менеджер проекта знает все требования, вы их обсуждаете и согласовываете, но после релиза к вам приходит Мария Ивановна — глава отдела маркетинга — и неистово кричит о том, что вообще-то все должно быть по-другому. Избегать таких ситуаций довольно просто — спрашивайте, кто отвечает за этот бизнес-процесс и обязательно взаимодействуйте с непосредственным заказчиком.

4. Не забывай про дизайнера, иначе он про тебя не забудет вдвойне.

Я вывел для себя правило — дизайнер всегда видит все по-своему. И с этим обязательно нужно считаться.

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

За последний год у меня не было ни одной (!) ситуации, когда дизайнер не предложил бы иное, нетривиальное решение. Дизайнер всегда подходит к вопросу с иной точки зрения — со стороны визуала и юзабилити (по крайне мере должен). Поэтому чтобы не собирать дополнительные встречи, не инициировать новые обсуждения, старайтесь привлекать вашего коллегу-дизайнера как можно раньше. Даже тогда, когда требования еще только формируются. Более того, не пренебрегайте черновиками и набросками из Figma — если у заказчика будет выбор при просмотре макетов, конечный результат будет лучше.

5. Делай свое, но смотри вокруг.

Пятая и финальная "татуировка" в этой статье, более глобальная, она действует не только в рамках аналитики.

Я в своей работе часто пытаюсь держать в голове это правило. Делай свое, но смотри вокруг. В нашей компании мы работаем вместе - единым фронтом. Каждый помогает друг другу. Но не нужно ждать момента, когда к тебе придут за помощью. Старайся сделать лучше в каждыймомент времени, смотри вокруг, предлагай, улучшай. И поверьте изменения не заставят вас ждать. Уже через пол года - год вы заметите, как вы научились программировать или к примеру создавать дизайн интерфейсов. Это сильно расширяет кругозор и повышает вашу личную экспертизу.

Заключение

Мне кажется, что эту тему можно продолжать бесконечно, потому что бизнес-аналитик — это в первую очередь коммуникатор. В мире нет ничего более нестабильного, чем человек, поэтому в первую очередь помните, что ваша основная цель — минимизировать недопонимание между всеми участниками процессов. Большое спасибо за внимание, обязательно делитесь своими советами!

P.S. Названием статьи вдохновился у Максима Батырева.

Предлагайте свои татуировки в комментариях :)

0
Комментарии
Читать все 0 комментариев
null