Как настроить работу внутри большой кросс-функциональной команды

Железные из Redmadrobot рассказывают, как отладить работу внутри команды из более семи человек так, чтобы каждый понимал свою зону ответственности, а новый специалист не тратил много времени на погружение в проект.

Для этого мы используем спринт-пульс. В статье даём заготовку этого инструмента в Miro, которую можно докрутить под свой проект, и практические советы для организации.

Предупреждён, значит, вооружен, а теперь к делу. Чем отличается спринт-пульс от спринта:

Спринт — это отрезок времени, за который Scrum-команда создаёт полезную часть продукта, которую можно выпустить в свет.

Спринт-пульс — это инструмент, который помогает минимизировать простои и выстроить работу команды во время спринта с учётом зависимостей внутри.

Мероприятия спринта поменять нельзя, а вот спринт-пульс — это та часть, которую можно настроить под конкретный проект.

Чтобы рассказать, как мы пришли к спринт-пульсу, берём в пример историю нашего проекта по созданию мобильного приложения. Но этот инструмент подходит и под другие типы проектов.

Стартовая команда проекта состояла из 6 человек: владелец продукта, менеджер проекта, UX-исследователь, арт-директор и два дизайнера. Одна итерация — одна неделя. Для всего этого подошёл Scrum.

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

Чтобы разработчики могли вовремя стартануть свою часть, их подключили к работе на пару спринтов раньше. Это время нужно было для того, чтобы команда могла продумать архитектуру приложения и настроить непрерывную интеграцию.

В это время появился вопрос — а как, собственно, можно «подружить» создание UI с кодингом? Но так, чтобы сохранился темп работы и постоянный инкремент (прирост продукта). Кроме того, команда разрослась, появились QA и четыре разработчика, пришлось увеличить срок спринта до двух недель.

Мы решили провести встречи с тимлидами по направлениям и с владельцем продукта со стороны клиента.

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

В процессе анализа работы мы поняли, что нам нужно что-то большее, чем мероприятия Scrum, для того чтобы всё работало чётко.

Собрав информацию, мы нашли и зафиксировали зависимости внутри команды: что после чего идёт и в какой промежуток времени должно быть сделано — всё это и стало спринт-пульсом.

Последний этап — интегрировать спринт-пульс в сам спринт.

Спринт-пульс со стикеров и бумаги мы пересобрали в Miro. Вообще, можно использовать любую другую программу (хоть на физических носителях, если удобно). Главное, чтобы все участники спринта могли в любое время посмотреть на схему: синхронизироваться по времени, задачам и связью с другими подкомандами.

Несколько ситуаций, с которыми нам помогает справляться инструмент. Это именно наш опыт. И конечно же, это не весь список. У каждого пользователя спринт-пульса он может быть свой.

По правилам Scrum, команда сама должна выстроить работу внутри спринта, опираясь на его мероприятия. Но проблема номер раз — у членов команды разный уровень способностей в коммуникациях и организованности. Два — чтобы наладить коммуникацию и процессы, специалистам нужно провести серию встреч, потратив на это время.

Решение: спринт-пульс — это «стартовый кит», схема работ. Сформировав его до момента, когда командам будут даны задачи, можно быстро и слаженно стартовать.

Во время работы специалисты сфокусированы на выполнении своих задач. Они могут не видеть риски и связи с коллегами.

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

Пример: тестирование приложения для банка.

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

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

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

Пример: к проекту подключается ещё один дизайнер. Ему рассказывают про проект и задачи, общекомандные и его подкоманды. Затем ему нужно пообщаться с другими дизайнерами и разработчиками. Важно узнать все тонкости, к примеру, когда он может привлечь разработчиков для оценки технической сложности спроектированной им реализации. Это занимает время и отвлекает остальных от задач, а значит, снижает её эффективность.

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

Спринт-пульс может ускорить работу, но есть случаи, когда тратить время на его организацию не стоит. Эта табличка — подсказка: если количество «нет» больше, чем «да», то, возможно, вам подойдёт другой инструмент.

Чтобы организовать спринт-пульс для своей команды, нужно ответить на шесть вопросов. Это поможет собрать информацию для выявления зависимостей и блокеров, которые нужно будет разложить на тайминг каждого спринта.

• Что и кто делает?

Вначале нужно определить направление работы: что делаем, кто делает, какая цель, что считаем за результат и так далее.

• Какие будут активности?

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

• Какие контрольные точки спринта?

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

• Какие есть связи внутри команды?

Определяем время на производство всех «зависимых» артефактов, нужных для работы других команд (например, макеты дизайнеров для разработчиков). Находим все взаимозависимости. Затем соединяем их и раскладываем на таймлайне спринта.

• Где могут быть простои?

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

• Когда командам нужно синхронизироваться?

Здесь нужно понять, на каких контрольных точках будет синхронизироваться команда. Все эти моменты фиксируем: какой результат, в каком объеме и к какому сроку должен быть готов. Мы синхронизируемся на встречах, звонках или в Slack.

Важно понимать, что на протяжении какого-то времени спринт-пульс будет «притираться» к реальностям проекта. Но даже несмотря на это, стартовать получится всё равно быстрее, чем без него.

Чтобы собрать спринт-пульс для своей команды, можно использовать вот такой шаблон. Мы указали основные моменты, дальше вы можете адаптировать всё под свой проект.

Эффективный процесс получается настроить, когда каждый специалист понимает, что, когда и зачем он делает. Для этого команду нужно синхронизировать, и спринт-пульс хорошо справляется с этой задачей.

Это дополнительный и необязательный инструмент для SCRUM-команд, но он точно полезный. Особенно, если команда кросс-функциональная и в ней больше семи человек. Спринт-пульс поможет двигаться в тайминге спринта, а вовремя завершенные спринты в свою очередь гарантируют готовый продукт к сроку.

#проект #управлениепроектами #команда #управлениекомандой #agile #scrum #спринт #инструменты #приложение #redmadrobot