Как управлять рисками в продуктовом бэклоге

Когда мы планируем разработку, в нашем бэклоге лежат задачи. Рядом с каждой из них могут незаметно притаиться риски — один или несколько. Давайте поговорим о том, как эти риски увидеть и что с ними делать потом. Это обобщение моего опыта в роли тимлида — что я делал по поводу рисков в бэклоге, что получалось, что нет.

Что такое риски? Риск это возможная проблема в будущем. В зависимости от разных факторов, эта проблема или случится или пройдет мимо нас. На часть факторов мы можем воздействовать, другие находятся вне нашего контроля.

История одного релиза

Мы создаем экосистему МойОфис, и хотим рассказать про интересный кейс из нашей практики программной разработки. Благодаря нему мы научились лучше оценивать риски и делать более точные прогнозы.

Наша фронтенд-команда работает двухнедельными спринтами. На каждый публичный релиз приходится 6-8 таких спринтов. Однажды, когда мы находились в середине цикла и оставалось буквально 3 спринта, к нам приходят владелец продукта с дизайнерами. «Нужно сделать редизайн, очень желательно успеть к релизу. Вот макеты, которые всем нравятся».

Новый макет выглядит, действительно, лучше прежнего. Но нужно поменять довольно большую часть внешнего облика системы. Заводим задачу «сделать редизайн», оцениваем. Получается, что если сразу начать, то теоретически к концу спринта можно успеть. Есть некоторые нехорошие предчувствия, но мы всё равно начинаем. И к концу спринта мы, конечно, не успеваем. Ну уж в следующем-то успеем?

В следующем спринте становится ещё хуже. Мы сталкиваемся с множеством крайних случаев, про которые никто не подумал изначально. Приходится придумывать много решений по ходу. Например, где-то на макете появился управляющий элемент, которого нигде не было до этого — почти целый день уходит на споры о его необходимости и можно ли  его заменить другим. Начинаем тестирование, и понимаем — всё стало еще хуже. Измененные части системы выглядят хорошо, зато расползаются те, которые мы не трогали. Потом кто-то проверяет как все выглядит в Internet Explorer…

В общем, это было непросто, но мы справились. История с редизайном была закончена только в самом конце спринта. С компромиссами и кучей костылей вливаем в master, и идём на ретроспективу.

Остается последний спринт релиза

На вливании в master история не заканчивается. Когда задача решается в самый последний день спринта, то как правило, страдает качество. Появляются регрессии по всему продукту. Затем, когда мы начинаем их править, на каждый исправленный баг вылезает по два новых.

Разбор полетов

Произошедшее заставило нас задуматься над тем, правильно ли мы умеем планировать свое время и управлять им. И какие выводы нужно сделать из этой ситуации, чтобы подобного не случалось в дальнейшем.

В случае с примером выше, ситуация становилась нервной ещё и потому, что в редизайн было вложено много усилий, наступили дедлайны и отступать было просто некуда. Вариант с удалением из основной ветки редизайна перед релизом тоже был маловероятен — поверх нового дизайна уже сделан ряд других важных функциональных изменений. В этот момент и появляется самый сильный страх — а вдруг, мы не успеем?

Для того, чтобы всё же успеть сдать релиз, пришлось напрячься и вложить все свои силы. Дальнейшее тестирование показало, что уровень качества даже такой работы оказался приемлемым. Правда затраты на разработку и тестирование, если считать честно, превышали оценку больше чем в три раза.

Так при чем тут управление рисками?

А его в этой истории и не было.

Это был главный вывод, который заставил нас сделать работу над ошибками и избегать подобных ситуаций впредь.

Управление рисками и кризис-менеджмент

Давайте немного поговорим о тушении пожаров.

Вспомним, что:

• риск — это возможная проблема. Когда такие проблемы видно заранее, мы можем с ними как-то работать, чтобы снизить вероятность или смягчить негативные последствия. Это управление рисками;
• кризис-менеджмент — ситуация, когда проблема уже возникла, её надо решать и минимизировать ущерб.

Управление рисками и кризис-менеджмент находятся в балансе. Все проблемы, которые не удалось предотвратить, нужно будет решать. Не управляешь рисками — будешь тренировать навыки кризис-менеджера.

В ситуации из примера мы понадеялись, что нам повезет и не предприняли никаких мер заранее. Не повезло.

Почему кризис-менеджмента лучше избегать?

Наверное, все слышали поговорку о том, что героизм одних — это следствие раздолбайства других. Неприятно, когда и герой и раздолбай находятся в одной команде. Это снижает уровень доверия, портит отношения, ухудшает продуктивность. А хуже всего когда раздолбай — тимлид.

Ситуацию внутри команды вы контролируете и можете сделать так, чтобы этих проблем не было. Скучно в любом случае не будет. Вам хватит героизма, вызванного неуправляемыми факторами.

Какие бывают риски

Некоторые риски уникальны, но большинство связаны с одними и теми же повторяющимися причинами. Эта статья посвящена только тем причинам, которые связаны с продуктовым бэклогом. Не будем говорить здесь про риски, связанные с качеством, человеческим фактором, отношениями с клиентами и т.п.

Мой топ-3 источников рисков:

• Неопределенность планирования
• Технический долг
• Соседние команды

Источник рисков: неопределенность планирования

Как вы думаете, неопределенность требований, неопределенность сроков и т.п. — риск для проекта?

Мой ответ — нет. Сама по себе неопределенность это не риск. Чтобы она стала риском, нужны дополнительные ингредиенты. Например, попытка составить более-менее четкий план на базе недостающей информации. И особенно, попытка давать обязательства по поставке, основываясь на таких планах.

Виды задач по критичности

Задачи стоит планировать по-разному в зависимости от приоритета.

Критичные (обязательные) задачи

Наша команда разрабатывает веб-интерфейс облачного файлового менеджера. Давайте возьмём для примера поддержку управления версиями документов. Эту функцию нужно было добавить в сервер и все клиенты в течение одного релиза. Если бы мы не успели сделать поддержку в своем компоненте, то система в целом осталась бы в недоделанном состоянии.

Для критичных задач у нас есть, по факту, фиксированный срок поставки. Если мы не попали в свой прогноз, то нужно искать компромиссы, которые помогут удешевить реализацию так, чтобы мы успели. Либо нести ущерб от нарушения своих обещаний и исключать эти задачи из релиза.

Для критичных задач наша цель управления рисками заключается в том, чтобы обеспечить поставку в срок. Если мы можем потратить чуть больше времени разработчиков, но при этом снизим риск — то это почти всегда стоит сделать.

Лучший способ сделать вовремя — начать раньше. Тут нам помогут ранняя интеграция, прототипы и декомпозиция.

Некритичные задачи

Однажды возникла идея — давайте сделаем режим галереи для просмотра фотографий, которые размещены внутри файлового менеджера. Эту фичу не включали в план релиза и никому заранее не обещали.

Фотогалерея отличный пример некритичной задачи. Управлять ими проще. Если мы такую задачу не успеем сделать в этом релизе, то ничего страшного не произойдет — сделаем в следующем. Эти задачи хорошо использовать в качестве буфера: если критичная задача не укладывается в оценку, мы можем выкинуть любую из некритичных и освободить время.

Основная цель управления рисками по некритичным задачам состоит в том, чтобы избежать возникновения проблем, которые помешают работе над чем-нибудь более важным.

Разберем один из случаев, когда затягивание работ по некритичной задаче может создать проблемы для более важных задач.

Оптимальная последовательность задач

Давайте посмотрим, как выглядит план релиза. У нас есть фиксированная дата выпуска и примерный перечень работ. Он делится на критичные и некритичные задачи. Первые мы обещали кому-то и на этих обещаниях другие люди могут строить свои планы. Вторые могут быть без особых последствий убраны, если вдруг что-то пойдет не так.

С точки зрения минимизации проблем, хорошо бы сначала сделать все обязательные истории, а необязательные — использовать в качестве задела на будущее.

Как думаете, в реальной жизни так получится? Нет, реальная жизнь обычно выглядит по-другому. Многие критичные задачи имеют зависимости и мы не можем начать их прямо сразу:

• не готов бэкенд;
• владелец продукта продолжает уточнять требования;
• какие-то задачи в принципе появляются в середине релиза.

Поэтому, чаще всего многие разработчики сначала занимаются чем-то некритичным, что уже можно взять в работу, а критичные вещи ждут своих зависимостей. Расставив очередность выполнения критичных задач с учетом зависимостей, можно оптимизировать процесс и получить вот такую картину:

Как видите, общий буфер стал втрое меньше, а для одной из критичных задач его нет вообще. Получить полностью оптимальную последовательность задач, как правило, невозможно. Но правильная декомпозиция может улучшить ситуацию, об этом ниже. А пока попробуем разобраться, чем может навредить недооценка некритичной задачи.

Недооценка некритичной задачи

Возьмем упрощенный случай: у нас есть ровно две задачи. По критичной ждем зависимости, некритичную можно начинать сразу. За критичной задачей снова стоят некритичные, их используем в качестве буфера перед дедлайном.

Как думаете, что случится, если мы недооценили первую задачу и поняли это уже в процессе?

Во-первых, когда задача уже начата, хочется её закончить. И когда она сильно вылезает из оценки, это может привести к тому, что из-за этой доделки позже будут начаты более критичные задачи.

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