Как стать автором
Обновить
82.89
Рейтинг
Surf
Создаём веб- и мобильные приложения

Топ-5 заблуждений в работе аналитика

Блог компании Surf Анализ и проектирование систем *Аналитика мобильных приложений *

Чем занимается бизнес-аналитик? А кто его знает: какая-то мутная профессия.

Это одно из заблуждений, которое — внезапно — высказывают не только клиенты… Но и коллеги внутри команды разработки, и даже сами аналитики. 

Меня зовут Виктория Юльская. Я аналитик в компании Surf. Успела поработать с разными заказчиками на сложных и не очень проектах. Обучаю бизнес-анализу молодых коллег.

Собрала самые популярные заблуждения начинающих аналитиков о работе и взаимоотношениях с заказчиками.

Заблуждение №1. Без аналитика можно обойтись

Да, даже сами аналитики порой не понимают, зачем они нужны.

Заказчики часто говорят: «А зачем нам аналитик?», «Почему я, как заказчик, не могу передать вам требования, а вы по ним разработаете продукт?», «Еще один человек в команде потребует дополнительных трат». Иными словами, кажется, что вести проект без аналитика можно, а ТЗ написать может кто угодно — особенно, если есть шаблон.

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

❌ Без аналитика

Анализом занимается вся команда. 

Проектные менеджеры выявляют верхнеуровневые требования и пишут ТЗ.

Дизайнеры бесконечно переделывают дизайн: «у нас это не так работает», всплывают новые требования при демонстрации и согласовании дизайна, и так по кругу.

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

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

✅ С аналитиком

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

Команда занимается своим делом и не тратит время на выявление требований. 

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

Без такого анализа дизайнер может не учесть скрытую логику или понять её некорректно.

Аналитик с  руководителем проекта следят, чтобы не выпадать из сметы и договора.

Разработчики по-прежнему что-то да находят — без этого никуда. Они озвучивают проблему — аналитик её решает. Разработчик занимается написанием кода — как и должно было быть.

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

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

В команде поддерживается единое инфополе. Все в курсе новостей и изменений в требованиях.

Когда аналитик сэкономил бы бюджет и сроки проектирования. Два примера

Первый пример. Команда без аналитика разработала прототипы на мобильное приложение. Заказчик дал фидбэк: это очень круто выглядит, но «у нас всё не так работает...» Пришлось полностью переделывать прототипы. 

Аналитик бы сразу узнал, как всё работает, и переделывать не пришлось.

Второй пример. На проекте не было аналитика — изначально клиент не видел в нём смысла. Разработку вели по требованиям от заказчика в таск-менеджере. Они были достаточно поверхностные и не покрывали множества кейсов — это сказывалось в том числе на дизайне. 

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

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

Так чем же всё-таки занимается аналитик. Мнение коллег

Попросила коллег из компании ответить на вопрос: «Чем, по-вашему, занимается аналитик? Как вам жилось бы без него на проекте?» 

Команда, которая привыкла работать с аналитиком и познала все преимущества, видит эту роль так:

Android-разработчик: «Сбор и формализация требований, формирование ТЗ к разработке, ведение бэклога».

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

Flutter-разработчик: «Аналитик — это «мостик» между хотелками заказчика и возможностями разработчика. По сути он конвертирует спецификации в техническое задание».

Тестировщик: «Знаете, я очень часто оказывался в ситуациях, когда аналитика просто не было на проекте. Чувства были различные: и гнев с яростью, и грусть с безнадежностью. Разработчик, QA или PM могут выступать в роли аналитиков, но это разве делает проект лучше? 

Мы только можем верить, что придет он — BA, и вытащит проект из пучин темной бездны. И тут на очередном созвоне говорят: „У нас будет аналитик со следующего спринта“. И сразу же жизнь начинала бить красками: ты понимаешь, что каждый занимается тем, чем и должен был изначально заниматься. Мы спасены, дальше нас ждёт светлое будущее».

Теперь у вас есть аргументы для заказчиков и коллег, зачем же на проекте всё-таки нужен «лишний рот» — бизнес-аналитик.

Заблуждение №2. Заказчик знает, чего хочет

Далеко не всегда заказчик знает, чего хочет. 

Зачастую он озвучивает абстрактные требования или сразу мыслит решением: «Хочу отзывы, как в озоне». При этом что именно нужно сделать, непонятно. Варианты:

  • «Отзывы как в озоне» нравятся визуально. При этом функционально нужно не всё, и заказчик не готов платить за избыточные возможности.

  • Нравится функциональная составляющая, а визуальное решение не подходит.

  • Показалось, что «отзывы на озоне» — эталон. Потом выясняется, что в них нет функциональности, которая нужна заказчику. И работают они совсем не так, как он представлял.

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

Если же молча сделать по первоначальному требованию «Хочу отзывы, как в озоне», реальная потребность или проблема заказчика закрыты не будут. Заказчик останется недоволен результатом, а вину за это повесит на команду разработки во главе с аналитиком. Аргументы «Мы делали по требованиям» не помогут сгладить негатив заказчика. 

Важно внимательно относиться к бизнес-требованиям. Чтобы выявлять реальную боль заказчика, рекомендую задавать больше вопросов «Почему? Зачем? Какую проблему мы хотим закрыть? Каких результатов добиться?». Да, такие вопросы могут выглядеть в глазах заказчика глупо (и в этом нет ничего страшного!). Но гораздо более глупо будет, если команда сделает совсем не то, что хотел клиент.

Заблуждение №3. Заказчик озвучил решение. Отлично, так и делаем

Стоит насторожиться, когда заказчик приходит сразу с готовым решением: «Хочу, чтобы корзина была локальной». Да, локальные корзины делают — технически в этом нет проблем. 

Но давайте не будем сразу бежать реализовывать фичу. Для начала уточним детали: какой функциональностью обладает корзина. Оказывается, там должны быть:

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

  • Баллы, которыми можно оплатить процент от стоимости заказа.

  • Данные для оформления заказа.

  • Управление через платформу автоматизации маркетинга типа loymax или mindbox: они делают свои предрасчеты, а не просто отдают размер скидки по промокоду.

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

  • Почему корзина должна быть локальной? 

  • Какую проблему закрываем этим решением? 

Допустим, заказчик хочет обеспечить быстрый доступ к корзине без загрузок, но не в курсе рисков, которые несёт локальная реализация. Например, он не знает, что локальная корзина — это куча логики и расчётов, и любые изменения должны будут проводиться через релиз. Работа с деньгами это всегда риски, и если её править через релиз, это больно втройне. 

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

Заблуждение №4. Заказчики внимательно читают ТЗ

Нужно быть готовым, что далеко не все заказчики внимательно читают ТЗ, а некоторые и вовсе не читают. Зачастую заказчика дёргают со сроками согласования. В такие моменты ему наверняка хочется, чтобы от него побыстрее отстали. Так получается долгожданное «Согласовано» или принимается решение стартовать разработку без согласования с фразой «Концептуально ок, стартуем».

На самом ли деле слово «Согласовано» означает, что ТЗ согласовано? Спустя некоторое время начинаются замечания, доработки, высказывания: «Должно было быть не так» и «Я не так себе это представлял».

Мы выработали другой способ доносить информацию из ТЗ до заказчика: вместо десятков страниц текста мелким кеглем делаем демо. 

  • Перед встречей отправляем заказчику ТЗ, но не ожидаем, что он его внимательно изучит.

  • На встрече демонстрируем дизайн. Голосом проговариваем требования, логику и обработку граничных кейсов, которые зафиксированы в ТЗ.

  • Заказчик высказывает замечания и уточнения или подтверждает, что всё отлично.

  • Замечания устраняем, отправляем итоговое ТЗ на согласование и ждём согласования.

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

Если нет возможности выделить время на демо и общение происходит в почте (так бывает в банках), есть альтернативный способ получить подтверждение требований:

  • Продумать все тонкие и спорные места. Задать по ним уточняющие вопросы в формате «Верно я понимаю…?».

  • Заказчик подтверждает требование или уточняет детали.

Список утверждений в духе «Раз в 5 минут обновлять список задач», «Если в списке получаем новые задачи, то на вкладке задач отображать анимированный индикатор» при таком подходе не работает, потому что очень уж похож на сжатое ТЗ. А вот список вопросов по узким местам помогает хорошо.

Заблуждение №5. Менять требования нельзя, они согласованы

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

Да, команде это может не понравиться: разработка уже идёт или, что ещё «лучше», задача выполнена. Но это не проблема заказчика — это проблема исполнителя. 

Тут главное, чтобы менеджер грамотно обрабатывал вбросы от заказчика (особенно если оплата за проект фиксированная), а аналитик — грамотно управлял изменениями. 

Перед тем как брать в работу очередное изменение требований, советую включить критическое мышление и вспомнить, что клиент далеко не всегда знает, чего хочет. Поэтому стоит предварительно тщательно допросить заказчика. Начинаем всё сначала: «Почему? Зачем? Какую проблему хотим закрыть? Каких результатов добиться?» Может оказаться, что на самом деле клиенту это не нужно или нужно не это.

О чём помнить начинающему аналитику

  1. Иногда важность роли аналитика на проекте приходится обосновывать самому аналитику. Для этого нужно быть во всеоружии. Например, суметь рассказать клиенту, как ведётся работа без аналитика и с ним. Расписать, что со сроками и бюджетом, сколько людей будут дёргать клиента с глупыми вопросами с разных сторон и так далее. Показать, что, хотя наличие аналитика формально увеличивает стоимость проекта, на самом деле даёт экономию: команда завершит разработку ровно в срок, продукт получится качественный.

  2. Во взаимодействии с клиентом всё совсем не так, как кажется на первый взгляд. Даже если заказчик говорит убедительно, сыпет решениями и просит вас побыть только «рабочими руками» и реализовать фичу (ведь сам-то он кодить не умеет) — не ведитесь, это ловушка. Опыт показывает, что заказчики довольно редко знают наверняка, чего хотят. И самое неприятное: в неудачных результатах они будут винить команду разработки.

  3. Заказчики не читают ТЗ. Точнее, может, они и читают, но не могут сразу предусмотреть все нюансы. Нужно иметь хорошее воображение, чтобы по черным буквам на белом листе представить, каким будет будущий продукт. Поэтому лучше помочь заказчику визуализировать, как всё будет выглядеть и работать: например, с помощью демо. 

  4. Менять изначальные требования можно и нужно. Если появляются новые вводные или меняются приоритеты, не стоит упираться в «как написано и утверждено на бумаге, так и делаем». Качество и успех продукта — прежде всего. 

Теги:
Хабы:
Всего голосов 11: ↑10 и ↓1 +9
Просмотры 13K
Комментарии 30
Комментарии Комментарии 30

Публикации

Информация

Сайт
surf.ru
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия