Статью перевел Роман Усов, Scrum Master, DatsTeam (Telegram: @romanusov)
При разработке софтовых продуктов абсолютное большинство продуктовых команд сталкиваются с одними и теми же трудностями:
Непонятно, насколько то, что мы сейчас делаем, действительно ценно.
Всё важно; много параллельной работы; невозможно сфокусироваться на чём-то одном, самом ценном.
Разработка идет монструозными фичами.
Вал незавершенной работы.
Релизы большие и редкие.
Большинство таких команд не знает своих клиентов и пользователей и никак не взаимодействует с ними. Главенствующая установка — мы либо поставляем сразу все, либо ничего. Каждый участник команды работает в функциональном колодце, фокусируясь на какой-то своей технической части без понимания цельной картины.
Есть четыре командных паттерна, которые помогают исправить эту ситуацию, чтобы:
Фокусироваться на ценности и ее быстрой поставке.
Быстро обучаться, чтобы поставлять то, что ждут клиенты и пользователи.
Получать чистый дофамин от завершения работы, которая важна клиентам и пользователям.
Получать кайф от совместной командной работы.
Футбольная команда
Метафора футбольной команды, наверное, лучше всего передает идею. Безусловно, не все аналогии работают; они часто ошибочны. Но некоторые очень полезны.
Команда приезжает на стадион. Ее приветствуют фанаты. Команда готовится к игре, собирается и выходит на поле. Фанаты ликуют. Звучит свисток, и команда получает мяч. Участники на поле видят друг друга. Они работают вместе, иногда небольшими группами, чтобы как можно быстрее переместить мяч по полю к воротам противника и забить гол. Победа – это забивание максимально возможного количества голов через тесное взаимодействие всей команды.
Команда всегда видит счет и оставшееся время. Они слышат реакцию болельщиков. А когда раздается свисток, они могут стремительно перегруппироваться и адаптироваться к сложившейся обстановке на поле. Команда работает как единое целое с максимальной производительностью.
Чего мы не увидим в футболе?
Пустого стадиона.
Большого количества мячей на поле, каждым из которых владеют разные участники одной и той же команды.
Брошенных мячей, до которых никому нет дела.
Поля, строго разделенного по функциональным зонам.
Паттерн 1: Прямое взаимодействие с пользователями и заинтересованными лицами
Типичная картина:
Между командой и пользователями/заинтересованными лицами находятся прокси.
Требования транслируются продуктовой команде выделенной группой специалистов.
С пользователями или их представителями никто не общается напрямую.
Что стоит сделать?
Демонтировать барьеры между командой и пользователями (их представителями, заинтересованными лицами). Пользователь становится в центре всего, что делает команда.
Команда принимает участие в сессиях по выработке стратегии продукта, дорожной карты и в проработке и детализации продуктовых фич.
Команда демонстрирует работающую версию продукта напрямую пользователям и получает живую обратную связь.
Команда собирает живые метрики продукта и строит свою дальнейшую работу на их основе.
Паттерн 2: Разрабатываем продукт тонкими срезами пользовательской функциональности
Типичный подход — «все и сразу» с монструозными релизами и заложенными в них рисками и поздним получением информации о том, действительно ли то, что мы сделали, принесло ожидаемую ценность.
При этом есть несколько ментальных установок, которые укореняют этот подход в командах:
Уверенность в том, что только предиктивное, детерминистическое планирование и разработка работают. Это единственный подход к организации работы.
Мы можем начать только после того, как все детали большой фичи будут прояснены. Только так мы можем снизить неопределенность и сложность предстоящего изменения.
Нужно, чтобы все были непрерывно заняты работой, даже если сейчас нам придется делать не совсем то, что является самым важным для продукта.
Ментальная модель “Мы можем все продумать и спланировать заранее” не работает.
Что использовать вместо?
Ментальную модель “Нам важно быстро обучаться, быстро узнавать, действительно ли то, что мы делаем полезно для продукта и его пользователей”. Для этого нам нужно часто выпускать, собирать живые метрики и принимать решение на их основе.
Подход к развитию продукта на основе живых данных исходит из того, что:
Мы не можем заранее все знать и просчитать. Мы узнаем и адаптируемся по мере продвижения.
Мы поставляем продукт тонкими end-to-end срезами пользовательской функциональности, рабочими пользовательскими сценариями через короткие циклы разработки.
Фокус переключается на то, чтобы видеть все “поле” и находить самый быстрый, уникальный в складывающихся обстоятельствах путь к тому, чтобы “забить гол”. Игру можно выиграть, забив максимальное количество голов, а не одновременно жонглируя максимальным количеством мячей.
Паттерн 3: Завершаем одно, прежде чем стартовать другое
Одновременный старт большого количества задач не означает прогресс и эффективность работы. При этом такой подход привычен, особенно, чтобы все были хотя бы чем-то заняты. Он поддерживается набором ментальных моделей:
Нам очень хочется “угодить” тем, кто ждет от нас эту работу (“Все хорошо, мы уже работаем над этим”).
Все важно, все задачи имеет одинаково высокий приоритет.
Работа заблокирована? Ок, давайте возьмем что-то еще.
Пусть каждый работает над своей отдельной технической частью конечной функциональности. Сделал, передал дальше.
Попробуем сменить перспективу. Нам нужно перестать начинать и начать заканчивать.
Как этого добиться?
Фокусируемся на одной единице работы — цели, фиче, задаче — в каждую единицу времени.
Если “все важно”, осознанно выбираем что-то одно, пусть даже рандомно.
Если работа чем-то заблокирована, останавливаемся, собираемся и прежде всего устраняем препятствие.
Объединяемся в кросс-функциональные команды, чтобы вместе сфокусироваться на одной, общей задаче (цели, фиче).
Наличие одного “мяча” на “поле” направляет энергию команды. Она быстро перемещает его к воротам соперника. Препятствия не проблема: команда обходит или преодолевает их вместе. Когда по “полю” разбросано много мячей, команда не может работать вместе. Нужен один мяч, одна точка фокуса.
Паттерн 4: Работаем как команда, а не группа разрозненных специалистов
Часто то, что мы называем командой, на самом деле, лишь группа разрозненных специалистов. Мы игнорируем новые свойства и способности, которые могут появляться у команды при движении к общей цели за счет тесного взаимодействия друг с другом.
Тут тоже есть укоренившиеся ментальные модели, которые определяют такой стиль работы:
Важно, чтобы все были хоть чем-то заняты, даже если сейчас эта работа никому особо не важна. Любой простой — величайший грех.
Каждый должен заниматься только своим делом в рамках узкой специализации.
Каждый должен работать со своей отдельной задачей. Решать задачу сообща, в паре или группе — это неэффективно.
Время, которое команда тратит на проработку функциональности и задач на совместных сессиях — это пустая трата времени.
Эти ментальные установки, возможно, когда-то были актуальны в тейлористской картине мира, но точно не работают в живой, динамичной продуктовой разработке.
Продуктовая разработка сопряжена с высоким уровнем сложности и неопределенности. Фокус каждого на общей цели и совместной работе на эту цель критичен.
Что делаем вместо этого?
Фокусируемся на том, где простаивает работа, а не отдельный участник команды.
Помогаем друг другу, чтобы работа двигалась по потоку создания ценности. Даже если где-то нужно выйти за рамки узкой специализации, подключиться, помочь, сделать что-то вместе, чтобы снять блокировку с работы.
Снимаем неопределенность и снижаем сложность через совместную проработку пользовательской функциональности на общих сессиях. Эта социальная часть работы так же важна, как непосредственно работа по написанию кода и тестов.
Вырабатываем и принимаем решения вместе, рассматривая проблему с разных сторон и точек зрения.
За счет этого мы устраняем искусственные барьеры внутри потока создания ценности, позволяя работе двигаться быстрее.