Блог

Четыре командных паттерна для эффективной поставки продукта

Статью перевел Роман Усов, Scrum Master, DatsTeam (Telegram: @romanusov)
При разработке софтовых продуктов абсолютное большинство продуктовых команд сталкиваются с одними и теми же трудностями:
  • Непонятно, насколько то, что мы сейчас делаем, действительно ценно.
  • Всё важно; много параллельной работы; невозможно сфокусироваться на чём-то одном, самом ценном.
  • Разработка идет монструозными фичами.
  • Вал незавершенной работы.
  • Релизы большие и редкие.
Большинство таких команд не знает своих клиентов и пользователей и никак не взаимодействует с ними. Главенствующая установка — мы либо поставляем сразу все, либо ничего. Каждый участник команды работает в функциональном колодце, фокусируясь на какой-то своей технической части без понимания цельной картины.
Есть четыре командных паттерна, которые помогают исправить эту ситуацию, чтобы:
  • Фокусироваться на ценности и ее быстрой поставке.
  • Быстро обучаться, чтобы поставлять то, что ждут клиенты и пользователи.
  • Получать чистый дофамин от завершения работы, которая важна клиентам и пользователям.
  • Получать кайф от совместной командной работы.

Футбольная команда

Метафора футбольной команды, наверное, лучше всего передает идею. Безусловно, не все аналогии работают; они часто ошибочны. Но некоторые очень полезны.
Команда приезжает на стадион. Ее приветствуют фанаты. Команда готовится к игре, собирается и выходит на поле. Фанаты ликуют. Звучит свисток, и команда получает мяч. Участники на поле видят друг друга. Они работают вместе, иногда небольшими группами, чтобы как можно быстрее переместить мяч по полю к воротам противника и забить гол. Победа – это забивание максимально возможного количества голов через тесное взаимодействие всей команды.
Команда всегда видит счет и оставшееся время. Они слышат реакцию болельщиков. А когда раздается свисток, они могут стремительно перегруппироваться и адаптироваться к сложившейся обстановке на поле. Команда работает как единое целое с максимальной производительностью.
Чего мы не увидим в футболе?
  • Пустого стадиона.
  • Большого количества мячей на поле, каждым из которых владеют разные участники одной и той же команды.
  • Брошенных мячей, до которых никому нет дела.
  • Поля, строго разделенного по функциональным зонам.

Паттерн 1: Прямое взаимодействие с пользователями и заинтересованными лицами

Типичная картина:

  • Между командой и пользователями/заинтересованными лицами находятся прокси.
  • Требования транслируются продуктовой команде выделенной группой специалистов.
  • С пользователями или их представителями никто не общается напрямую.
Что стоит сделать?
Демонтировать барьеры между командой и пользователями (их представителями, заинтересованными лицами). Пользователь становится в центре всего, что делает команда.
  • Команда принимает участие в сессиях по выработке стратегии продукта, дорожной карты и в проработке и детализации продуктовых фич.
  • Команда демонстрирует работающую версию продукта напрямую пользователям и получает живую обратную связь.
  • Команда собирает живые метрики продукта и строит свою дальнейшую работу на их основе.

Паттерн 2: Разрабатываем продукт тонкими срезами пользовательской функциональности

Типичный подход — «все и сразу» с монструозными релизами и заложенными в них рисками и поздним получением информации о том, действительно ли то, что мы сделали, принесло ожидаемую ценность.
При этом есть несколько ментальных установок, которые укореняют этот подход в командах:
  • Уверенность в том, что только предиктивное, детерминистическое планирование и разработка работают. Это единственный подход к организации работы.
  • Мы можем начать только после того, как все детали большой фичи будут прояснены. Только так мы можем снизить неопределенность и сложность предстоящего изменения.
  • Нужно, чтобы все были непрерывно заняты работой, даже если сейчас нам придется делать не совсем то, что является самым важным для продукта.
Ментальная модель “Мы можем все продумать и спланировать заранее” не работает.
Что использовать вместо?
Ментальную модель “Нам важно быстро обучаться, быстро узнавать, действительно ли то, что мы делаем полезно для продукта и его пользователей”. Для этого нам нужно часто выпускать, собирать живые метрики и принимать решение на их основе.
Подход к развитию продукта на основе живых данных исходит из того, что:
  • Мы не можем заранее все знать и просчитать. Мы узнаем и адаптируемся по мере продвижения.
  • Мы поставляем продукт тонкими end-to-end срезами пользовательской функциональности, рабочими пользовательскими сценариями через короткие циклы разработки.
Фокус переключается на то, чтобы видеть все “поле” и находить самый быстрый, уникальный в складывающихся обстоятельствах путь к тому, чтобы “забить гол”. Игру можно выиграть, забив максимальное количество голов, а не одновременно жонглируя максимальным количеством мячей.

Паттерн 3: Завершаем одно, прежде чем стартовать другое

Одновременный старт большого количества задач не означает прогресс и эффективность работы. При этом такой подход привычен, особенно, чтобы все были хотя бы чем-то заняты. Он поддерживается набором ментальных моделей:
  • Нам очень хочется “угодить” тем, кто ждет от нас эту работу (“Все хорошо, мы уже работаем над этим”).
  • Все важно, все задачи имеет одинаково высокий приоритет.
  • Работа заблокирована? Ок, давайте возьмем что-то еще.
  • Пусть каждый работает над своей отдельной технической частью конечной функциональности. Сделал, передал дальше.
Попробуем сменить перспективу. Нам нужно перестать начинать и начать заканчивать.
Как этого добиться?
  • Фокусируемся на одной единице работы — цели, фиче, задаче — в каждую единицу времени.
  • Если “все важно”, осознанно выбираем что-то одно, пусть даже рандомно.
  • Если работа чем-то заблокирована, останавливаемся, собираемся и прежде всего устраняем препятствие.
  • Объединяемся в кросс-функциональные команды, чтобы вместе сфокусироваться на одной, общей задаче (цели, фиче).
Наличие одного “мяча” на “поле” направляет энергию команды. Она быстро перемещает его к воротам соперника. Препятствия не проблема: команда обходит или преодолевает их вместе. Когда по “полю” разбросано много мячей, команда не может работать вместе. Нужен один мяч, одна точка фокуса.

Паттерн 4: Работаем как команда, а не группа разрозненных специалистов

Часто то, что мы называем командой, на самом деле, лишь группа разрозненных специалистов. Мы игнорируем новые свойства и способности, которые могут появляться у команды при движении к общей цели за счет тесного взаимодействия друг с другом.
Тут тоже есть укоренившиеся ментальные модели, которые определяют такой стиль работы:
  • Важно, чтобы все были хоть чем-то заняты, даже если сейчас эта работа никому особо не важна. Любой простой — величайший грех.
  • Каждый должен заниматься только своим делом в рамках узкой специализации.
  • Каждый должен работать со своей отдельной задачей. Решать задачу сообща, в паре или группе — это неэффективно.
  • Время, которое команда тратит на проработку функциональности и задач на совместных сессиях — это пустая трата времени.
Эти ментальные установки, возможно, когда-то были актуальны в тейлористской картине мира, но точно не работают в живой, динамичной продуктовой разработке.
Продуктовая разработка сопряжена с высоким уровнем сложности и неопределенности. Фокус каждого на общей цели и совместной работе на эту цель критичен.
Что делаем вместо этого?
  • Фокусируемся на том, где простаивает работа, а не отдельный участник команды.
  • Помогаем друг другу, чтобы работа двигалась по потоку создания ценности. Даже если где-то нужно выйти за рамки узкой специализации, подключиться, помочь, сделать что-то вместе, чтобы снять блокировку с работы.
  • Снимаем неопределенность и снижаем сложность через совместную проработку пользовательской функциональности на общих сессиях. Эта социальная часть работы так же важна, как непосредственно работа по написанию кода и тестов.
  • Вырабатываем и принимаем решения вместе, рассматривая проблему с разных сторон и точек зрения.
За счет этого мы устраняем искусственные барьеры внутри потока создания ценности, позволяя работе двигаться быстрее.

Published by
Продукт