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