|
В этой небольшой заметке расскажу вам, как эту проблему обычно решаю я.
Представьте себе очень большую компанию, где неведомое количество стейкхолдеров на один ваш небольшой, но гордый, проект. Допустим, у вас есть 10 фич разной величины и сложности, которые для вашего Product Owner «все одинаково важны». Давайте поможем ему (или ей) в этом немного разобраться.
Мы с вами знаем, что очень плохо иметь 10 «самых приоритетных задач» (это вызывает переключение, пожаротушение, крик “нужно прямо сейчас” и тд). Наша с вами задача — помочь владельцу продукта ОБЪЕКТИВНО выбрать ту одну, над которой наша команда будет трудиться следующей. Для этого я использую WSJF из Scaled Agile Framework (оставим за рамками этой статьи холивар LeSS vs. SAFe).
Что такое WSJF ( Weighted Shortest Job First)? Это многокомпонентная система оценки, на выходе с которой вы получаете приоритизированный список задач, где первая — самая простая в реализации, но при этом и самая ценная с точки зрения бизнеса. Формула проста:
Где Cost of Delay:
Давайте более детально:
Бизнес (или клиентская) ценность — насколько эта инициатива принесет пользу для бизнеса или клиента.
Временная критичность — насколько нам важно сделать эту задачу сейчас, немедленно, или мы можем подождать. Например, конкурент делает что то похожее и нам нужно быть первыми.
Фактор риска (или возможности) — насколько эта инициатива уменьшает риск или открывает новые возможности. Например, выполнив эту задачу мы сможем выполнить следующие 10, или эта задача пришла от государственного регулятора.
Сложность работы — насколько технически сложно реализовать эту инициативу.
Итак, самое интересное! Первые три параметра, по отношению к каждому элементу, оценивает бизнес, а последний — ИТ. Но как оценивают?
Оценивание выполняют, используя ряд Фибоначчи, то есть в Story Points (далее просто поинты). Он очень удобен для этого, так как шаг значений увеличивается не линейно, а значит будет сложнее сложить все в одну оценку. Так же чувствуется разброс, например сразу видна разница в бизнес ценности между задачей в 3 поинта и 21.
Итак, нашу группу мы разбиваем на 2 лагеря: бизнес и ИТ. Садим за разные столы, даем в руки Planning Poker карты (или делаем их из стикеров, или используем телефон). Если необходимо, проводим небольшое обучение магии голосования. Скажу честно, можно обойтись и без карт, иногда это быстрее. Так что выбор за вами.
К этому моменту у вас должна быть подготовленная физическая доска. Да, именно физическая, не Jira, и не Version One. Физическая визуализация поможет всем говорить об одной картине на одном языке. Как только вы делаете это онлайн, все видят разное. На доске вертикально — ваши эпики/стори/инициативы, горизонтально — наименование факторов оценки.
Должно выйти что-то такое:
Дальше даем время и просим их оценить каждую задачу в каждой колонке в Story Points по отношению друг к другу. Здесь важно объяснить, что они берут колонку за колонкой. То есть, например, выбирают первую колонку Business Value расставляют оценки ко всем задачам в ней, только потом переходят к следующей. Это важно, потому что держит общение в рамках одного параметра.
По мере выполнения задачи просим их выносить оценки на доску.
В скором времени доска примет вот такой вид:
В моем случае я добавил еще один параметр оценивания для ИТ — Зависимости. Таким образом я хотел визуализировать, как некоторые, с виду простые, задачи, на самом деле очень сложны к выполнению из-за обилия вендоров.
Далее, дело за малым : суммируем и считаем баллы.
Победил тот, у кого выше балл :)
С цифрами сложно спорить, особенно когда сам бизнес ставит оценку. Но если это так, вам стоит вывести разговор в конструктив. Предположим, бизнес хочет делать первой задачу 5ю по списку, в которой много интеграций и зависимостей. Спросите, согласны ли они с оценками на доске? Видят ли они те же риски, что и другие? Понимают ли они объем задач?
В случае сильного сопротивления нужно идти вглубь, то есть погружаюсь в задачу, которую бизнес выбрал, вместе с ними, чтобы расширить контекст. Для этого я использую Impact Mapping. Но об этом уже в следующей статье!
Я проводжу ретроспективи досить часто, близько сотні на рік, а почав уперше це робити майже 10 років тому. У цій статті я хочу відповісти на Top 5 із питань про Ретроспективи, які найчастіше задають учасники тренінгів та Agile-ком'юніті.
Однією з основних функцій сучасного менеджера лідера є розкриття потенціалу кожного учасника команди для досягнення максимальної ефективності та реалізації цілей. Scrum Masters, Product Owners, Facilitators та інші лідери й керівники можуть використовувати коучинговий підхід для підвищення …
Ідея статті народилась із проблеми, яку я часто зустрічаю під час роботи з різними компаніями: Скрам Майстри не можуть знайти підходи до роботи з Власником Продукту (Product Owner = PO). Ця стаття дасть вам кілька ідей навколо 3-х проблем, чим ви можете бути корисні для PO.
