Апр. 17

Как организовать работу с требованиями в распределенной команде. План действий для BA

Дистанционная работа — тренд последнего месяца (и, скорее всего, следующего тоже). Теперь не только IT, но и другие бизнесы имеют дело с распределенными командами — сотрудниками, каждый из которых работает из своего дома/локации. Я же начала работать в таком формате задолго до того, как это стало необходимостью, и сегодня хочу поделиться собственным опытом, как бизнес-аналитику организовать процесс сбора, анализа и обработки требований в распределенной команде с максимальным результатом.

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

Требования никто не читает. Что делать

До того, как попасть в Astound Commerce, я довольно долго проработала в компании, практикующей Scrum-подход к разработке. Как это принято на такого рода проектах, вся команда работала вместе в одной комнате, и живое, спонтанное общение было краеугольным камнем в процессе создания успешного решения.

Разумеется, бывали и исключения: сотрудники могли время от времени работать из дома или из другой локации, подключаясь к общению по Skype. Но так как процесс не был адаптирован к удаленной работе, во время таких отлучек я отчетливо ощущала, как падает моя продуктивность, гора неотвеченных вопросов накапливалась, и после возвращения в офис я несколько дней тратила на то, чтобы ее разгрести.

Здесь же все организовано иначе. У Astound только в Украине 5 центров разработки, а еще есть офисы в Колумбии, Словакии, Болгарии, Турции и Индии. Как правило, в проектах участвуют специалисты минимум из трех локаций, которые вдобавок часто расположены в разных часовых поясах. Поэтому подход к коммуникациям внутри команды и всех ее участников с внешним миром должен учитывать территориальную распределенность.

Не секрет, что у бизнес-аналитиков, впервые попавших в распределенную команду (особенно у тех представителей профессии, кто, как и я, относит себя к закоренелым интровертам) часто возникает соблазн просто писать документацию, отдавая ее с некоторой периодичностью на согласование команде и клиенту. Сидишь себе спокойно в офисе, оттачиваешь мастерство слога и точных формулировок — идиллия! Однако у такого подхода есть существенный недостаток: прекрасную, точную, однозначную и непротиворечивую спецификацию никто не читает. Ну, может, кроме QA-специалистов. Да и они читают невнимательно.

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

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

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

Как и с кем вести коммуникацию

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

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

менеджер проекта;
разработчики;
UX-специалист;
QA-инженеры;
архитектор решений (Solution Architect);
представители решений, с которыми мы интегрируемся;
представители заказчика.

Как часто и о чем необходимо общаться с каждой категорией, чтобы знания не терялись в недрах документации? Давайте разберемся.

Общение с менеджером проекта

Как правило, мне достаточно ежедневной получасовой синхронизационной встречи (daily sync), на которой присутствует вся команда и все обмениваются статусами выполнения работы и планами на текущий день. Такую встречу наши проектные менеджеры стараются проводить в утреннее время (если это невозможно, то во время, которое считается утренним у большей части команды). Если же возникают какие-то внештатные ситуации, то тут же, на синке, можно договориться о личной встрече (или созвоне) с менеджером в ближайшее возможное время.

Обычно эти дополнительные личные встречи длятся не больше 15-20 минут, да и необходимость в них возникает не часто. Как правило, на них мы согласовываем сроки поставки пакета требований или организационные моменты, например, необходимость подключить к решению задачи представителей других команд.

Общение с разработчиками и UX-специалистом

По мере написания требований у вас наверняка возникают вопросы вроде «А как именно работает форма, изображенная на прототипе?» или «Стоит ли сделать параметр настраиваемым?». В свою очередь, у разработчиков и UX-специалистов также могут быть вопросы по деталям функциональности, которую они в данный момент разрабатывают. Для ответов на эти и подобные вопросы у нас запланирована ежедневная встреча между бизнес-аналитиком, UX-специалистом и представителями команды разработки (обычно это лиды front-end- и back-end-команд). Конечно, одновременно собрать четырех человек бывает сложнее, чем переговорить с каждым с глазу на глаз. Однако пользу от такой встречи, когда собираются воедино «что?», «как?» и «зачем?», невозможно переоценить.

На встрече, как правило, я показываю очередную порцию написанных требований. За день объем будет небольшим, и мы его все вместе разбираем. UX-специалист также может продемонстрировать особо сложный кусок прототипа. Остаток времени посвящаем ad hoc — вопросам. Средняя продолжительность встречи — 15-30 минут. Обычно такую встречу мы проводим сразу после дневного синка. Это удобно, так как команда не успела разбежаться по своим делам. При необходимости (например, очень сложная и спорная функциональность) количество встреч можно временно увеличить до двух в день, например, одна встреча утром и одна вечером для закрепления договоренностей и окончательного разрешения всех вопросов.

Общение с QA-специалистом

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

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

Чаще всего перечисленных встреч достаточно для того, чтобы формальное согласование требований командой прошло без проблем. По мере завершения документации к отдельному модулю, если функциональность сложная или было много переделок в процессе обсуждения, я могу сделать отдельную встречу для презентации требований. На этой встрече присутствуют все вышеупомянутые специалисты: лиды разработки, UX, QA, а также по желанию — проектный менеджер и все остальные участники команды. Конечно, спланировать такую встречу бывает достаточно сложно, но поскольку она случается не очень часто (обычно не чаще, чем 5-10 раз за проект), то даже необходимость подключиться к встрече в нерабочее (плюс-минус час от обычного графика) время не вызывает дискомфорта.

Общение с архитектором решений (Solution Architect)

У бизнес-аналитика и разработчиков часто возникают вопросы, ответить на которые может только Solution Architect. Но привлекать его на ежедневной основе нецелесообразно, ведь такие специалисты нарасхват и их время стоит очень дорого. Отвлекать SA спонтанно по мере возникновения вопросов тоже не лучшая идея: без погружения в контекст человек вряд ли выдаст хорошее решение. Да и через несколько недель такого «выдергивания» он того и гляди заблокирует вас в корпоративном мессенджере. Вместо этого мы договорились созваниваться с архитектором два раза в неделю.

На встрече всегда присутствуют собственно архитектор, бизнес-аналитик, лиды разработки и лид QA. В принципе, любой член команды, если у него есть вопросы именно к SA, тоже всегда может присоединиться. Вопросы для обсуждения к этим встречам мы готовили в общем файле. Если вопросов не было (редкое событие!), то SA, просматривая файл, понимал, что встречи не будет. Если вопросы были, он мог заранее их посмотреть, на что-то ответить там же, в файле, или же подготовиться к ответу. Средняя продолжительность встречи — 30-60 минут в зависимости от фазы и сложности проекта.

Общение с представителями других команд

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

И наконец, общение с заказчиком

Как я писала выше, не стоит рассчитывать, что представители бизнеса внимательно прочитают спецификацию требований. Поэтому все вопросы, которые вызывают сомнение, лучше обсуждать с заказчиком заранее. Обычно мы планируем одну-две еженедельные встречи длительностью 30-60 минут для обсуждения открытых вопросов, которые я готовлю заранее (обычно в тикетах Jira). Таким образом, заказчик осведомлен, о чем мы собираемся его спрашивать, и может подготовиться.

Обычно этих встреч достаточно для безболезненного утверждения документации и, что важнее, для относительно безболезненного прохождения приемочного тестирования. Впрочем, иногда по желанию клиента (а точнее, по нежеланию вникать в формальный текст спецификации) мы проводим ревью требований. Такое ревью осуществляется для наиболее важных модулей продукта. На встрече я достаточно бегло прохожусь по всем требованиям к модулю, концентрируясь на критичных для работы и настройки продукта моментах, и человеческим языком объясняю, что именно скрывается за сухим формальным текстом спецификации и что конкретно будет или не будет реализовано. Длительность таких встреч — не более часа, частота — примерно раз в две-три недели.

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

Результаты и выводы

И напоследок немного статистики. Для примера я взяла несколько своих проектов приблизительно одинаковой сложности. На двух из них я работала без предварительно составленного плана вовлечения заинтересованных лиц, то есть фактически рассчитывая только на результаты ревью требований и на ad hoc обсуждение в личной переписке. На третьем проекте коммуникации были спланированы так, как описано в статье. Метрикой является количество комментариев команды и клиента, повлекших за собой правки функциональных требований, созданных после того, как документ уже был согласован.

Проект	Тип коммуникации	Количество документов (общее)	Количество правок (общее)	Среднее количество правок на документ
Проект № 1	Ad hoc + формальные синкапы	25	33	1,3
Проект № 2	Ad hoc + формальные синкапы	23	42	1,8
Проект № 3	По плану	25	15	0,6

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

Тем же, кто только начинает составлять подобный график, рекомендую выполнить следующие действия:

Определите круг заинтересованных лиц. За основу можно взять всех перечисленных в этой статье (это необходимый минимум), а также добавить к списку тех, кто, по вашему мнению, должен предоставлять информацию на регулярной основе или же кого необходимо регулярно информировать. Это может быть, например, спонсор проекта, представители команды поддержки, представители юридического отдела и прочие специалисты.
Подумайте, как часто и как долго вам нужно общаться с представителями каждой из категорий в течение недели. Можно начать с получасовых встреч раз в неделю, увеличивая их продолжительность и частоту, как только станет очевидно, что этого недостаточно.
Совместно с участниками договоритесь о средствах общения и распределите встречи равномерно по рабочей неделе. Подумайте: возможно, ответы, полученные на одной встрече, могут стать входной информацией для другой? Тогда эти встречи стоит поставить поближе друг к другу.

Вот и все! Планируйте правильно и общайтесь!