В своей работе вижу, что бизнес-аналитики в начале работы над проектом, совершают одни и те же ошибки. Поэтому, в статье собрал практические советы из моего опыта и опыта коллег: какие шаги в начале повысят вероятность успешного окончания.
Цель этих советов — подготовить бизнес-аналитиков к реалиям IT-проектов.
И первое, что нужно сделать, прежде чем погружаться в работу, — оценить, насколько сложным будет проект. Предварительная оценка поможет спрогнозировать риски и подготовиться к трудностям.
Оценить сложность проекта
Для понимания сложности, проекты удобно классифицировать по типу клиента, размеру проекта, типу контракта и методологиям. В каждой из категорий есть вариант попроще и посложнее.
Тип клиента
Проще будет работать с ISV — Independent Soft Vendor, компанией, которая сама производит программное обеспечение. В эту же категорию можно отнести STARTUP. Компании ISV нанимают для работы дополнительных подрядчиков — вендоров, часто из Украины, Белоруси, России.
С клиентами по типу ISV проще наладить контакт и общаться, потому что они знают специфику производства ПО, используют техническую терминологию, понимают все нюансы.
Сложнее работать с Enterprise клиентами. Как правило, — это большая организация или предприятие, далекое от сферы IT, например, завод, сеть больниц, реальный бизнес, который решил диджитализироваться.
Enterprise клиент привлекает вашу компанию как вендоров, для реализации нужного решения: оптимизации процессов, внедрения функций либо полной диджитализации предприятия.
Enterprise компании сложнее по двум причинам:
- Не понимают, как пишется программное обеспечение, не знают, что такое SDLS, да, в принципе, и не должны. Подход у них такой: мы заплатили деньги, — сделайте нужное решение.
- В крупных организациях больше бюрократии: согласований, политики, дополнительных нюансов и самих стейкхолдеров.
Размер и сроки
Легче разобраться с краткосрочным проектом, в котором немного заинтересованных лиц: один представитель со стороны клиента, и маленькая команда для выполнения целей проекта.
В категорию сложных относят длительный проект, для которого понадобятся несколько команд разработки и будет много стейкхолдеров со стороны клиента. Чем больше команд, тем больше нужно коммуникации и постоянной синхронизации действий всех участников.
Тип контракта
Просто — это Dedicated Team, который еще называют Time and Material. В этом случае команда трудится над продуктом, — а компания получает деньги за время, отработанное командой. Допустим, команда проработала месяц, — выставили счет. Счет оплатили, работаем дальше, и через месяц выставляем следующий счет.
Контракт Time and Material достаточно простой, потому что у него нет особых ограничений: команда работает, создает продукт и получает деньги.
Сложнее работать с Fixed Price. Такой тип контракта означает, что к фиксированной цене прилагается фиксированный срок, за который команда должна выдать оговоренный кусок работы.
В Fixed Price появляется сложность, характерная именно для работы ВА: Scope Creep — расползание объема работы.
Один из примеров, как происходит scope creep. С клиентом договорились на определенный объем, есть четкий срок окончания проекта, фиксированная стоимость — работа началась. Но тут заказчик начинает генерировать дополнительные «хотелки» или функциональность, и бизнес-аналитик понимает, что нужно сделать больше чем планировали. Объем работы увеличивается, при этом, как правило, дедлайн остается прежним и цена тоже.
Задача ВА в этой ситуации — как можно раньше идентифицировать вещи, связанные с расползанием скоупа. Иногда придется жестко общаться с заказчиком, пытаясь отказаться от новых видений или настаивать, что дополнительные требования не были прописаны, поэтому нужно отодвинуть дедлайн.
Методология
Для разработки проектов используют два основных направления методологий: Agile и Waterfall.
Обе методологии имеют право на существование, хотя в аутсорс проектах сейчас распространен гибкий подход. Продукт разрабатывают итеративно: по спринтам длительностью от 2 до 4 недель. В конце каждого спринта клиент получает готовый инкремент продукта и сразу может с ним работать: пользоваться, собирать фидбек и т. д.
Waterfall менее гибок, потому что конечный продукт и решение определены заранее, и команда должна воплотить их максимально подробно. Требования в Waterfall долго собираются и выверяются до последней запятой еще до начала разработки.
Жесткая методология важна для продуктов, где высока цена ошибки, например, программное обеспечение для аппарата, который делает глазные операции с помощью лазера.
Здесь не подойдет подход: Быстро написали приложение и отдали, а если во время операции произошло что-то плохое, команда говорит: «Ну, фидбек не очень хороший, но в следующей версии мы его допишем, переделаем, и снова выкатим на рынок».
В ситуации с высокой ценой ошибки, работают по Waterfall: очень долго описывают, выверяют все возможные требования, затем требования проходят аудит и сертификацию и только потом имплементируют. При жестком подходе работать сложнее: цена ошибки выше и нужно предусмотреть все уже с первой попытки, на этапе написания требований.
Подведем итог краткого экскурса в категории проектов:
- Самым простым вариантом будет ISV проект или Startup, с небольшой командой и короткими сроками выполнения.
- Сложные проекты относятся к Enterprise клиентам, долгосрочным проектам с большим количеством стейкхолдеров.
Чем больше нужной информации о проекте и требованиях стейкхолдеров выяснил ВА на старте, тем меньше будет изменений в процессе, и тем лучшие способы решения бизнес-задач сможет найти аналитик.
В начале важно разобраться с контекстом проекта, а дальше бизнес-аналитику нужно понять собственную зону ответственности и поработать с ожиданиями остальных участников.
Понять свою зону ответственности
Прежде чем создать правильные ожидания от работы ВА у остальных участников, нужно самому понять, чем занимается ВА на проекте и как распределяются зоны ответственности в команде.
За какие задачи отвечает BA:
- анализирует бизнес потребности, контекст, стейкхолдеров;
- собирает требования;
- управляет требованиями;
- коммуницирует требования;
- отвечает за содержание продукта;
- контролирует задачи, связанные с приемкой функционала.
Если обобщить, то бизнес-аналитик отвечает за все задачи, связанные с требованиями, скоупом, содержанием продукта и приемкой функционала. Но бывает и так, что перед бизнес-аналитиком ставят другие задачи, несвойственные этой роли.
Чем ВА заниматься НЕ должен:
- Распределение задач между разработчиками (решать, кому из разработчиков какую задачу поручить).
- Равномерная нагрузка команды работой.
- Commitment команды — обещание команды сделать конкретный функционал, типичное для agile и скрама. Например, команда обещает, что к следующей итерации сделают определенную часть функционала.
- Принятие технических решений, потому что за это отвечают другие люди.
- Подсчет времени (сколько кто потратил на задачу) и различный reporting.
- Распределение зарплат и премий.
По-моему опыту, активности, несвойственные роли ВА, не только мешают выполнять прямые обязанности, но и провоцируют конфликты.
Например, если ВА вовлечен в commitment команды, это помешает управлять требованиями: аналитик будет подстраивать требования под обещание команды, или не примет commitment, зная, что в требования по желанию клиента включены вещи, с которыми ВА не согласен.
Чтобы не возникало ситуаций, при которых ВА выполняет чужие обязанности, нужно сразу выяснить, чего ждут от бизнес-аналитика в конкретном проекте.
Работать с ожиданиями
Неправильная работа с ожиданиями приведет к ошибкам в коммуникации, взаимному недовольству и конфликтам. Ошибочные представления о роли ВА, могут появиться как со стороны самого бизнес-аналитика, так и со стороны команды или РМ-а.
Чтобы разобраться с ожиданиями, на старте проекта нужно пройти через три этапа: базовый анализ стейкхолдеров, прояснение ожиданий с РМ-ом, формирование ожиданий у команды и клиента.
Провести базовый stakeholder analysis
Анализ всех стейкхолдеров и связей между ними — одно из начальных действий ВА на проекте. С первых дней работы бизнес-аналитик выясняет:
- структуру команды и количество людей, с которыми ВА будет работать;
- структуру управления — кто кому подчиняется и перед кем отчитывается;
- клиент — какой у него бэкграунд, ожидания, приоритеты.
В нормальной ситуации, РМ проводит для бизнес-аналитика онбординг и отвечает на вопросы. Если этого не произошло, нужно проактивно найти ответы, потому что stakeholder analysis дает важный контекст, из которого будет следовать остальные решения ВА по работе с ожиданиями.
Понять ожидания РМ-а
С РМ-ом бизнес-аналитику приходится общаться чаще всего, поскольку это главный человек, отвечающий за проект. Задача РМ-а — реализовать проект согласно контракта, уложившись в сроки, бюджет, объем работы, качество.
Для достижения цели проектному менеджеру от бизнес-аналитика нужны две глобальных вещи:
- Бэклог, проработанный на много горизонтов вперед. Под горизонтом будем понимать спринты либо какие-то временные отрезки.
- Постоянный объем работы для команды.
На каждом конкретном проекте у РМ-а будут дополнительные ожидания. Если бизнес-аналитик не старте не выяснил, как менеджер представляет обязанности ВА, — позднее не избежать конфликтов.
Как выяснить, чего ждет РМ:
- Встретиться «один-на один» и прямо попросить рассказать, как РМ видит позицию ВА на проекте и за что бизнес-аналитик должен отвечать.
- Попросить сформулировать информацию тезисно: на доске, бумаге, email.
Если информацию или ответ на вопрос не просто проговаривать, а прописывать, человеку придется выбирать конкретные и понятные формулировки. Это очень хороший метод: он работает и с клиентами, и с любыми стейкхолдерами.
Почему нельзя обойтись просто описанием обязанностей в вакансии, а нужно обязательно поговорить с РМ-ом?
Как правило, описания вакансии слишком общие. Не достаточно и базового job description, который есть в компании, потому что он тоже оторван от контекста. А вам важны особенности, понимание, чего конкретный РМ ожидает от конкретного ВА на конкретном проекте.
Если ваши ожидания от позиции ВА не совпадают с видением РМ-а, — это лучше выяснить сразу. Иначе может быть так, что РМ и команда ждут от вас чего-то, о чем вы не знаете, и на этой почве начинаются конфликты.
Позиция ВА — это не что-то максимально точное и определенное, не существует «эталонного ВА из палаты мер и весов». Обязанности сильно зависят от контекста проекта, клиента, компании. Поэтому прояснить ситуацию в самом начале сотрудничества с РМ-ом и командой — обязательно, если хотите избежать конфликтов.
Создать ожидания у команды и клиента
Когда есть понимание, чего РМ ждет от бизнес-аналитика, — нужно создать ожидания у команды и клиента, то есть, объяснить, чем ВА будет заниматься, за что отвечать. Молодые бизнес-аналитики часто пренебрегают этим этапом, потому что думают, что все и так знают, чем они занимаются на проекте.
На самом деле, у вас может быть команда или часть команды, которые никогда не работали с ВА или работали в совершенно других условиях, где от ВА требовались другие вещи. Клиент тоже иногда не понимает, для чего нужен бизнес-аналитик, и чем он занимается на проекте.
Как ВА может сформировать ожидания:
- Сделайте небольшую презентацию и попросите 15 минут у команды, чтобы рассказать о себе и своей роли на проекте. Расскажите, чем будете заниматься, какую пользу приносить и почему хорошо, когда на проекте есть бизнес-аналитик.
- Объясните ground rules — правила работы с вами. Они могут быть совершенно разными.
Вместо вывода: 5 советов, как не провалить первый проект
1.Не бойтесь сказать, если что-то непонятно. Приходя на проект, новички думают, что должны сразу все суметь и смочь, поэтому стараются выполнить любую задачу, не задавая «лишних» вопросов.
2. Не бойтесь просить помощи на раннем этапе. Если вы ощущаете, что можете с чем-то не справиться, поднимите руку и скажите: «Ребята, мне кажется, я сам могу не справиться, нужна помощь». Либо: «Я чего-то не понимаю, мне нужна помощь».
Как правило, новые ребята самостоятельно пытаются решить задачу изо всех сил, до момента, когда уже реально поздно. И когда ВА, в конце концов говорит, что не смог справиться с задачей, помочь уже гораздо сложнее.
3. Избегайте паралича анализа. Паралич возникает, когда мы видим несколько вариантов развития событий, и все кажутся равноценными, поэтому невозможно принять решение: «Надо бы за этот кусок требований взяться, но тут все зависит от вот этого, а это тоже непонятно. А если взяться за другое, то оно тоже зависит еще от чего-то». Окончательное решение принять невозможно, и мы сидим, как парализованные.
Хороший способ избежать паралича анализа — это решение, которое мой друг называет «типичное не то».
Например, вы хотите что-то с клиентом обсудить, какие-то задачи, вопросы, но клиент говорит:
— Слушай,вообще ничего пока не ясно, давай потом.
И можно на этом остановиться. Но лучше, исходя из ваших допущений, сделать что-то и показать клиенту — описание требований, диаграмму, рисунок. Это и будет «типичное не то». Принести и сказать:
— Я вижу таким образом. Как считаете — так это или нет?
Скорее всего, вам не скажут:
— Не хочу смотреть, давай потом.
А все-таки посмотрят и уточнят:
— Вот это совсем не годится, здесь правильно, здесь поменять.
К этому моменту становится более-менее понятно, что делать, и можно потихоньку выходить из паралича.
4. Внятно коммуницируйте риски, когда видите, что есть какие-то подозрения. Как можно раньше нужно уведомить о рисках всех, кого это касается. Чем раньше вы об этом заявите, тем меньше проблем может произойти потенциально.
5. И главное, помните, что провалить проект в одиночку практически невозможно — это «командная» работа. Проект нельзя провалить по вине одного человека. Надо это понять, делать свою работу, и не нервничать, что только из-за вас все может испортиться.