Вы отправили сообщение, подготовились к встрече и готовы к приоритизации, верно?
Давайте сразу проясним – присвоение баллов отличается от приоритизации.
Присвоение баллов = процесс определения получаемого охвата, влияния, уверенности и затрачиваемых усилий.
Приоритизация = взятие этих баллов и их ранжирование для определения того, над чем работать дальше.
В этом контексте приоритизация – это простая часть. Трудность заключается в присвоении баллов, потому что для этого требуются дополнительные усилия, коммуникация, определение проблем, данные и многое другое.
Как менеджер продукта, у вас может быть представление о том, что находится в вашем бэклоге. Однако, если этот бэклог покрыт пылью, возможно, вам придется освежить память по нескольким элементам – и это нормально, потому что есть очень высокая вероятность, что не все участники вашего запуска понимают, что это такое – и, по моему опыту, вам следует именно так и предполагать.
Давайте разложим шаги и представим, что ваша встреча началась в 10 утра:
10:00 утра – убедитесь, что каждый понимает, почему он здесь, и прочитал всю информацию в Google-документе, в который вы вложили так много усилий.
10:01 утра – так как никто не прочитал его, запустите демонстрацию экрана и кратко перескажите основную информацию.
10:15 утра – теперь, когда опоздавшие присоединились к встрече, и вы презентовали вводную информацию, пришло время начать веселую часть – назначение баллов, и да, в первое время у вас это будет получаться неуклюже.
** Совет – просмотрите список задач до встречи и найдите ту, которую считаете легкой, и переместите ее вверх, чтобы поднять дух команды, прежде чем углубляться в трудные задачи.
10:16 утра – нажмите на первый проект. Прочтите заголовок и пользовательскую историю вслух. Задайте всем вопрос – «Понимаете ли вы, какую проблему мы пытаемся решить этим проектом?» – и я бы настоятельно рекомендовал добавить «систему поддержки» для молчаливых участников, которые должны высказаться сегодня. Что-то вроде: «Ничего страшного, если вы не знаете этот проект, я тоже не знаю их все, давайте это обсудим».
Как только вы убедитесь, что каждый понимает проблему, которую нужно решить, переходите к следующему шагу – назначению баллов.
10:20 утра – отлично! Мы все понимаем проблему, давайте определим наш "R" в RICE (Охват). Задайте этот вопрос вслух группе: «Сколько клиентов этот проект охватит в данном квартале по нашему мнению?».
Должен предупредить вас ... Вы можете подумать, что на этот вопрос сможете быстро дать ответ ... но нет. Этот вопрос должен совпадать с ДАННЫМИ – так как вы хотите, чтобы ваше прогнозируемое количество достигаемых клиентов было основано на данных. Хорошим примером может быть что-то вроде этого от вашего руководителя дизайна:
"Хорошо, сегодня с продуктом X мы видим только 150 клиентов в месяц, и я думаю, что если мы реализуем этот проект, то увидим прирост в 50 человек на основе данных, которые у нас есть от маркетинга, показывающих, что Y люди отваливаются на точке Z... **Открывает электронную таблицу** – и если считать за квартал, то будет прирост в 150 клиентов за квартал, и, вероятно, нам нужно скорректировать это, запустив его в середине квартала."
Не забудьте прикрепить таблицу к проекту!
Затем спросите, есть ли у кто-то данные, противоречащие ранее упомянутым, другие мысли и т.д. Если есть –обсудите. Определите правдивый источник данных и используйте его, если это возможно.
10:30 утра - согласовано количество Охвата в 150. Ура! (Мы действительно это делаем!)
10:31 утра - Влияние... Так много способов расчета, но в этой статье будем использовать простой подход.
Оставив открытым тот же проект, на который вы нажали в 10:16, задайте следующий вопрос: "На сколько процентов проект увеличит конверсию при взаимодействии клиента с ним?"
И мы не ищем четкое числовое значение, как в разделе Охвата. Мы ищем выбранное число от 0,25 до 3.
3 – это максимальное значение, а 0,25 – минимальное.
Обсудите с командой, какое число наиболее близко отражает потенциальное Влияние от реализации данного проекта. Воодушевите других присоединяться, если они молчат, вовлекайте их в обсуждение.
Я лично предпочитаю, чтобы оценка влияния основывалась на сочетании доступных данных и интуиции. Участники команды могут спорить по поводу более высоких или низких чисел, и это нормально. Просто оставайтесь на цели – числе, которое поможет нам определить приоритеты. Когда вы назначили оценки всем проектам, вы можете обнаружить, что оценили влияние неправильно по сравнению с другими, что позволит продолжить обсуждение до переранжирования. Допустим, наша оценка Влияния составляет среднюю или "1".
10:45 утра - тот же проект все еще открыт, и мы определили R и I.
** Совет – вместо перехода к оценке Уверенности (C), перейдите к оценке Усилий (как можно присвоить оценку уверенности, если все числа еще неизвестны?)
Теперь задайте вопрос: "Думая об этом проекте не только с точки зрения разработки, но также дизайна, поддержки, подготовки к обучению, сколько человеко-месяцев на это потребуется по нашему мнению?"
10:46 утра – не хочу вас огорчать, но вам придется повторить, что такое "человеко-месяц". Несмотря на то, что вы этого не хотите, потратьте следующие 10 минут, чтобы убедиться, что все понимают, что это такое, это будет лучше для вас в долгосрочной перспективе.
Также стоит повторно указать, что присвоенная оценка усилий не означает, что на выполнение потребуется именно столько времени.
11:00 утра – когда у всех сложится четкое понимание того, что такое человеко-месяц, вернитесь к оценке. Повторите вышеприведенный вопрос и подождите, пока кто-нибудь ответит. Ставлю 10 долларов на то, что это был разработчик. Угадал?
Разработчик говорит: "Ну, я могу ответить только на основе того, что у нас есть в этой задаче/проекте, поэтому, исходя из этого, вероятно, потребуется спринт, чтобы все согласовать, когда мы будем готовы к постройке".
Отлично! Но это только часть головоломки, а что насчет технического обзора, дизайна и т.д.?
"А что думает дизайн-команда?"
Вы уже поняли основную суть.
Затем вы берете итоговую оценку от всех команд – скажем, это было:
2 недели планирования, 2 недели на дизайн, 2 недели технического обзора и 2 недели на разработку. Таким образом вы можете поставить оценку усилий в 2 человеко-месяца.
11:15 утра – ВЫ СДЕЛАЛИ ЭТО, вы избавились от трех самых сложных букв R, I, E. Теперь время для простой – C – Уверенности.
** Совет – Смотрите со стороны «насколько вы уверены в числах, которые установили для R, I и E, а не в вашей Уверенности в проекте».
Если вы округлили все числа без данных и разговора, ваша уверенность низкая. Если у вас есть сверхуверенность, потому что это всего лишь небольшое обновление, или ваша команда имеет все исторические и прогнозируемые данные, – уверенность высока.
Итак, в нашем примере, мы обсудили и никто не сверхуверен, но мы думаем, что у него есть потенциал, который нужно проверить... мы пойдем с 50% уверенностью, и если уверенность увеличится или уменьшится в процессе открытия, мы обновим это соответственно.
11:25 утра – Уровень Уверенности = 50% или 0,5
11:26 утра – R*I*C/E = 150*1*0,5/2 = 37,5
11:27 утра – Вы справились – у вас есть рейтинг RICE для одного проекта! Теперь вам нужно повторить это еще около 87 раз... Думаю, вы поняли, насколько это может быть времязатратным. Нам потребовалось полтора часа, чтобы получить один рейтинг на нашей первой встрече. Однако со временем и повторением ваша команда будет справляться быстрее.
11:28 утра – Постарайтесь получить как минимум еще один полный рейтинг на этой встрече, а затем позвольте всем вернуться к своей повседневной жизни. Однако, если времени нет – убедитесь, что вы сообщите заинтересованным лицам, что этот процесс продолжится на следующих встречах, и если они хотят присоединиться, они приветствуются, поскольку их голоса напрямую влияют на оценки. Однако, если у вас есть доверительная группа лидеров, они могут отказаться и оставить вас и вашу оставшуюся команду оценивать и устанавливать приоритеты на будущие встречи.
12:00 дня – Надеюсь, вы получили еще один оцененный проект и теперь можете поместить наиболее высоко оцененный элемент на первое место, за которым следует второй элемент на втором месте и так далее. Теперь мы заканчиваем встречу и убеждаемся, что все знают, когда состоится следующая – не позднее чем через неделю, желательно как можно скорее.
** Совет – не бойтесь здесь выходить за рамки запланированных встреч. Никто не любит делать это, так же как никто не любит заниматься спортом. Это нужно, чтобы иметь здоровое понимание того, над чем работать дальше, с минимальной неопределенностью.
Это также является повесткой дня для вашего совещания, которую нужно включить на шаге 1.