Обреченный на успех StartUp. Глава 6
Введение: Бэклог Шредингера
Дорогие читатели, добро пожаловать в шестую главу нашей эпопеи.
Ссылка на предыдущие главы тут
В этой главе мы обсудим проблему “Бэклога Шредингера” или “Списка задач, которого не существовало”. Далее под бэклогом будем понимать отсортированный по приоритету список задач.
Что получите вы?
Вы узнаете, почему важно обсуждать приоритеты не только с собой любимым, но и с командой.
Волки и овцы
Все задачи от бизнеса носили приоритет “очень важная задача, только её ждем для выхода в прод”. Из-за этой сверхважности всех задач команда приняла правило: выполнять задачи от бизнеса строго в порядке их поступления. Редко допускались исключения, когда более позднюю задачу делали раньше, если она гармонично встраивалась в архитектуру проекта.
Формально процесс выглядел так: бизнес дает X сверхважных задач, команда начинает их выполнять. В момент N, когда сделана только часть из X задач, появляется еще Y сверхважных задач. Для бизнеса приоритет всех задач массива [X; Y] одинаков — сверхважный. Поэтому команда сама решала, какую задачу делать первой, исходя из загрузки команды и готовности архитектуры.
На тот момент существовала абсолютная вера в то, что каждая задача действительно важна для выхода на прод, и её нужно немедленно реализовать. Это ведь начало жизни стартапа!.
На первой стадии у менеджерской команды The StartUp возникло ощущение полного контроля над роадмапом: был последовательный план задач от бизнеса, внутренние задачи команды, понятные приоритеты и метод включения новых задач в роадмап.
Однако результаты работы показали, что бизнес недоволен сроками и качеством разработки. Тогда провели исследование и часть проблем удалось решить, изменив подход к оценке задач (см. главу 5), но это не решило проблему недовольства бизнеса.
Неравномерная загрузка
Вторая стадия ознаменовалась тем, что пришло осознание неравномерности и фрагментарности задач от бизнеса.
Задачи от бизнеса могли появляться каждый день или раз в полгода. Предсказать их появление было невозможно, так как они рождались в результате личных размышлений владельца бизнеса.
К тому же общей картины задачи часто не было: бизнес озвучивал одну часть, команда её реализовывала, после чего поступала другая часть, зачастую требовавшая переделки уже сделанного. На просьбы рассказать всю задачу сразу бизнес отвечал: «Вы хотя бы это сделайте...».
В таких условиях стало сложнее планировать задачи дальше одной итерации разработки. Поэтому менеджерами было принято решение, кроме задач от бизнеса, для нивелирования рисков неравномерности включать в бэклог задачи от продактов команды, в основном, для операторской части продукта, баги и технический долг.
На второй стадии стало тревожнее за бэклог, который мог в любой момент измениться, как зачастую происходило в первую итерацию. Но команда менеджеров старалась поддерживать порядок, добавляя операторские задачи, и продолжала проводить презентации задач команде.
Пузырь сверхважности
После двух итераций взаимодействия с бизнесом, нескольких демо и долгих обсуждений команда менеджеров сформировала для себя ключевые тезисы, с которыми предстояло поработать.
Приоритет сверхважных задач определялась исключительно личными потребностями владельца бизнеса, а их ценность зависела от его настроения.
Все сверхважные задачи были важны по-разному. Зачастую новая сверхважная задача оказывалась важнее старой такой же.
Ни одна реализация сверхважной задачи не привела к выходу на прод.
Актуальность задачи для бизнеса ограничена по времени, но заранее это время неизвестно. Актуальность задач теряется раньше, чем команда успевает их обрабатывать.
Заранее продолжительность актуальности неизвестна, потому что никаких внешних признаков определения такой актуальности не существовало.
Это не были показания внутренних метрик, это не были внешние сезонные факторы - актуальность зависела только от внутренних ощущений бизнеса и личных отношений с основным инвестором или потенциальными клиентами.
Приоритеты старых задач менялись не только относительно новой задачи, но и относительно друг друга.
Прикладные выводы из новых данных были такие: при появлении новой задачи от бизнеса нужно было обновлять приоритеты всех задач, включая те, что уже в работе; не стоило планировать бэклог дольше, чем на одну итерацию; запасные задачи (например, операторские) было полезно держать в резерве.
На третьей стадии пришло смирение, что команда совсем не контролирует список задач, а выступает исполнителями заявок бизнеса.
Было сложно больше психологически (лично мне) признать, что я вообще ничего не решаю. Было обидно видеть, как проработанные задачи не запускались в разработку, а уже разработанные оказывались ненужными клиентам.
Глобальные проблемы: Кто здесь главный?
Проблема «несуществующего бэклога» вновь напомнила о фундаментальных проблемах The StartUp:
Команда считала, что может управлять приоритетами, а бизнес ожидал, что его задачи отправляются в разработку моментально.
Сферические приоритеты в вакууме
Какие выводы будут полезны вам, дорогие читатели?
Разговаривайте с бизнесом, коллегами, сотрудниками. Старайтесь делать так, чтобы все находились на одной волне (on the same page).
Приоритеты — это относительная величина (а не то, что вы подумали, прочитав заголовок). Если у вас все задачи — блокеры-сверхважные, значит у вас все задачи неважные пришло время пересмотреть приоритеты.
Полезно учитывать мнение всех заинтересованных сторон при определении приоритетов задач: явное распределение веса голосов всех заинтересованных сторон в команде и подсчет средневзвешенного приоритета задач может на первом этапе решить проблему приоритезации.
Один мой коллега и очень хороший друг сказал, что новая функциональность вообще не может быть блокером по определению. Я с ним согласна, в моей текущей системе координат блокер - это проблема без которой не работает ключевая функциональность системы.
На этой ноте завершим главу про приоритеты и бэклог.
Спасибо, что дочитали! Делитесь, как вы определяете приоритеты в своих командах.