Testing Stage’19: Technical | Security | Management and Approach — Early bird till 21 Dec. Hurry up!
×Закрыть

Что делает бизнес-аналитик на discovery-фазе: анализ потребностей клиента

В прошлой статье я рассказал, какие задачи решает бизнес-аналитик. В этот раз поговорим больше о его работе на дискавери-фазе. Я встречал два пути ее инициирования:

  • Продажа дискавери-фазы как отдельного продукта с определенными сроками и стоимостью.
  • Проведение дискавери-фазы вендором за свой счет, чтобы привлечь клиента.

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

На практике дискавери-фаза длится до 1 месяца. Почти никто не инвестирует в этот процесс так, чтобы он длился 2-4 месяца.

Хочу отметить, что не всегда дискавери-фаза проводится до подписания контракта. Бывают случаи, когда тендер уже был проведен, контракт подписан, а требований нет. Вот тут и нужно быстро понять, что нужно сделать.

Задача — помочь клиенту

Есть две команды — заказчика и вендора. Со стороны вендора ее состав обычно такой:

  • проектный менеджер или человек, который отвечает за продажу;
  • бизнес-аналитик;
  • дизайнер;
  • технический эксперт.

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

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

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

Важен опыт команды

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

Я приведу пример. В вашем распоряжении есть ровно месяц, чтобы понять, какой scope нужен, и подготовить коммерческое предложение. Если ваш дизайнер junior, то вложиться в 1 месяц будет очень сложно, потому что он будет медленно создавать нужные прототипы. Из-за этого будет затягиваться и последующая работа всей команды и проекта.

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

Не скупитесь на профессиональные кадры для продажи и запуска проекта, это поможет команде стартовать с меньшими проблемами.

Слаженность команды

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

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

Ваша задача как профессионала — рассказать последовательность ваших действий, объяснить, какая помощь для этого нужна. То есть разложить клиенту все по полочкам. Для этого и нужны kick-off, где вы представляете свою команду, рассказываете, чем вы будете заниматься, какая дальнейшая работа. Конечно же project manager может рассказать глобально, но за то, как будет проходить процесс сбора требований, ответственны именно вы!

Заказчик — это группа людей, работников компании, которые занимались своей рутинной работой каждый день. Они, возможно, никогда не сталкивались с процессом сбора требований. Помогите им, рассказывайте, делайте, не бойтесь. Вы профессионал в этом деле и вы должны драйвить.

Обязанности бизнес-аналитика на дискавери-фазе

После проведенных встреч, обсуждений и наблюдений у вас должен быть целый перечень артефактов для дальнейшей работы над продажей проекта:

  • Use cases — основные сценарии работы с системой или приложением.
  • Бизнес-процессы. Вы должны посмотреть, какие процессы уже есть и попытаться описать, какими они должны быть. Процессы всегда есть, даже если они не описаны. Почитайте про концепт (as is / to be).
  • Должностные инструкции. В любой компании, особенно большой, есть такие инструкции. Ознакомьтесь с ними, узнайте, чем занимаются люди и что входит в их обязанности.
  • Отчеты. Найдите все отчеты, которые используются внутри компании. Это поможет вам понять структуру данных, что есть на сегодняшний день и чего не хватает для полной картины.
  • Скриншоты текущих систем. Делайте скриншоты всего, что только можно — чтобы было с чего начать и не придумывать с нуля.
  • User stories — если после дискавери-фазы у вас нет списка user stories с высокоуровневыми описанием требований, значит вы провалили эту фазу!

Если вы крутой бизнес-аналитик, то вы должны с самого начала создавать и структурировать backlog. Рекомендации:

  • Будьте проактивными и направляйте клиента, потому что не он делает проект, а именно вы!
  • В момент выявления или сбора требований нужно делать assumptions (предположения). Это поможет вам в будущем при оценке проекта и разработке.
  • Начинайте думать с самого начала категориями «epic» и «user story» — это поможет вам дальше управлять backlog’ом, который зайдет в проект.
  • Перед тем как идти на какие-либо встречи, читайте про доменную область.
  • На все встречи ходите с дизайнером, потому что вы должны понимать проект на одном уровне.
  • Не бойтесь задавать глупые вопросы. Лучше задать глупые вопросы и выдать хороший результат, чем не спросить ничего и облажаться. Эта мудрость пришла ко мне с годами :)

Обязанности дизайнера

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

Если речь идет о разработке программного обеспечения для внутреннего использования, не придумывайте велосипед. Так и скажите дизайнеру — не нужно изобретать то, что только затруднит работу пользователя внутри организации. Интерфейс должен быть как можно проще, и желательно, чтобы он имел схожие паттерны поведения с глобальными продуктами (MS, SAP, Oracle).

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

Дизайнер обязательно должен создавать прототипы. Главная задача — показать, как будет выглядеть будущее приложение. Они помогут оценить сложность проекта. В коммерческом предложении вы будете ссылаться на дизайн, и клиенту будет все понятно.

Задача технического специалиста

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

Результаты дискавери-фазы

Результат работы бизнес-аналитика на дискавери-фазе — всевозможный материал, собранный на стороне клиента: документы, артефакты и понимание, что нужно сделать.

Почему я говорил изначально «думайте через epiс и user story»? Потому что для того, чтобы составить коммерческое предложение, вам нужно создать WBS (work breakdown structure). Каждый кусок информации, который вы получили на дискавери-фазе, поможет sales-команде построить правильное коммерческое предложение.

У вас должны быть Mockups, которые будут соответствовать требованиям, потому что они будут базисом для дальнейшей работы.

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

LinkedIn

12 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Спасибо, отличная статья,

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

Может быть даже так)

Рад, что понравилась!

Запомните: дизайнер занимается только дизайном и все! Он не придумывает требования

Такое лучше не запоминать. :) Дизайнеры, разработчики, QA могут быть отличным источником требований и решений, как в новых продуктах, так и при оптимизации существующих.

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

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

Если это проект, без технической команды со стороны заказчика, то вы абсолютно правы.
Есть проекты, в которых участвую только люди из бизнеса и им не очень понятно, что за магия происходит там в Украине, главное чтобы им показывали картинки и предлагали что-то.
Тогда, вы можете работать с командой над тем, как же реализовать в системе бизнес нужду. Но даже тут, зачастую это трата времени. Команда должна уже получать четкую готовую информацию проработанную аналитиком и дизайнером с клиентом вместе.

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

я рассказываю про

Ви розповідаєте про свій суб’єктивний досвід. Бізнес-аналіз це досить розмита штука, часто на проектах немає окремих бізнес-аналітиків, і їх функції якось розподіляють між іншими учасниками процесу.

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

Это само собой! Но у меня сложилось другое впечатление: «Я аналитик, и я описываю требования, а ты не лезь и тихо рисуй, что тебе говорят». Возможно, я ошибся, но это частая проблема. :)

Андрей, на проектах типа «Enterprise» так и есть к сожалению. Когда речь идет о корпоративных системах, то этот так. Там и аналитик и дизайнр это пушечное мясо, которое крутиться в колесе как белка :)
Тут много аспектов. Данный пост про аутсорсинг и фикс прайс проекты :)

Вероятно, Сергей, мне просто больше везло с опытом Enterprise-проектов. :) К вашему ответу выше, если и команду и заказчика устраивает, то ок, тогда понятно, почему вы описали именно такой подход. Спасибо за статью!

Так бывает лучше, если дизайнер в доменной области ни в зуб ногой, а мнение имеет.

Подписаться на комментарии