Сегодня мы расскажем о внедрении кросс-командной приоритизации во всей компании Спортмастер Лаб, и о том, как мы:
сократили время планирования разработки в 9 раз (с 18 до 2 недель).
увеличили количество значимых для бизнеса функций в 5 раз без роста команды разработчиков.
Новый подход открыл целый ряд неожиданных преимуществ для участников процесса:
"У нас наконец-то появился единый процесс принятия решений, — сказал один из разработчиков — четкие приоритеты с которыми согласен и бизнес и IT, никаких бесконечных дебатов."
"Каждый приоритет оценен на 100% и согласован всеми, а не основан на интуиции или влиянии отдельных лиц. Теперь есть мы видим высокий балл приоритизации, мы можем ему доверять."
"Это прозрачно: все знают, как рассчитывается оценка приоритета, и каждый заинтересованный участник, от заказчиков до потенциальных блокировщиков, имеет право голоса до того, как что-либо попадет в очередь разработки. Больше нет затягивания задач – мы знаем, что действительно важно."
"Разработка и бизнес стали больше понимать друг друга. Это совершенно новый уровень взаимодействия и снижения конфликтов."
"Я нашел задачу, потерянную в беклоге, которая помогла увеличить выкуп заказов на X процентных пунктов; при нашем объеме это олимпиарды денег. Эта отличная идея осталась похороненной в беклоге, если бы я не оценил задачи через наш новый процесс приоритизации."
Эта статья является дополнением к выступлению Ольги Лаптевой и Романа Грибова на конференции Enterprise Agile. Рекомендуем также посмотреть видео и почитать данный материал целиком.
Стопор из-за приоритизации?
Каждый квартал 1200 разработчиков, дизайнеров, продактов, аналитиков из Sportmaster Lab получают беклог от бизнеса на тысячи задач, и решают, что на данный момент самое значимое для бизнеса и IT нужно сделать.
В мире, где бизнес-потребности растут, IT сталкивался с суровой реальностью:
Перегрузка. Каждые полгода беклог увеличивается на 2000 новых запросов, что значительно превышает емкость разработки, и подчеркиваетло необходимость острой фокусировки на самых важных задачах.
Рост vs. Эффективность. Простое увеличение IT-команды не было подходящим решением. Нужно оставаться в рамках бюджета и пока процесс неэффективен, его нельзя масштабировать.
Вместо общих планов — волюнтаризм (идеалистическое направление в философии, приписывающее божественной или человеческой воле основную роль в развитии природы и общества). Решение принимались непонятно как и непонятно кем, что сейчас идёт в работу. Понять приоритеты можно было только обсудив все задачи всем со всеми, что было невозможно даже за несколько месяцев.
Потеря актуальности задач к релизу. К моменту выпуска быстро меняющаяся бизнес-среда и потребности часто делали задачи устаревшими. Бизнес-заказчики нередко обнаруживали, что конечный продукт больше не соответствует их ожиданиямтребованиям. Нужно было актуализировать приоритеты до момента начала разработки. А приоритеты могут меняться буквально в реальном времени. Требования регуляторов, сторов мобильных приложений, легаси задач.
Неучтенные запросы стейкхолдеров. Порой, когда какая-то из задач уже была в работе, об неё могли споткнуться стейкхолдеры, которые не знали о задаче, и создать блокирующие условия для дальнейшей работы. Например, архитекторы могли указать объективные причины, что в таком виде задачу невозможность выпускать и ее нужно переделывать. Т.к. не были привлечены вовремя к приоритизации и без их оценок подготовка задач к работе была не полной.
Нереализованный потенциал. Как следствие этих проблем, ценные ресурсы разработчиков не тратились на критически важные для бизнеса задачи.
Цель приоритизации
Наша главная задача — это эффективно использовать ценный ресурс разработки, быть уверенными, что берем в работу значимые для бизнеса задачи.
Минимизировать время на планирование.
Бизнес и IT должны быть согласны с топом приоритетов.
Для всех должно быть прозрачно, почему та или иная задача попала в топ.
Делегаты от функций бизнеса должны оценить его приоритетность и сложность до начала работы.
По каждой отдельной задачеа должна быть высокая согласованность с оценками.
Фактически это означает, что нам нужно было обсудить все задачи в беклоге с каждым участником и понять, что из этого важное, актуальное и насколько сложное.
Из всего описанного выше мы оказались перед дилеммой: или не учесть весь контекст потребностей, или согласовывать приоритеты бесконечно время. И нам удалось решить обе проблемы.
Из электронных таблиц в тупик: почему WSJF не помог справиться
Начали с WSJF
Мы решили начать с популярного фреймворка Weighted Shortest Job First (WSJF), используя гугл табличку для приоритизации.
Коротко про WSJF: фреймворк приоритизации из методики SAFe, состоящий из 4 критериев:
User Business Value — польза для конкретного бизнес-заказчика.
Time Criticality — насколько критична по времени задача.
Risk Reduction and Opportunity Enablement — снижение риска или открытие возможностей.
Job Size — время на задачу.
Общий балл считается по формуле:
⚖️
Выгрузили какую-то ограниченную часть задач по непонятным принципам из Jira в эксельку. Каждый критерий фреймворка приоритизации превратили в колонку. И лидеры бизнес функций стали оценивать.
Результаты оценки с WSJF в эксельке
Три месяца были потрачены на оценку без получения окончательного согласования приоритетов.
Широкие и субъективные критерии
Фреймворк WSJF опирается на общие понятия, такие как "риск", "размер работы" и "критичность", которые могут быть по-разному интерпретированы различными людьми. Например, для разработчика риск — это уязвимость, а для бизнеса — это штрафы регулятора.
Эта субъективность привела к несогласованности и разочарованию, при этом ценные, сложные задачи были упущены в пользу "более легких", что совсем не устроило бизнес.
Быстрые победы vs. Истинная ценность
Недостаток фреймворка WSJF в его формуле деления на усилия, мог увеличить приоритет меньших, незначительных задач над стратегическими. Это создавало беклог, в котором на верх списка приоритетов поднимались быстрые победы, вроде “поменять цвет кнопки”, но падали на дно списка важные, сложные проекты, такие как юридические задачи и задачи по соблюдению требований регуляторов.
Это и отражено в названии фреймворка “short job first”, но цель нашего бизнеса взять в работу самое значимое, а не самое простое.
Болото электронных таблиц
Электронные таблицы быстро стали кошмаром: медленные, подверженные ошибкам и требующие постоянных ручных обновлений. Кто-то постоянно ломал ячейки, что-то друг за другом стирали. Синхронизация данных с Jira стала утомительным упражнением в копировании и вставке (не все успевали обновить вовремя).
Слишком долгое погружение в контекст задачи. В таблицы выгружаются только названия задач и ссылки. Чтобы прочитать содержание, приходилось открывать сотни вкладок.
В итоге нескольким людям пришлось поддерживать актуальность беклога в таблицах, что только усложняло и без того сложный процесс.
Переход от Экселек к ПриоПлану
После первоначальных трудностей с WSJF, мы поняли, что нужен принципиально иной подход. В это время нам подвернулся тогда еще молодой стартап PrioPlan, который предлагал новый подход для приоритизации и нам эта парадигма подошла.
Этап I: Единая система приоритизации вместо изолированного принятия решений
🥇Приоритизация для нас — это не просто сортировка по важности, а это получение информации о приоритетах и согласие с ними от всех стейкхолдеров процесса.
В предыдущем подходе с WSJF мы приглашали только людей от функций бизнеса, но в реальности больше людей влияют на решение о важности и актуальности той или иной фичи.
Представьте приоритизацию в отдельных командах (продуктовых, командах роста, разработки) с ограниченным вкладом от других важных заинтересованных сторон, таких как юридический отдел, отдел безопасности, поддержки, рисков и т.д. Это приводило к разрозненным перспективам, несогласованным приоритетам и постоянно меняющимся оценкам сроков доставки из-за поздней обратной связи.
Самое главное решение: внедрить процесс "Саммитов". Вместо изолированных решений только IT или только бизнеса, или только юристов, мы пригласили всех за “общий стол приоритизации”.
Этап II: Собственные критерии приоритизации
🥇Лучший фреймворк приоритизации — это тот, который отражает процессы конкретно нашей компании и понятен каждому лицу, принимающему решения.
После WSJF стало очевидно, что нам не подходят абстрактные общие критерии вроде бизнес-ценности (“User Business Value”), поскольку они будут восприниматься каждым участником очень субъективно. Кто-то улучшает выручку, кто-то — конверсию сайта, кто-то — удовлетворенность клиентов и т.д.
Мы разработали свой собственный фреймворк приоритизации, который:
Использует наши внутренние термины. В основе критериев мы использовали слова из наших обычных обсуждений задач. Т.е. не абстрактные риски, а влияние на архитектуру.
Бизнес и IT. Дать возможность каждому рычаг воздействия на беклог.
Каждый из критериев был назначен соответствующему оценщику и имел своегому фасилитаторау. Об этом поговорим дальше.
Каждый участник приоритизации получил конкретные критерии для оценки задач. Это привело к созданию нашего собственного фреймворка приоритизации:
Критерии бизнеса:
Ключевые результаты (KR): прямое влияние на KPI продукта / процесса / функции / компании.
Радость пользователей (CSAT): оценивает удовлетворенность пользователей и количество пользователей, затронутых изменением.
Открытие возможностей: потенциал для стратегических инвестиций и устранения препятствий для развития.
Юридические риски: потенциальные юридические риски, репутационный ущерб и штрафы, связанные с задачей.
Критерии IT:
Риски разработки: снижение производительности команды, увеличение затрат на обслуживание или уязвимости безопасности.
Влияние на архитектуру.Определяет, приближает ли задача к целевой архитектуре или растит технический долг.
Критерии уверенности:
Проработка: прогресс, достигнутый в выполнении задачи, минимизация отказа от выполнения начатых задач.
Исследование: уверенность в том, что задача нам реально нужна (с помощью подтверждающих данных).
Критерии усилий:
Срочность: обеспечивает гибкость в рамках системы для приоритизации и быстрого решения задач с срочными последствиями.
Сложность фронтенда, бекенда, мобильной разработки, UX: время, необходимое для разработки веб- и мобильных продуктов.
Пример шкалы оценки
На примере критерия “Влияние на показатели”:
Какой численный бизнес-показатель продукта / процесса / функции / компании хотим улучшить? (ожидается непосредственное влияние в том же сезоне, в котором завершили реализацию ну или в крайнем случае в следующем)
Что оцениваем: Заказ на производство в контексте БИ / КИ (т.е. сам заказ может не приводить к изменению показателей работы. Но если он является частью БИ / КИ, на это направленных, то нужно оценку ставить исходя из этого знания
1 — не оказывает прямого влияния ни на какие показатели
2 — очень слабо влияет на показатели, в метриках не увидим
3 — слабое влияние на показатели. Возможно увидим в метриках
5 — среднее влияние, средняя уверенность
8 — ожидается ощутимое влияние на показатели продукта/бизнес-процесса/функции. Есть расчеты
13 — ожидается ощутимое влияние на показатели функции/компании. Есть расчет эффективности, подтвержденные
21 — ожидается значительное влияние на показатели компании/функции. Мы в этом уверенны, к инициативе приложен расчёт изменения показателей по данным пилотов, бенчмарков, референтов
Примеры задач под каждую оценку:
1 — Отслеживание просмотра правил подбора товара
2 — Улучшение качества отображения правил подбора товара на iPhone 4s
3 — Улучшение качества отображения правил подбора товара на мобильных устройствах
5 — Добавление правил подбора товара
8 — Отображение наличия товара по размерам
13 — Заказ размера товара на доставку в нескольких размерах
21 — Заказ товара через сайт
* Подробнее о каждом из критериев, шкале оценки и примерах в приложении статьи.
Как результат мы смогли прийти к собственной системе, которая резонировала с уникальными потребностями компании. Фактически мы “оцифровали” обсуждение планов, используя в критериях те термины, слова, единицы измерения, которые употребляли в обычных разговорах о планах.
⛳ Совет: Всегда четко определяйте и переименовывайте критерии приоритизации, чтобы устранить неоднозначность. Это гарантирует, что все будут на одной волне и внесут значимый вклад в процесс приоритизации.
"Мы успешно учли разнообразные интересы многих сторон и получили приоритизированную очередь запросов в разумные сроки," – директор по развитию данных и аналитике Роман Грибов.
Этап III: Асинхронный сбор мнений
Чтобы посмотреть на задачу с разных сторон, нужно опросить мнение каждого участника приоритизации о каждой задаче. Провести такое количество синк встреч просто невозможно.
Коллеги из PrioPlan’а показали основную возможность — асинхронно получить оценку важности или сложности каждой задачи в нашем беклоге.
Каждый участник приоритизации получал свой набор задач, где всегда отображалась актуальная информация синхронизированная из таск трекера, а справа было видно свои критерии, которые нужно оценить. При этом были выведены все необходимые поля.
Пример оценки по критерию “исследования”.
При такомй простом интерфейсеы, мы получали все оцифрованные мнения, на основании которых можно было проще принимать решения.
Были услышаны все голоса, от топ-менеджеров до инженеров, маркетологов, юристов, поддержки, логистики и менеджеров розничных магазинов. Это создало более короткий цикл обратной связи и обеспечило согласованность всех участников и раннее выявление потенциальных препятствий.
🌓 В приоритизации нет правильных ответов насколько задача важная или сложная, это все сбор мнений каждого отдельного сотрудника. Поэтому важно оценивать разногласия.
После сбор всех оценок, лиды каждого из направлений оценивали уровень согласованности каждой из оценок. Если один оценщик поставил максимальный балл, а другой средний, значит, кто-то что-то не знает. И такие момент потенциально опасны из-за неясностий для команды. Отчет о согласованности быстро показывает разногласия и только то, что нужно обсудить и быстро переголосовать.
Пример разброса оценки по критерию “открытие возможностей”
В конце концов мы получаем проскоренный беклог в котором мы уверены, что собрали мнения со всех людей, которые должны были высказаться по задаче, и уверены в том, что нет разногласий.
Такой подход способствует развитию культуры прозрачности и сотрудничества, где каждый голос услышан, и каждое решение проверено на его актуальность
"Ни у кого в бизнесе и IT-подразделениях не было сомнений, что задачи, выбранные для разработки, были наиболее приоритетными и значимыми для бизнеса." Ольга Лаптева (Руководитель Центра компетенции методологии продуктового подхода).
Этап IV: Подходящий инструмент
Эксельки и гугл таблицы нам уже никак не помогали. И мы решили попробовать специализированный инструмент приоритизации — PrioPlan.app, который обещал решить все наши проблемы и задачи приоритизации.
Синхронизация с Jira в реальном времени
Проблему выгрузки беклога Приоплан решаел отлично. Нам больше не нужно поддерживать несколько беклогов: в таск трекере и в табличках.
В Приоплане оказалась возможность двусторонней интеграции с Jira Server в реальном времени. Мы просто сделали фильтр синка и все заработало.
Изменения в беклоге Jira Server мгновенно обновляются в PrioPlan’е. Например, новая задача появляется в Jira, - и мгновенно она появляется в списке на оценку.
Сегментация задач
Также казалось невозможным справиться с таким пугающим объемом задач в беклоге Jira. Раньше мы оценивали весь список из тысяч задач в таблице. Но и тут нашлось решение – стратегическая сегментация. Мы разделили огромный беклог на небольшие части по командам и/или функциям, что помогло ментально разгрузиться и превратить огромную гору задач. Каждый сегмент, теперь содержащий 25-50 задач, был понятен и готов к оценке.
Этот подход привел к созданию 150 отдельных досок для каждой команды, сквозные приоритеты которых мы собрали на единой доске-отчете.
Назначение ответственных по критериям
Приоплан позволил перенести все наши критерии оценок без каких-либо компромиссов.
Оценка пошла заметна быстрее: у нас теперь всегда перед глазами актуальная версия задачи, критерии видно, подсказки объясняют как оценить задачу.
Если при WSJF все оценивали все, то теперь при очень четко описанных критериях мы приглашали к оценке только людей, которые в них разбираются. Подход “все оценивают все” только добавлял сумбурности и порождал недоверие к результатам.
Это позволило одновременно дать каждому члену команды вовлеченность и показать, что его мнение учтено через прозрачную и понятную систему принятия решений. Каждый отвечал только за тот критерий, в котором разбирается и каждый мог посмотреть чужие оценки в финале голосования, увидеть чужую точку зрения.
Уточнение задач из-за невозможности оценки
Только начав оценку задач, команда столкнулась с проблемой — порой сложно понять, о чем задача, в результате невозможно оценить.
Когда сотни людей в понятных рамках критериев “прочесывают” весь беклог, задумываясь о каждой задаче по своим критериям — происходит backlog refinement. Всплывает много понятных задач. Кнопка “поднять вопрос по задаче” отлично помогла нам переписать задачи, так чтобы ее можно было оценить.
Анализ разногласий
В каждом из критериев у нас больше одного оценщика. И нередко оказывалось, что один человек считает эту задачу “очень простой”, другой “очень сложной”. Один считает задачу “очень значимой”, а второй “совсем не нужной”. Это нормально, в приоритизации не может быть правильных ответов. Это как раз и есть та самая субъективность, из-за которой мы могли взять в работу неактуальную задачу.
С помощью отчета о согласованности команды мы стали быстро выявлять расхождения. Различия в оценках задач могли указывать на недопонимание или различное восприятие важности задачи и сигнализировать о необходимости уточнения: самой задачи, критерия и т.д. С двадцатью оценщиками на доску только 5-10% беклога требовали дальнейшего обсуждения. Решения по этому проценту задач появлялисьрешались на звонках, во время которых команда приходила к финальной оценке. Также есть есть фасилитаторы критерия “главный эксперт по этому вопросу в компании”, который наделен правом поменять финальную оценку в случае большого разногласия.
В истории оценок видно, кто и когда это сделал, и в случае чего можно откатить или оспорить оценку.
Процент оцененности и согласованности
К моменту принятия решения, что брать в работу, мы смотрим на две метрики каждого из бордов: процент оцененности и процент разногласий. Чем выше оцененность и меньше разногласий, тем больше доверия к топу приоритетов, а значит, можно брать из него задачи в работу.
Теперь зайдя в топ приоритетов, можно увидеть отсортированный список задач и понять, почему та или иная задача находится на своем месте в списке и за счет какого критерия.
Протухание оценок приоритетов
Признавая, что приоритеты могут быстро устаревать, наша компания приняла практику сброса оценок каждый месяц. Эта регулярная "чистка" гарантировала, что старые и, как оказалось, ненужные задачи были постепенно отброшены и закрыты, а мы сфокусировались только на актуальных вопросах.
Если задача осталась в беклоге на момент переоценки, то вопрос, а правда ли она все еще актуальна? Часто при переоценке задачи, которая когда-то была -то важной, оказывалось, что она больше не важна, падала в самый низ, или мы ее вовсе удаляли или склеивали с другой.
Этап IV: Кросс-функциональная приоритизация — 500% рост в задачах с бизнес-влиянием
Да, вы правильно прочитали. Оказалось, что мы стали делать в 5 раз больше более значимых для бизнеса задач.
Секрет успеха хорошо сформулировал наш CTO Михаил Заборов:
«По сути мы просто приоритизировали задачи в PrioPlan, и всё как-то поехало. Большая часть успеха в подходящем инструменте для придуманного процесса.»
У такого феноменального роста продуктивности было три основных фактора:
Планирование в 9 раз быстрее
Кросс-функциональная приоритизация сократила время принятия решений с изнурительных 18 недель (четыре с половиной месяца) в год до двух недель. Этот квантовый скачок был достигнут благодаря:
Специализированным инструментам. Использование синхронизации в реальном времени между Jira и Приопланом оптимизировало процесс.
Динамическим обновлениям критериев. Адаптация критериев приоритизации к меняющемуся бизнес-ландшафту обеспечила постоянное согласование приоритетов.
Автоматическому обнаружению разногласий. Мгновенное выявление расхождений сохраняло нашу фокусировку на важных и релевантных задачах.
Устранение задач с низким влиянием
После приоритизации мы получили такие результаты:
30% текущих задач разработки были удалены из-за низкого приоритета, ресурсы перераспределились на проекты с более высокой ценностью.
50% задач с наивысшим приоритетом были не готовы к разработке, и приоритизация позволила превентивно решить проблемы, которые могли возникнуть на этапе разработки.
60% задач, стоявших в очереди на производство, были деприоритизированы, потеряв актуальность из-за изменения бизнес-контекстов.
Колоссальное повышение продуктивности
Однако речь идет не только об удалении ненужных задач, а также и об оптимизации всего рабочего процесса с тем же размером команды.
время выполнения сократилось на 40% (это недели сэкономленного времени!);
время цикла релиза сократилось на 50%;
производительность разработчиков увеличилась в 2 раза.
Внедрение подхода кросс-функциональной приоритизации: пошаговое руководство
С готовыми шаблонами и подробными руководствами внедрение данного метода в вашей организации — это просто. Несмотря на то, что описанные ниже шаги основаны на использовании Приоплана, основные принципы можно экспериментально применить с использованием электронных таблиц (но будьте готовы к проблемам табличек)
Начните с небольшого беклога. Создайте список приоритизации, используя шаблон фреймворка.
Импортируйте беклог. 30-50 задач из вашего таск трекера. По желанию настройте синхронизацию результатов приоритизации обратно в ваш трекер для бесшовного рабочего процесса.
Настройте критерии. Тщательно просмотрите все критерии. Будут ли эти критерии резонировать с вашей командой во время обсуждений? Знакомы ли термины или их нужно изменить? Скорректируйте описания, чтобы они соответствовали языку вашей команды, удалите то, что не требуется, и добавьте критерии, которых может не хватать. Если вам кажется, что разные люди могут интерпретировать критерий по своему — разделите его. Например, время фронтенд, время бекенда и т.п.
Назначьте ответственного. Одного или нескольких человек, ответственных за каждый критерий. Это может быть любая комбинация членов команды, обеспечивающая широкую экспертизу.
Вовлеките вашу команду. Пригласите всех участников оценить задачи. Это коллективное усилие критично для всесторонней оценки.
Договоритесь про непонятные задачи: что делать, если в задаче не хватает данных для оценки.
Уточните разногласия. Если по одному и тому же критерию несколько человек поставили разные оценки, найдите способ не пропустить это, корректируйте оценки по мере необходимости, приходя к консенсусу и устраняя расхождения.
Оцените результат. Просмотрите приоритизированный список задач. При необходимости доработайте веса и количество критериев для дальнейшего уточнения приоритетов.
Внедрение этого подхода не только оптимизирует ваш процесс приоритизации, но и способствует созданию среды сотрудничества, где каждая задача оценивается через многогранную призму.
Заключение
Внедрение системы, о которой мы рассказали, трансформирует приоритизацию проектов. Команды часто обнаруживают, что то, что казалось "многообещающим", может не выдержать кросс-функциональной проверки, в то время как упущенные из виду "пусть будет" функции оказываются возможностями с высоким ROI. Настоящая победа — обнаружение скрытых жемчужин в беклоге, которые могли бы быть пропущены.
Сила кросс-командной приоритизации заключается в инклюзивности — объединении всех, кто может повлиять на выполнение задачи, а не только узкого круга специалистов. Мы столкнулись с проблемами непонятных, неточных описаний задач для людей из других команд, ролей. Опция "не могу оценить" привела к тому, что многие задачи были отправлены на дополнение описания их авторам. Изначально встреченная сопротивлением, эта практика в конечном итоге создала "позитивное давление" на авторов задач, чтобы уточнять, консолидировать или удалять задачи.
Наш опыт показывает, что кросс-функциональная приоритизация — это не просто инструмент для управления задачами, а мощный катализатор изменений в организационной культуре, способствующий прозрачности, сотрудничеству и эффективности. Внедряя такой подход, компании могут не только улучшить свои процессы разработки, но и создать более сплоченную, ориентированную на результат организационную среду.
Приложение:
Примеры критериев с описаниями, которые мы чаще всего используем для оценки. В Приоплане у нас накопилась большая библиотека критериев, отражающих особенности именного нашего бизнеса.
Для общего понимания важности разработки своих собственных критериев, делимся с вами несколькими наиболее частными.
Влияние на архитектуру
Двигает ли задача нас к целевой архитектуре (в том числе закрывая архитектурный/ функциональный долг)
Что оцениваем: Заказ на производство сам по себе
- 10 — задача очень сильно увеличивает архитектурный/технический долг (мега большой костыль)
- 6 — задача существенно увеличивает архитектурный долг/ технический (большой костыль)
- 2 — задача незначительно увеличивает архитектурный долг/ технический (маленький костыль)
0 — нет существенного влияния архитектуру, и не приближает целевое решение, и не отдаляет, фактически работает на текущем решении
2 — задача незначительно сокращает функциональный/архитектурный / технический долг
6 — задача значительно двигает нас к целевой архитектуре (в том числе закрывает "белые пятна" автоматизации функционала)
10 — задача приводит к целевой архитектуре
ИТ риски
Под ИТ рисками мы понимаем:Снижение пропускной способности команды
Увеличение технического долга
Неадекватное увеличение сопровождения, создаём новый ручной труд
Повышение хрупкости
Снижение производительности
Понижение безопасности и защищенности
Другие риски
Что оцениваем: Заказ на производство сам по себе
10 — задача очень сильно увеличивает ИТ риски
6 — задача существенно увеличивает ИТ риски
2 — задача незначительно увеличивает ИТ риски
0 — задача никак не влияет на ИТ риски
2 — задача незначительно сокращает ИТ риски
6 — задача существенно сокращает ИТ риски
10 — задача очень сильно сокращает ИТ риски
Экстренная
Критерий для внезапных задач, если их не сделать, то кто-то серьёзно пострадает, может быть, даже умрёт.
0 - не экстренная
Примеры задач, где можно поставить 100:
— Нашли уязвимость грозящую утечкой персональных данных
— Apple пригрозил выкинуть приложение из Appstore
— Пришло предписание от Роскомнадзора
— Есть высокий риск получить оборотный штраф
Исследование
Критерий важен для совершенствования системы сбора данных о взаимодействии пользователей с цифровыми каналами компании. Собранные данные используются для анализа результатов работы подразделений Маркетинга и Омни
0 — не узнаём ничего нового и ничего не тестируем
21 — собираем новые данные по поведению пользователей в цифровых каналах
Радость пользователей
Насколько этих изменений ждут пользователи? Каких пользователей затронет? Какое количество пользователей/клиентов коснуться изменения?
Пользователи — это не только наши клиенты, хотя в первую очередь, конечно, они. Это ещё и сотрудники компании, которые станут лучше работать благодаря выполненной задаче
Что оцениваем: Заказ на производство сам по себе
1 — не влияет на радость пользователей
2 — единицы смогут заметить улучшения
3 — небольшая часть обрадуется
5 — улучшения заметят: четверть клиентов/половина бизнес-пользователей/руководители структурных подразделений
8 — улучшения заметят: половина клиентов/все бизнес-пользователи/руководители функций
13 — изменение очень ждут все клиенты/все бизнес пользователи/руководители функций
21 — все клиенты/бизнес-пользователи не просто хотят этот функционал, у нас есть обратная связь, в поддержку постоянно звонят, нас об этом спрашивают друзья, родственники и даже прохожие на улице
Примеры задач под каждую оценку:
1 — Отслеживание доставки письма
2 — Улучшение вёрстки писем для Lotus Notes
3 — Возможность задания альт текста для картинок в письмах
5 — Адаптация вёрстки писем для gmail
8 — Отправка уведомлений с учётом часового пояса
13 — Центр уведомлений в мобильном приложении
21 — Возможность отписки от уведомлений в приложении
Влияние на показатели
Какой численный бизнес-показатель продукта/процесса/функции/компании хотим улучшить? (ожидается непосредственное влияние в том же сезоне, в котором завершили реализацию ну или в крайнем случае - в следующем)
Что оцениваем: Заказ на производство в контексте БИ/КИ (т.е. сам заказ может не приводить к изменению показателей работы. Но если он является частью БИ/КИ, на это направленных, то нужно оценку ставить исходя из этого знания
1 — не оказывает прямого влияния ни на какие показатели
2 — очень слабо влияет на показатели, в метриках не увидим
3 — слабое влияние на показатели. Возможно увидим в метриках
5 — среднее влияние, средняя уверенность
8 — ожидается ощутимое влияние на показатели продукта/бизнес-процесса/функции. Есть расчеты
13 — ожидается ощутимое влияние на показатели функции/компании. Есть расчет эффективности, подтвержденные ДКИП
21 — ожидается значительное влияние на показатели компании/функции. Мы в этом уверенны, к инициативе приложен расчёт изменения показателей по данным пилотов, бенчмарков, референтов
Примеры задач под каждую оценку:
1 — Отслеживание просмотра правил подбора товара
2 — Улучшение качества отображения правил подбора товара на iPhone 4s
3 — Улучшение качества отображения правил подбора товара на мобильных устройствах
5 — Добавление правил подбора товара
8 — Отображение наличия товара по размерам
13 — Заказ размера товара на доставку в нескольких размерах
21 — Заказ товара через сайт
Открытие возможностей
Устранение препятствий к развитию, открытие новых возможностей
Например, реализация шлюза продуктов устраняет большие препятствия для отображения остатков товаров на сайтах и в приложениях
Что оцениваем: Заказ на производство в контексте БИ/КИ (т.е. сам заказ может не открывать возможности. Но если он является частью БИ/КИ, открывающей возможности, то нужно оценку ставить исходя из этого знания)
1 — не открывает никаких возможностей
2 — открывает ничтожные возможности
3 — открывает локальные возможности для бизнес-процессов/продуктовой функциональности
5 — даёт ощутимые возможности для развития бизнес-процессов/продуктовой функциональности
8 — открывает возможности, которые в перспективе скажутся на работе функции или бизнес-процессе (можно будет увидеть в показателях будущих периодов)
13 — открывает возможности, которые в перспективе существенно скажутся на работе компании или функции (можно будет увидеть в показателях будущих периодов)
21 — открывает возможности, без которых компания абсолютно точно не выполнит долгосрочные планы
Примеры задач под каждую оценку:
1 — Отслеживание просмотра правил подбора товара
2 — Улучшение качества отображения правил подбора товара на iPhone 4s
3 — Улучшение качества отображения правил подбора товара на мобильных устройствах
5 — Добавление правил подбора товара
8 — Отображение наличия товара по размерам
13 — Заказ размера товара на доставку в нескольких размерах
21 — Заказ товара через сайт
Статус исполнения
Устранение препятствий к развитию, открытие новых возможностей
Например, реализация шлюза продуктов устраняет большие препятствия для отображения остатков товаров на сайтах и в приложениях
Что оцениваем: Заказ на производство в контексте БИ/КИ (т.е. сам заказ может не открывать возможности. Но если он является частью БИ/КИ, открывающей возможности, то нужно оценку ставить исходя из этого знания)
1 — не открывает никаких возможностей
2 — открывает ничтожные возможности
3 — открывает локальные возможности для бизнес-процессов/продуктовой функциональности
5 — даёт ощутимые возможности для развития бизнес-процессов/продуктовой функциональности
8 — открывает возможности, которые в перспективе скажутся на работе функции или бизнес-процессе (можно будет увидеть в показателях будущих периодов)
13 — открывает возможности, которые в перспективе существенно скажутся на работе компании или функции (можно будет увидеть в показателях будущих периодов)
21 — открывает возможности, без которых компания абсолютно точно не выполнит долгосрочные планы
Примеры задач под каждую оценку:
1 — Отслеживание просмотра правил подбора товара
2 — Улучшение качества отображения правил подбора товара на iPhone 4s
3 — Улучшение качества отображения правил подбора товара на мобильных устройствах
5 — Добавление правил подбора товара
8 — Отображение наличия товара по размерам
13 — Заказ размера товара на доставку в нескольких размерах
21 — Заказ товара через сайт