Бизнес-аналитик в распределенной команде (часть 1)

(Из ленты Курсы бизнес анализа, тренинги и обучение бизнес аналитике| ArtofBA)
В данной статье я хотел поделиться своим опытом работы в распределенной команде. Под термином «распределенная команда» я понимаю ситуацию, когда команда, создающая решение, находится не просто не в одном офисе, а в разных городах, странах, часовых поясах. Но по большому счету данные рекомендации могут быть полезны и в случае команды, работающей из одного офиса. Для начала разберемся с причинами, почему распределенные команды начали появляться все чаще. По большому счету, если вы занимаетесь не in-house разработкой, то вы работаете в распределенной команде: заказчик и команда находятся в разных местах. Но даже in-house разработка в крупных компаниях предполагает, что заказчик решения, конечные пользователи и команда будут находится в разных локациях. Но нас больше интересуют проекты, когда члены команды разработки – бизнес-аналитики, руководители проектов, разработчики и тестировщики также «разбросаны» по разным офисам. Некоторые компании, как например DataArt, занимающиеся технологическим консалтингом и разработкой заказных решений, изначально закладывают принцип распределенной команды и не ставят перед собой цель собрать под проект всех людей в одном офисе. Какие у этого есть причины? Первая причина – оптимизация затрат. Лучшее соотношение цена/качество по зарплатам специалистов, Вам не нужно арендовать дополнительные офисные помещения в Лондоне или Нью-Йорке, релоцировать специалистов и их семьи или платить сотрудникам командировочные. Вторая причина, которая, на мой взгляд, может быть даже важнее чем первая – гибкое управление ресурсами. Если у вас есть доступ к рынку труда в разных странах, то задачу быстрого найма нужных специалистов вам решить намного проще. Также распределенная команда позволяет лучше управлять рисками и в некоторых случаях закрыть требования местного законодательства. Около двух лет я работал в супер-распределенной команде. Нашим клиентом был один из крупнейших игроков финансового рынка, со штаб-квартирой в Нью-Йорке. Наша команда работала из 11 офисах в разных странах (Украина, Польша, Россия, Аргентина, США). Команда бизнес-аналитиков, работающих на стороне вендора, состояла из 18 человек. Рассмотрим проблемы, с которыми мы столкнулись и способы их решения. 1. Разные часовые пояса. Разница во времени между Нью-Йорком и Киевом – 7 часов, между Нью-Йорком и Вроцлавом – 8 часов. Чем больше разница во времени, тем меньше возможностей для проведения общих митингов, Ad Hoc коммуникаций для прояснения вопросов и решения проблем. Мы выработали для себя следующие подходы для уменьшения влияния данного фактора: a. Рекомендуемые рабочие часы
Для каждой локации определили рекомендуемые рабочие часы. Например, в Киеве бизнес-аналитики, и не только, должны были быть на связи с 12 по 19 по местному времени (или, с 5 до 12 по времени Нью-Йорка). Оставшиеся 2 часа вы могли отработать до или после указанного диапазона. b. Business Analysis Communication Plan
Мы детально прорабатывали план наших коммуникаций (Business Analysis Communication Plan). Так у нас было 2 запланированных митинга с представителями заказчика в неделю и 3 митинга с командой разработки для обсуждения историй из бэклога. Если бизнес-аналитик видел, что вопросов для обсуждения нет, митинг отменялся. c. Работа из дома
Официально была разрешена работа из дома по VPN. Если у вас запланирован важный митинг на 9 часов вечера, вы с большей готовностью примите в нем участие, если по его завершении вам не нужно будет ехать через весь город домой. d. «Будь на связи и сделай свою работу» Последнее и самое важное. Мы работали по принципу «Будь на связи и сделай свою работу». Имели значение не отсиженные часы, а достигнутый результат. 2. Одиночество Когда вы и ваша команда сидите в одном офисе, вы можете вместе пойти пообедать или выпить кофе, пообщаться на неформальные темы или обсудить рабочие вопросы. В случае распределенной команды такой возможности нет. Вы можете испытывать чувства, которые испытывал Робинзон на необитаемом острове: люди где-то есть, но здесь и сейчас вы один/одна. Что можно с этим сделать? a. Если нет возможности общаться вживую, общайтесь через skype, zoom, slack, webex. b. По возможности используйте видео-звонки. Максимальный эффект присутствия. А если ваш собеседник в момент разговора находится дома, то можете практически побывать у него в гостях. c. Создавайте отдельные неформальные чаты для обмена новостями и разговорами «за жизнь» d. Если вы лид команды, имеет смысл лично посетить локации, где сидят члены вашей команды. А если есть возможность, то собирайтесь всей командой вместе время от времени для проведения тимбилдинга и общения лицом к лицу. 3. Проблемы с коммуникацией внутри БА команды BABOK говорит о том, что в случае распределенной команды нам необходим более формальный подход к документированию требований, мы должны более детально прорабатывать наши артефакты и выбирать предиктивные подходы (predictive approach). Однако на практике распределенные команды часто работают по адаптивным методологиям (Scrum, Kanban и др.). Что у себя внедрял я: a. Единый темплейт написания требований. Это позволяет легче вводить новых сотрудников в команду, как бизнес-аналитиков, так и других членов команды. Обеспечивается лучшая полнота требований, а соответственно меньше запросов на прямые коммуникации с бизнес-аналитиком – автором требований. b. Ad hoc митинги и созвоны для обсуждения открытых вопросов. c. FYI-письма Если вся команда сидит в одной комнате, то содержание любого обсуждения/разговора автоматически доносится до всех. В распределенной команде этот принцип не работает. Поэтому мы выработали для себя правило писем «For You Information” (FYI): если узнал что-то новое/полезное – перешли коллегам с тегом «FYI» d. Оповещение об отсутствии Как я уже писал выше, мы придерживались правила «будь на связи и сделай свою работу». Оно предполагало, что вы можете покинуть рабочее место на некоторое время на протяжение рабочего дня. Но что делать, это в момент вашего отсутствия возникнет срочный вопрос или назначат ad-hoc митинг? Если ваши коллеги бизнес-аналитики будут знать о вашем отсутствии, они смогут заменить вас или, как минимум, предложить перенести обсуждение. Конечно, можно ставить оповещение в Outlook, но намного проще написать в общий ба-чат, что вас не будет ближайший час. 4. Проблемы с коммуникацией внутри команды разработки Как выстроить эффективную коммуникацию между разработчиками, тестировщиками и бизнес-аналитиками, если между сотни, если не тысячи километров? a. Регулярные grooming session Чем раньше аналитик вовлечет команду в обсуждение требований по функционалу, тем раньше будут выявлены пробелы или неточности в требованиях. Аналитику имеет смысл обсуждать с командой требования даже тогда, когда требования еще не финализированы. b. Review сессии с архитекторами Отдельно хотелось выделить необходимость ревью требований с привлечением архитекторов, работающих одновременно с несколькими командами. Они являются источником специфических требований – архитектурных ограничений. Учитывая их, мы можем улучшить качество наших требований согласно критерию «реализуемость». c. Тематические чаты Если у вас есть сложная User story/Use Case/Feature, значит с ней будет связано много обсуждений. Дабы не засорять командный чат, имеет смысл создать отдельный чат и пригласит в него всех заинтересованных лиц. Это позволит не только доносить информацию, но и хранить ее до момента завершения разработки. А потом сам бог велел занести информацию в базу знаний по проекту. d. Test case review Один из критериев качества требований – понятность. Я бы еще добавил «и доходчивость». Нам важно не только сформулировать и передать пакет с требованиями команде, но и проверить, правильно ли нас поняли. Проверка test case бизнес-аналитиком позволяет получить ответ сразу несколько вопросов: Правильно ли нас поняли тестировщики? Не содержат ли тест-кейсы сценариев, которые противоречат требованиями? Не содержат ли тест-кейсы сценариев, которые не предполагаются требованиями? Все ли сценарии, описанные в требованиях, охвачены? После первой сессии ревью вы можете быть удивлены тем, сколько ошибок и недоразумений удалось избежать. Во второй части статьи мы поговорим об особенностях работы с заказчиком и о планировании бизнес-аналитических работ в условиях распределенной команды. Тренинги от «Art of Business Analysis»: Комплексный тренинг по бизнес-анализу Базовые компетенции бизнес-аналитика Data Science и машинное обучение для бизнес-аналитиков

Источник: Бизнес-аналитик в распределенной команде (часть 1)