Про продуктовые команды 🤝
(Часть 1 - Scrum Guide)

Scrum Guide (далее SG) читали полностью слишком мало продактов. А ещё меньше понимают его суть. Очень рекомендую познакомиться с ним поближе. Джеф и Кен продумали стройный и целостный фреймворк для команд разработки (и не только).

Несмотря на то, что в реальной жизни эталонный Scrum я не встречал ни разу, SG содержит несколько мощных идей, которые вместе резко повышают шансы команды на успех.

✦ Эмпирический подход (сердце Scrum) - цикл: ставить эксперимент, получать обратную связь, делать выводы. Комада постоянно инспектирует продукт (sprint review), саму себя (sprint retrospective) прогресс в работе (daily scrum). Это создаёт систему в которой (если она по-настоящему работает) невозможно не перформить. Представьте гоночный болид, который с каждым спринтом едет быстрее за счёт постоянного анализа, что мешает, и небольших, но постоянных, улучшений. Если гипотеза улучшения не сработала, она просто откатывается в конце спринта и тестируется следующая.

✦ Команда сама определяет принципы, по которым работает. Любые попытки выработать общие правила (кроме вернеуровневых) приводят к тому, что неудобно вообще всем. Давая командам больше автономности и спрашивая за результат, а не за следование процессам, повышается их продуктивность. В случае унификации delivery, например, достаточно gateway’ев - контрольных точек в процессе типа “успешно пройдено 100% регрессионных авто-тестов”. А как именно этого добились, и чьими руками - не так важно.

✦ Цели спринта не подлежат изменению в ходе спринта (кроме особо описанных исключений). Это позволяет сконцентрироваться на достижении конкретного результата, не тратя ресурсы на постоянное переключение контекста. Я встречал команды, которые не имели end2end работающего продукта, спустя год работы. Потому что приоритеты менялись буквально по 2 раза в неделю.

✦ Длительность спринта - не более 1-го месяца. Такой подход снижает риски, позволяет меньше сомневаться и не впадать в параличь в попытках выработать идеальное решение. Потому что быстрее проверить гепотезу на практике и получить реальную обратную связь клиентов. Даже, если ты принял неверное продуктовое решение, команда потеряет (в худшем случае) месяц работы. Но и это позволит сделать вывод из допущенной ошибки.

Когда я в полной мере осознал логику с циклами обратной связи я стал видеть области её применения повсюду, начиная с семейной жизни и заканчивая построение карьеры. Не удивительно, что и область применения Scrum давно распространилась далеко за пределы IT.

При этом стоит учитывать, что для достижения настоящего Scrum (и вытеснения Waterfall) потребовался ряд пререквизитов:
✦ высокая пропускная способность каналов связи, позволившая доставлять обновления софтверный продукты онлайн (а не 💿)
✦ распространение DevOps и CI/CD практик и авто-тестов, позволившие снизить накладные расходы и ускорить циклы (а не ручной регресс длинной в неделю)
✦ превалирование in-house разработки или “time and material” (на смену fix price - в условиях фиксированный платы за заведомо оговорённый скоуп не бывает гибкости)

Рекомендую посетить тренинг по Scrum, если ещё не. Откроет глаза на много интересного. 🤔

#product_team #product_management #Scrum