IAMPM
65000
+38 (091) 481 01 38+7 (495) 128 58 05info@iampm.club

Что важно сделать бизнес-аналитику на старте проекта

21 октября 2020

  • Автор: Кирилл Белявский

  • Сложность: не сложно

  • Время: 8 мин

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

Цель этих советов — подготовить бизнес-аналитиков к реалиям IT-проектов. 

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

Оценить сложность проекта 

что делать BA на старте проекта 1

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

Тип клиента

Проще будет работать с ISV — Independent Soft Vendor, компанией, которая сама производит программное обеспечение. В эту же категорию можно отнести STARTUP. Компании ISV нанимают для работы дополнительных подрядчиков — вендоров, часто из Украины, Белоруси, России. 

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

Сложнее работать с Enterprise клиентами. Как правило, — это большая организация или предприятие, далекое от сферы IT, например, завод, сеть больниц, реальный бизнес, который решил диджитализироваться. 

Enterprise клиент привлекает вашу компанию как вендоров, для реализации нужного решения: оптимизации процессов, внедрения функций либо полной диджитализации предприятия. 

Enterprise компании сложнее по двум причинам:

  1. Не понимают, как пишется программное обеспечение, не знают, что такое SDLS, да, в принципе, и не должны. Подход у них такой: мы заплатили деньги, — сделайте нужное решение.
  2. В крупных организациях больше бюрократии: согласований, политики, дополнительных нюансов и самих стейкхолдеров.

Размер и сроки 

Легче разобраться с краткосрочным проектом, в котором немного заинтересованных лиц: один представитель со стороны клиента, и маленькая команда для выполнения целей проекта.

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

Тип контракта

Просто — это Dedicated Team, который еще называют Time and Material. В этом случае команда трудится над продуктом, — а компания получает деньги за время, отработанное командой. Допустим, команда проработала месяц, — выставили счет. Счет оплатили, работаем дальше, и через месяц выставляем следующий счет. 

Контракт Time and Material достаточно простой, потому что у него нет особых ограничений: команда работает, создает продукт и получает деньги.

Сложнее работать с Fixed Price. Такой тип контракта означает, что к фиксированной цене прилагается фиксированный срок, за который команда должна выдать оговоренный кусок работы. 

В Fixed Price появляется сложность, характерная именно для работы ВА: Scope Creep — расползание объема работы. 

Один из примеров, как происходит scope creep. С клиентом договорились на определенный объем, есть четкий срок окончания проекта, фиксированная стоимость — работа началась. Но тут заказчик начинает генерировать дополнительные «хотелки» или функциональность, и бизнес-аналитик понимает, что нужно сделать больше чем планировали. Объем работы увеличивается, при этом, как правило, дедлайн остается прежним и цена тоже. 

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

Методология

Для разработки проектов используют два основных направления методологий: Agile и Waterfall. 

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

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

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

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

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

что делать BA на старте проекта 2

Подведем итог краткого экскурса в категории проектов: 

  • Самым простым вариантом будет ISV проект или Startup, с небольшой командой и короткими сроками выполнения.
  • Сложные проекты относятся к Enterprise клиентам, долгосрочным проектам с большим количеством стейкхолдеров. 

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

Понять свою зону ответственности

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

За какие задачи отвечает BA:

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

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

Чем ВА заниматься НЕ должен:

  • Распределение задач между разработчиками (решать, кому из разработчиков какую задачу поручить).
  • Равномерная нагрузка команды работой.
  • Commitment команды — обещание команды сделать конкретный функционал, типичное для agile и скрама. Например, команда обещает, что к следующей итерации сделают определенную часть функционала.
  • Принятие технических решений, потому что за это отвечают другие люди.
  • Подсчет времени (сколько кто потратил на задачу) и различный reporting.
  • Распределение зарплат и премий. 

По-моему опыту, активности, несвойственные роли ВА, не только мешают выполнять прямые обязанности, но и провоцируют конфликты. 

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

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

Работать с ожиданиями 

Неправильная работа с ожиданиями приведет к ошибкам в коммуникации, взаимному недовольству и конфликтам. Ошибочные представления о роли ВА, могут появиться как со стороны самого бизнес-аналитика, так и со стороны команды или РМ-а. 

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

Провести базовый stakeholder analysis

Анализ всех стейкхолдеров и связей между ними — одно из начальных действий ВА на проекте. С первых дней работы бизнес-аналитик выясняет: 

  • структуру команды и количество людей, с которыми ВА будет работать;
  • структуру управления — кто кому подчиняется и перед кем отчитывается;
  • клиент — какой у него бэкграунд, ожидания, приоритеты.

В нормальной ситуации, РМ проводит для бизнес-аналитика онбординг и отвечает на вопросы. Если этого не произошло, нужно проактивно найти ответы, потому что stakeholder analysis дает важный контекст, из которого будет следовать остальные решения ВА по работе с ожиданиями. 

Понять ожидания РМ-а 

что сделать BA на старте проекта 3

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

Для достижения цели проектному менеджеру от бизнес-аналитика нужны две глобальных вещи:

  1. Бэклог, проработанный на много горизонтов вперед. Под горизонтом будем понимать спринты либо какие-то временные отрезки.
  2. Постоянный объем работы для команды. 

На каждом конкретном проекте у РМ-а будут дополнительные ожидания. Если бизнес-аналитик не старте не выяснил, как менеджер представляет обязанности ВА, — позднее не избежать конфликтов.

Как выяснить, чего ждет РМ:

  • Встретиться «один-на один» и прямо попросить рассказать, как РМ видит позицию ВА на проекте и за что бизнес-аналитик должен отвечать.
  • Попросить сформулировать информацию тезисно: на доске, бумаге, email.

Если информацию или ответ на вопрос не просто проговаривать, а прописывать, человеку придется выбирать конкретные и понятные формулировки. Это очень хороший метод: он работает и с клиентами, и с любыми стейкхолдерами. 

Почему нельзя обойтись просто описанием обязанностей в вакансии, а нужно обязательно поговорить с РМ-ом?

Как правило, описания вакансии слишком общие. Не достаточно и базового job description, который есть в компании, потому что он тоже оторван от контекста. А вам важны особенности, понимание, чего конкретный РМ ожидает от конкретного ВА на конкретном проекте. 

Если ваши ожидания от позиции ВА не совпадают с видением РМ-а, — это лучше выяснить сразу. Иначе может быть так, что РМ и команда ждут от вас чего-то, о чем вы не знаете, и на этой почве начинаются конфликты. 

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

Создать ожидания у команды и клиента

Когда есть понимание, чего РМ ждет от бизнес-аналитика, — нужно создать ожидания у команды и клиента, то есть, объяснить, чем ВА будет заниматься, за что отвечать. Молодые бизнес-аналитики часто пренебрегают этим этапом, потому что думают, что все и так знают, чем они занимаются на проекте. 

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

Как ВА может сформировать ожидания:

  • Сделайте небольшую презентацию и попросите 15 минут у команды, чтобы рассказать о себе и своей роли на проекте. Расскажите, чем будете заниматься, какую пользу приносить и почему хорошо, когда на проекте есть бизнес-аналитик. 
  • Объясните ground rules — правила работы с вами. Они могут быть совершенно разными. 

Вместо вывода: 5 советов, как не провалить первый проект

1.Не бойтесь сказать, если что-то непонятно. Приходя на проект, новички думают, что должны сразу все суметь и смочь, поэтому стараются выполнить любую задачу, не задавая «лишних» вопросов. 

2. Не бойтесь просить помощи на раннем этапе. Если вы ощущаете, что можете с чем-то не справиться, поднимите руку и скажите: «Ребята, мне кажется, я сам могу не справиться, нужна помощь». Либо: «Я чего-то не понимаю, мне нужна помощь». 

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

3. Избегайте паралича анализа. Паралич возникает, когда мы видим несколько вариантов развития событий, и все кажутся равноценными, поэтому невозможно принять решение: «Надо бы за этот кусок требований взяться, но тут все зависит от вот этого, а это тоже непонятно. А если взяться за другое, то оно тоже зависит еще от чего-то». Окончательное решение принять невозможно, и мы сидим, как парализованные. 

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

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

 — Слушай,вообще ничего пока не ясно, давай потом. 

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

— Я вижу таким образом. Как считаете — так это или нет?

Скорее всего, вам не скажут:

— Не хочу смотреть, давай потом. 

 А все-таки посмотрят и уточнят:

— Вот это совсем не годится, здесь правильно, здесь поменять. 

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

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

5. И главное, помните, что провалить проект в одиночку практически невозможно — это «командная» работа. Проект нельзя провалить по вине одного человека. Надо это понять, делать свою работу, и не нервничать, что только из-за вас все может испортиться.

 

 

Кирилл Белявский

Кирилл Белявский

Senior BA и сервис-менеджер в SoftServe. Более 8 лет опыта в бизнес анализе. Спикер курса I am BA. Регулярный лектор на курсах, митапах и конференциях, ведет подкаст о жизни и бизнес-анализе.