Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Как организовать работу с требованиями в распределенной команде. План действий для 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 обсуждение в личной переписке. На третьем проекте коммуникации были спланированы так, как описано в статье. Метрикой является количество комментариев команды и клиента, повлекших за собой правки функциональных требований, созданных после того, как документ уже был согласован.

ПроектТип коммуникацииКоличество документов (общее)Количество правок (общее)Среднее количество правок на документ
Проект № 1Ad hoc + формальные синкапы25331,3
Проект № 223421,8
Проект № 3По плану25150,6

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

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

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному7
LinkedIn

Схожі статті




15 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Спасибо за статью. Для трех проектов-примеров была, на ваш взгляд, разница в скорости запиливания от-до? И насколько для вашей практики релевантна токсичная реакция команды на большую долю рабочего времени, уходящего на митинги?

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

Что до второго вопроса: по моему опыту команда гораздо лучше воспринимает запланированные заранее встречи с понятной повесткой, чем внезапное выдергивание потому, что «очень надо срочно спросить». Кроме того, тщательно спланированное общение отнимает меньше времени команды, т.к. меньше времени теряется на нерезультативном общении.

Дякую, корисна стаття!

Неожиданно интересная кейсовая статья на доу.

Не хватило описания вообще процесса, чтобы понять лучше, куда эти все встречи становятся. Тогда уже можно дискутировать с Денисом по вопросу трудозатрат =) Но в целом интересно.

Можно со мной подискутировать, хоть я и не Денис :-) Процесс может быть любой, и адаптивный (agile подход) и предиктивный. В статье я говорю о том, как структурировать общение, это не зависит от подхода.
Мое мнение — планирование и структуризация общения трудозатраты сокращает, так как на выходе получаем меньше общения с нулевым выхлопом (а при ad-hoc общении выхлоп часто бывает нулевой, т.к. участники не всегда готовы предметно отвечать на вопросы, которые им вдруг решили задать :-) )

А не получается, что количество отвлечений наиболее опытных специалистов на встречи превышает затраты при разработке без документации (SCRUM / lean / kanban)? Да, без документации будут делаться ошибки, но если есть представитель заказчика (product owner), эти ошибки будут быстро замеяать и исправлять, и через пару месяцев программисты или лиды начнут с ним консультироваться по большинству фич, и количество ошибок сойдет на нет.

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

Вообще-то гибкий подход как раз позволяет сократить объем документации за счет активного и часто спонтанного общения (возник вопрос — сбегал к продакту за ответом).

Вот я не понимаю, зачем при таком подходе вообще документация. То есть, какая именно? Руководство для пользователей — может быть, но это — дело тех писателя, а не БА. Вики и диаграммы архитектуры для программистов — дело рук самих программистов.

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

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

Для этого разработчики пишут свою внутреннюю вики.

Или, чтобы наткнувшись на код, который реализует странную функциональность, команда понимала, откуда это взялось, а не пожимала плечами «так исторически сложилось».

Для этого уменьшают текучку кадров, и тогда лид или архитектор помнит. Если не помнит — делается git blame, он указывает на задачу, в рамках которой был добавлен код. А в задаче ПМ или ПО (или QA) пишет, для чего задача нужна.

Обычно документируются самые важные, критичные для системы, требования.

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

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

То есть, Вы как БА заводите все задачи на новые фичи? Тогда — ни о чем не спорим. Но указали бы в статье, что это все не про документацию, а про создание задач в трекере.

Статья об организации общения, а не о документации или задачах :-)

Вот я подозреваю, что организация общения вредит производственному процессу.
en.wikipedia.org/wiki/Law_of_triviality
wiki.c2.com/?DeathByPlanning
blablablogorg.files.wordpress.com/2017/10/meetings2.png

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