В данной статье я хотел поделиться своим опытом работы в распределенной команде. Под термином «распределенная команда» я понимаю ситуацию, когда команда, создающая решение, находится не просто не в одном офисе, а в разных городах, странах, часовых поясах. Но по большому счету данные рекомендации могут быть полезны и в случае команды, работающей из одного офиса.
Для начала разберемся с причинами, почему распределенные команды начали появляться все чаще. По большому счету, если вы занимаетесь не in-house разработкой, то вы работаете в распределенной команде: заказчик и команда находятся в разных местах. Но даже in-house разработка в крупных компаниях предполагает, что заказчик решения, конечные пользователи и команда будут находится в разных локациях. Но нас больше интересуют проекты, когда члены команды разработки – бизнес-аналитики, руководители проектов, разработчики и тестировщики также «разбросаны» по разным офисам. Некоторые компании, как например DataArt, занимающиеся технологическим консалтингом и разработкой заказных решений, изначально закладывают принцип распределенной команды и не ставят перед собой цель собрать под проект всех людей в одном офисе. Какие у этого есть причины? Первая причина – оптимизация затрат. Лучшее соотношение цена/качество по зарплатам специалистов, Вам не нужно арендовать дополнительные офисные помещения в Лондоне или Нью-Йорке, релоцировать специалистов и их семьи или платить сотрудникам командировочные. Вторая причина, которая, на мой взгляд, может быть даже важнее чем первая – гибкое управление ресурсами. Если у вас есть доступ к рынку труда в разных странах, то задачу быстрого найма нужных специалистов вам решить намного проще. Также распределенная команда позволяет лучше управлять рисками и в некоторых случаях закрыть требования местного законодательства.
Около двух лет я работал в супер-распределенной команде. Нашим клиентом был один из крупнейших игроков финансового рынка, со штаб-квартирой в Нью-Йорке. Наша команда работала из 11 офисах в разных странах (Украина, Польша, Россия, Аргентина, США). Команда бизнес-аналитиков, работающих на стороне вендора, состояла из 18 человек. Рассмотрим проблемы, с которыми мы столкнулись и способы их решения.
1. Разные часовые пояса.
Разница во времени между Нью-Йорком и Киевом – 7 часов, между Нью-Йорком и Вроцлавом – 6 часов. Чем больше разница во времени, тем меньше возможностей для проведения общих митингов, 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 бизнес-аналитиком позволяет получить ответ сразу несколько вопросов:
Правильно ли нас поняли тестировщики?
Не содержат ли тест-кейсы сценариев, которые противоречат требованиями?
Не содержат ли тест-кейсы сценариев, которые не предполагаются требованиями?
Все ли сценарии, описанные в требованиях, охвачены?
После первой сессии ревью вы можете быть удивлены тем, сколько ошибок и недоразумений удалось избежать.
Во второй части статьи мы поговорим об особенностях работы с заказчиком и о планировании бизнес-аналитических работ в условиях распределенной команды.
Из-за разницы в менталитете проблемы регулярно. С ними можно побороться только проработав с конкретными людьми длительное время. Плюс гибкость/адаптивность/эмпатия. По поводу пассивного участия в митингах. Есть отличный термин "Хай-бай митинг" (hi-bye meeting). Это митинг, где ты в начале говоришь "hi!", а в конце "Bye!" и больше ничего. @Таня, если тебе есть что сказать по этому поводу, пиши заметку и мы ее с удовольствием опубликуем!
Денис, спасибо большое за статью! Очень интересно было прочитать. :)
У меня к тебе 2 вопроса:
1. Не было ли у тебя в такой многонациональной команде проблемы с коммуникацией из-за разницы в менталитете?
2. Не было ли проблемы пассивного участия в митингах некоторых приглашённых ? ( человек участвует в митинге, но по дальнейшему общению, ты понимаешь, что он из митинга ничего не вынес)
Денис, спасибо за комментарий. О соц.сетях и small talk будет в следующей части, посвященной работе с заказчиком на расстоянии :)
Очень хорошие советы, многие из них использую!
По первому разделу - рекомендую поставить на телефон https://www.worldtimebuddy.com, очень сильно облегчает жизнь.
И насчет раздел "2. Одиночество" - рекомендую найти коллег в соц. сетях (лучше всего в инстаграме, контент там более личный) и регулярно просматривать. Это конечно не замена живому общению, но таким образом получается чуть лучше познакомиться с коллегами, и появляется много тем на "small talk".