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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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