Чем занимается бизнес-аналитик? А кто его знает: какая-то мутная профессия.
Это одно из заблуждений, которое — внезапно — высказывают не только клиенты… Но и коллеги внутри команды разработки, и даже сами аналитики.
Меня зовут Виктория Юльская. Я аналитик в компании Surf. Успела поработать с разными заказчиками на сложных и не очень проектах. Обучаю бизнес-анализу молодых коллег.
Собрала самые популярные заблуждения начинающих аналитиков о работе и взаимоотношениях с заказчиками.
Заблуждение №1. Без аналитика можно обойтись
Да, даже сами аналитики порой не понимают, зачем они нужны.
Заказчики часто говорят: «А зачем нам аналитик?», «Почему я, как заказчик, не могу передать вам требования, а вы по ним разработаете продукт?», «Еще один человек в команде потребует дополнительных трат». Иными словами, кажется, что вести проект без аналитика можно, а ТЗ написать может кто угодно — особенно, если есть шаблон.
Иногда аналитиков привлекают на защиту и «продажу» своей роли перед заказчиком. Будет нелишним вооружиться аргументами: сравним, как происходит работа без аналитика и с аналитиком.
❌ Без аналитика
Анализом занимается вся команда.
Проектные менеджеры выявляют верхнеуровневые требования и пишут ТЗ.
Дизайнеры бесконечно переделывают дизайн: «у нас это не так работает», всплывают новые требования при демонстрации и согласовании дизайна, и так по кругу.
Разработчики выявляют более детальные требования, вместо того чтобы писать код.
Тестировщики при проверке сборки к очередному релизу натыкаются на необработанные кейсы и опять возвращаются к выявлению требований. Бывает, что разработчик одной платформы уточнил требование, но до команды другой платформы оно не дошло. Получается разная реализация на платформах и последующие выяснения, а как правильно.
✅ С аналитиком
Аналитик обсуждает с командой дизайн и требования перед началом проекта: замечания и вопросы снимаются до старта разработки, принимаются архитектурно правильные решения. Они соответствуют требованиям заказчика и закрывают потребности пользователя.
Команда занимается своим делом и не тратит время на выявление требований.
Дизайнеры получают подробно выявленные требования. Они понимают, для чего эта задача, какую проблему она закрывает, какие данные необходимы и как всё должно функционировать.
Без такого анализа дизайнер может не учесть скрытую логику или понять её некорректно.
Аналитик с руководителем проекта следят, чтобы не выпадать из сметы и договора.
Разработчики по-прежнему что-то да находят — без этого никуда. Они озвучивают проблему — аналитик её решает. Разработчик занимается написанием кода — как и должно было быть.
Тестировщики обязательно находят разные нюансы, но это и хорошо: работа у них такая. Они не выявляют требования, а занимаются свои делом — тестируют и помогают донести до людей качественный продукт.
У команды есть «Энциклопедия проекта» в виде ТЗ и самого аналитика. Энциклопедия детально описывает логику и покрывает большое количество граничных кейсов. Аналитик всегда поможет, уточнит нюансы, подскажет, что требуется. Это точка синхронизации между разработкой и бизнесом.
В команде поддерживается единое инфополе. Все в курсе новостей и изменений в требованиях.
Когда аналитик сэкономил бы бюджет и сроки проектирования. Два примера
Первый пример. Команда без аналитика разработала прототипы на мобильное приложение. Заказчик дал фидбэк: это очень круто выглядит, но «у нас всё не так работает...» Пришлось полностью переделывать прототипы.
Аналитик бы сразу узнал, как всё работает, и переделывать не пришлось.
Второй пример. На проекте не было аналитика — изначально клиент не видел в нём смысла. Разработку вели по требованиям от заказчика в таск-менеджере. Они были достаточно поверхностные и не покрывали множества кейсов — это сказывалось в том числе на дизайне.
Команда выявляла требования в процессе разработки и тестирования. Из-за обилия доработок и крупных изменений в логике разработчики не уложились в бюджеты и сроки. Заказчик остался недоволен результатами, а команда — процессами.
Решили за свой счет подключить аналитика на проектирование некоторого скоупа задач, чтобы показать заказчику, насколько всё улучшится на проекте. Команда счастлива, сроки соблюдены, багов в разы меньше. Правда, заказчик от роли аналитика все равно отказался — не знаю, по каким причинам.
Так чем же всё-таки занимается аналитик. Мнение коллег
Попросила коллег из компании ответить на вопрос: «Чем, по-вашему, занимается аналитик? Как вам жилось бы без него на проекте?»
Команда, которая привыкла работать с аналитиком и познала все преимущества, видит эту роль так:
Android-разработчик: «Сбор и формализация требований, формирование ТЗ к разработке, ведение бэклога».
Тестировщик: «Собирает требования, пишет документацию, иногда занимается проектированием системы, является транслятором между заказчиком и разработкой, лучше всех знает поведение системы».
Flutter-разработчик: «Аналитик — это «мостик» между хотелками заказчика и возможностями разработчика. По сути он конвертирует спецификации в техническое задание».
Тестировщик: «Знаете, я очень часто оказывался в ситуациях, когда аналитика просто не было на проекте. Чувства были различные: и гнев с яростью, и грусть с безнадежностью. Разработчик, QA или PM могут выступать в роли аналитиков, но это разве делает проект лучше?
Мы только можем верить, что придет он — BA, и вытащит проект из пучин темной бездны. И тут на очередном созвоне говорят: „У нас будет аналитик со следующего спринта“. И сразу же жизнь начинала бить красками: ты понимаешь, что каждый занимается тем, чем и должен был изначально заниматься. Мы спасены, дальше нас ждёт светлое будущее».
Теперь у вас есть аргументы для заказчиков и коллег, зачем же на проекте всё-таки нужен «лишний рот» — бизнес-аналитик.
Заблуждение №2. Заказчик знает, чего хочет
Далеко не всегда заказчик знает, чего хочет.
Зачастую он озвучивает абстрактные требования или сразу мыслит решением: «Хочу отзывы, как в озоне». При этом что именно нужно сделать, непонятно. Варианты:
«Отзывы как в озоне» нравятся визуально. При этом функционально нужно не всё, и заказчик не готов платить за избыточные возможности.
Нравится функциональная составляющая, а визуальное решение не подходит.
Показалось, что «отзывы на озоне» — эталон. Потом выясняется, что в них нет функциональности, которая нужна заказчику. И работают они совсем не так, как он представлял.
Заказчику нужно решить бизнес-проблему, но у него не всегда получается грамотно её сформулировать. Задача аналитика — помочь выявить проблему и выработать решение, которое учтёт требования бизнеса, потребности пользователей, архитектурные нюансы, впишется по бюджету.
Если же молча сделать по первоначальному требованию «Хочу отзывы, как в озоне», реальная потребность или проблема заказчика закрыты не будут. Заказчик останется недоволен результатом, а вину за это повесит на команду разработки во главе с аналитиком. Аргументы «Мы делали по требованиям» не помогут сгладить негатив заказчика.
Важно внимательно относиться к бизнес-требованиям. Чтобы выявлять реальную боль заказчика, рекомендую задавать больше вопросов «Почему? Зачем? Какую проблему мы хотим закрыть? Каких результатов добиться?». Да, такие вопросы могут выглядеть в глазах заказчика глупо (и в этом нет ничего страшного!). Но гораздо более глупо будет, если команда сделает совсем не то, что хотел клиент.
Заблуждение №3. Заказчик озвучил решение. Отлично, так и делаем
Стоит насторожиться, когда заказчик приходит сразу с готовым решением: «Хочу, чтобы корзина была локальной». Да, локальные корзины делают — технически в этом нет проблем.
Но давайте не будем сразу бежать реализовывать фичу. Для начала уточним детали: какой функциональностью обладает корзина. Оказывается, там должны быть:
Промокоды, которые могут «протухать», заканчиваться и так далее.
Баллы, которыми можно оплатить процент от стоимости заказа.
Данные для оформления заказа.
Управление через платформу автоматизации маркетинга типа loymax или mindbox: они делают свои предрасчеты, а не просто отдают размер скидки по промокоду.
Всё это — в мобильном приложении. В дело вступает критическое мышление: из опыта понятно, что много что может пойти не так. Стоит узнать:
Почему корзина должна быть локальной?
Какую проблему закрываем этим решением?
Допустим, заказчик хочет обеспечить быстрый доступ к корзине без загрузок, но не в курсе рисков, которые несёт локальная реализация. Например, он не знает, что локальная корзина — это куча логики и расчётов, и любые изменения должны будут проводиться через релиз. Работа с деньгами это всегда риски, и если её править через релиз, это больно втройне.
Хорошо бы озвучить заказчику эти нюансы. Может оказаться, что гибкость и безопасность важнее быстрой загрузки корзины. А быструю загрузку корзины можно реализовать другим способом, который не будет настолько рискованный.
Заблуждение №4. Заказчики внимательно читают ТЗ
Нужно быть готовым, что далеко не все заказчики внимательно читают ТЗ, а некоторые и вовсе не читают. Зачастую заказчика дёргают со сроками согласования. В такие моменты ему наверняка хочется, чтобы от него побыстрее отстали. Так получается долгожданное «Согласовано» или принимается решение стартовать разработку без согласования с фразой «Концептуально ок, стартуем».
На самом ли деле слово «Согласовано» означает, что ТЗ согласовано? Спустя некоторое время начинаются замечания, доработки, высказывания: «Должно было быть не так» и «Я не так себе это представлял».
Мы выработали другой способ доносить информацию из ТЗ до заказчика: вместо десятков страниц текста мелким кеглем делаем демо.
Перед встречей отправляем заказчику ТЗ, но не ожидаем, что он его внимательно изучит.
На встрече демонстрируем дизайн. Голосом проговариваем требования, логику и обработку граничных кейсов, которые зафиксированы в ТЗ.
Заказчик высказывает замечания и уточнения или подтверждает, что всё отлично.
Замечания устраняем, отправляем итоговое ТЗ на согласование и ждём согласования.
Да, времени занимает больше, чем просто прочитать ТЗ и получить формальный «ок». Но насколько же это эффективнее. Согласование ТЗ теперь приятный процесс и для исполнителя, и для заказчика. Мы смотрим картинки будущего приложения и детально представляем, как оно будет работать, а не просто читаем портянку текста.
Если нет возможности выделить время на демо и общение происходит в почте (так бывает в банках), есть альтернативный способ получить подтверждение требований:
Продумать все тонкие и спорные места. Задать по ним уточняющие вопросы в формате «Верно я понимаю…?».
Заказчик подтверждает требование или уточняет детали.
Список утверждений в духе «Раз в 5 минут обновлять список задач», «Если в списке получаем новые задачи, то на вкладке задач отображать анимированный индикатор» при таком подходе не работает, потому что очень уж похож на сжатое ТЗ. А вот список вопросов по узким местам помогает хорошо.
Заблуждение №5. Менять требования нельзя, они согласованы
На проекте может случиться что угодно: нашли что-то критичное, появились новые вводные и согласованная логика уже не совсем подходит, изменились приоритеты — требования можно изменить, и в этом нет ничего страшного.
Да, команде это может не понравиться: разработка уже идёт или, что ещё «лучше», задача выполнена. Но это не проблема заказчика — это проблема исполнителя.
Тут главное, чтобы менеджер грамотно обрабатывал вбросы от заказчика (особенно если оплата за проект фиксированная), а аналитик — грамотно управлял изменениями.
Перед тем как брать в работу очередное изменение требований, советую включить критическое мышление и вспомнить, что клиент далеко не всегда знает, чего хочет. Поэтому стоит предварительно тщательно допросить заказчика. Начинаем всё сначала: «Почему? Зачем? Какую проблему хотим закрыть? Каких результатов добиться?» Может оказаться, что на самом деле клиенту это не нужно или нужно не это.
О чём помнить начинающему аналитику
Иногда важность роли аналитика на проекте приходится обосновывать самому аналитику. Для этого нужно быть во всеоружии. Например, суметь рассказать клиенту, как ведётся работа без аналитика и с ним. Расписать, что со сроками и бюджетом, сколько людей будут дёргать клиента с глупыми вопросами с разных сторон и так далее. Показать, что, хотя наличие аналитика формально увеличивает стоимость проекта, на самом деле даёт экономию: команда завершит разработку ровно в срок, продукт получится качественный.
Во взаимодействии с клиентом всё совсем не так, как кажется на первый взгляд. Даже если заказчик говорит убедительно, сыпет решениями и просит вас побыть только «рабочими руками» и реализовать фичу (ведь сам-то он кодить не умеет) — не ведитесь, это ловушка. Опыт показывает, что заказчики довольно редко знают наверняка, чего хотят. И самое неприятное: в неудачных результатах они будут винить команду разработки.
Заказчики не читают ТЗ. Точнее, может, они и читают, но не могут сразу предусмотреть все нюансы. Нужно иметь хорошее воображение, чтобы по черным буквам на белом листе представить, каким будет будущий продукт. Поэтому лучше помочь заказчику визуализировать, как всё будет выглядеть и работать: например, с помощью демо.
Менять изначальные требования можно и нужно. Если появляются новые вводные или меняются приоритеты, не стоит упираться в «как написано и утверждено на бумаге, так и делаем». Качество и успех продукта — прежде всего.
