Быстро создавать продукты и сервисы, нужные клиентам и не тратить время и деньги зря, своевременно реагировать на изменения рынка, новые поступающие данные - это то, что нужно любому бизнесу. Гибкий, итеративный подход к работе помогает достигнуть поставленных целей.
Давайте разберемся с тем, что гибкий, итеративный подход в работе над продуктом (по сути, продуктовый подход).
Эта концепция пришла из разработки, программирования. Scrum, Agile – это все оттуда.
А потом она начала широко использоваться в бизнесе.
Итерации, как вы помните из математики – короткие промежутки времени, в течение которых происходит работа над продуктом.
Эти промежутки в Scrum называют спринтами.
По завершению спринта получается и обрабатывается обратная связь от стейкхолдеров, клиентов, внешняя и внутренняя информация о каких-либо изменениях, при необходимости в работу над продуктом вносятся корректировки и т.д.
В отличие от такого подхода проектный предполагает четкий план от начала до конца, обратная связь получается уже в конце.
Артефакт (документ, мини-продукт) Product owner, который помогает работать с таким подходом – это бэклог спринта, который составляется на каждый спринт и гибко обновляется, для задач в нем ставятся и меняются приоритеты.
В проектном подходе (его еще называют каскадный, вотерфольный) у вас есть стартовая точка A и финальная точка B.
В нем часто возникают две проблемы:
- вы в итоге не приходите в точку B
- вы приходите в точку B, но пока вы шли, мир изменился, поступили новые данные, и в соответствии с ними саму цель надо было поменять, но вы эти данные не учли и пришли не туда.
Что происходит в случае применения гибкого, итеративного подхода?
Есть стартовая точка A.
Есть итоговая цель B, есть подцели на пути движения к ней, путь делится на промежутки, итерации
По достижению каждой промежуточной цели мы смотрим и сверяемся:
- достигли ли мы промежуточной цели, что нам это дало
- приближаемся ли мы или нет к нашей конечной цели
- затем мы проходим следующую итерацию, опять сверяемся и т.д.
Если что-то изменилось, мы корректируем первоначальный план, спокойно намечаем другой маршрут по целям.
В итоге мы даже корректируем финальную цель и начинаем двигаться именно к той цели, которая актуальна для текущего состояния рынка, для наших клиентов и т.д.
Итак, спринт - это ограниченный во времени период работы, в результате которого Product owner и его команда достигают какой-либо поставленной цели.
Конечной целью спринта является некоторая ценность для пользователя.
Спринт может включать в себя любой набор работ, которые необходимо выполнить, чтобы достичь промежуточной цели.
Планирование спринта происходит перед его началом.
В конце спринта вы проводите демо для стейкхолдеров – показываете, что было сделано.
В конце каждого спринта вы проводите ретроспективу, оглядываясь на спринт назад.
Вы анализируете, куда продвинулись, в правильном ли направлении продолжаете двигаться, сделали, достигли ли промежуточной цели, приближает ли эта промежуточная цель вас к конечной цели.
Основываясь на обратной связи, получая по спринтам короткие петли этой обратной связи, вы реагируете на нее, корректируете свой бэклог, пересматриваете планы по продвижению к цели.
Бэклог спринта - это, по сути, набор тех самых задач, которые необходимо выполнить, чтобы достичь цели спринта (промежуточная цель).
Бэклог спринта формируется из бэклога продукта.
В правильно выстроенных и структурированных системах обычно задачи, которые необходимо выполнить для достижения цели текущего спринта, находятся вверху бэклога продукта, т.е. они приоритизированы.
Хороший бэклог спринта:
- Составляется заранее
- В нем выставлены приоритеты задач, которым соответствуют цели спринта
- Участники команды понимают, зачем делается то или иное действие – иначе с их выполнением могут возникнуть проблемы.
В плохом бэклоге спринта:
- Задачи нечетко сформулированы
- Нет понимания, зачем их нужно делать
- Непонятны принципы приоритизации
- В бэклог постоянно "докидываются" задачи, он раздувается, выполнить его становится сложно
В общем, так делать не надо.
Безусловно, бывает, что возникают новые, критичные задачи, которые нужно решить.
В таких случаях работает следующее правило: если у нас есть крайняя необходимость что-то взять в работу, то мы должны пересмотреть бэклог спринта. Мы можем взять эти задачи в итерацию, в бэклог спринта, но при этом мы равнозначные по сложности и трудоемкости задачи должны убрать бэклога.
Нужна помощь в обучении продуктовых команд? Обращайтесь!
Мы всегда на связи: Telegram, сайт, info@neuromap.tech.
