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