какие виды критичности присутствуют у фичи истории
Приоритезация фичей
Мы как продукт менеджеры, генерируем неисчисляемое количество идей. Каким-то образом у себя в голове их приоритезируем. Голова лопается, мы не знаем, что делать с этими идеями. В вашем “листе идей” какой-то ад творится… Особенно это знакомо людям которые только начинают свой путь в бизнесе, или же только начинают свой путь продуктами.
Эта статья поможет быстро (на пальцах) откинуть из сотни фичей большую часть. И оставить только те, которые действительно принесут бизнесу пользу.
Для начала рассмотрим переменную таблицу методов приоритезаций:
Исходя из данной таблицы, можно сделать вывод.
По горизонтали есть внутренние методы приоритезации, которые решаются в рамках компании — команды.
Если же принимают участие пользователи, то соответственно это внешние.
По вертикали, то сколько данных есть для принятия решений.
Качественные когда вы делаете глубинные интервью от десятков респондентов. И количественные, когда имеется много разных аналитических данных.
Внешние методы применяются:
Когда продукт только вышел в свет, и мы пока не понимаем глубинных потребностей потребителя.
Когда внутри компании есть ключевые подразделения которые принимают решения (аналитика, маркетинг, сейлзы, стейкхолдеры).
Внутренние методы применяются:
Когда есть история какая функциональность меняет метрики, можно сделать приоритезация внутри команды.
Уточнение результатов полученных из внешних методов;
Мы рассмотрели основные различия внутренних и внешних методов.
Далее мы рассмотрим такие методы приоритезации как быстрая (на пальцах) и медленная.
Быстрая позволяет откинуть наиболее не ценные функции, а медленная помогает выбрать из оставшихся самые лучшие.
Быстрые методы
Метод Reach/Frequency
Reach — охват аудитории. Сколько людей готовы воспользоваться фичей.
Frequency — частота использования фичи.
В идеале нам нужен верхний правый угол. Те кто все время пользуется и вся аудитория.
Метод Poker planning
Идея взята из Agile методологий. (Оценка производится внутри команды.)
Оценка пользы фичи
Вы произносите фичу и на счет “раз, два, три”, члены команды поднимают пальцы. Считаете средний балл. (Можете приглашать внешних людей из других проектов).
Собираем разработчиков, говорим про функционал и так же ставим условие: 1 палец — быстро сделают. 2 пальца — разработка будет не сложной. 3 пальца — разработка будет очень сложной и долгой.
Далее мы делим пользу на затраты и получаем приблизительную оценку функциональности.
Фича 4 имеет самый высокий процент, значит точно будет вверху таблицы приоритезаций. Фича 2 имеет самый низкий процент — мы точно выкидываем из нашего бэклога.
Медленные методы
Разработан компанией intercom.
Это такой метод приоритезации идей и фич продукта, который включает 4 фактора, которые менеджер продукта использует для оценки и приоритезации фич:
Reach — охват аудитории. Не забываем, что охват именно тех людей, которые увидят эту фичу.
Impact — влияние фичи на пользователя. Его радость, бусты, эмоции от данной фичи. (0.25 — очень плохо, 0.5 — плохо, 1 — средне, 2 — хорошо, 3 — отлично)
*** Некоторые считают что impact — это именно влияние фичи на компанию. То есть какое количество метрик мы подымем при помощи этой фичи.
Confidence — Уверенность в гипотезе. Довольно важный параметр, показывающий на сколько вы считаете хороша ли гипотеза, т.к мы не всегда придумываем супер-топ идеи. ( Высокая = 100%, средняя = 80%, слабая = 50% и ниже)
Effort — Сложность разработки. Обычно указывается в месяцах. (пол месяца 0.5)
Приоритезация по ROI
Изначально Вам нужно сделать иерархию метрик. Если Ваш продукт не Amazon и не google, более чем достаточно будет сделать древовидную систему. Что из чего происходит. Например Life time Value напрямую зависит от Retention. Отлично! Этого будет достаточно для интернет магазина. Далее по аналогии в зависимости от масштабов продукта, можно использовать аналитические данные и делать формулы.
Очень удобно когда есть идея, знать на какую метрику она повлияет. И понимать на каком уровне дерева находится. И чем будет придуманная фича ближе к главной метрике, тем профитнее она. Чем дальше, соответственно шансов почти нет, что она повлияет на главную метрику.
Пример приоритезаций из иерархии метрик
С командой мы расставляем “вес” фичи, на сколько кто в нее верит. + ставится на те которые выбирает большинство. На них можно делать основной акцент на ближайшие пол года.
Пример приоритезации по ROI
У нас есть количество пользователей за год. Мы делаем прогноз, что воспользуются продуктом 70%, а приобретут продукт 50% от пользователей.
Я прикидываю, что внедрение фичи принесет компании 4% от прибыли.
Зная сколько у нас прибыль от одной оплаты, не сложными расчетыми мы получаем сумму которую наша фича принесет за год дополнительно.
Далее мы идем к разработчикам и понимаем сколько будет длиться разработку. Переводим все в человека часы и получаем стоимость разработки.
Имея эти данные мы можем посчитать ROI ((доходы — расходы) / расходы * 100%) фичи.
Таким образом, мы можем посчитать все фичи из бэклога и приоритезировать его.
*** Так же можно сделать более детальную проработку таблицы с Реальными % конверсии, пессимистичными и оптимистичными.
Ты получаешь оценку в деньгах. Люди любят деньги.
Не учитываются абсолютные значения
Многое зависит от личных скилов продакт менеджера.
Мелкие фичи не понятно как считать.
Считать прибыль, а не выручку.
Типичные ошибки Product manager’ов
1. Оценивать в одиночку.
Всегда просите, чтобы ваши расчеты кто-нибудь проверил. Свежий взгляд всегда хорошо;
2. Не учитывают влияние одной части на другие части продукта.
Очень важно думать как вся экосистема работает, чтобы не проседали другие части продукта;
3. Повестись на хейтеров.
Всегда есть хейтеры которые пользуются продуктом, но всегда чем то не довольны. Главное не путать между обычными хейтерами и людьми которые хотят помочь продукту. Делать исследования глубже;
4. Количественная оценка не всегда лучше, чем качественная.
Если продукт новый, или не большой, лучше всего общаться со своей аудиторий и понимать ее глубинные потребности.
5. Закопаться в мелочах. Смотрите на продукт сверху!
Подводя итог могу сказать, что та система приоритезации, которая работает в Яндексе, вряд ли будет работать, если вы захотите ее применить для стартапа, в котором работает четыре человека.
Компании разные, у них разные цели, разные задачи, разное позиционирование и положение на рынке — кто-то еле сводит концы с концами и важно заработать денег буквально завтра, иначе стартапу конец, а кому-то деньги уже не так важны в сравнении с положением на рынке или репутацией, у кого-то есть деньги на масштабирование и главной задачей является привлечение новых пользователей, а кто-то не может масштабироваться из-за ограничений инфраструктуры и хочет сократить круг пользователей, но зарабатывать больше денег с существующих. В общем, не все так просто.
Что дальше? Или как правильно выбрать фичи для разработки
Грамотно и вовремя выбирать фичи для разработки и не прогадать – это про искусство приоритизации. Как найти критерии оценки, необходимые для своего продукта, вырастить стратегические показатели, предложить клиентам еще больше ценности, наладить все внутренние процессы в команде и добиться других наглядных показателей с помощью качественной приоритизации?
Эта статья написана по материалам доклада “Что дальше? Или искусство приоритизации”, с которым я выступил 26 июня на конференции BDS. Marketing.
В докладе я рассказал о том, как мы приоритизируем фичи в компании Hygger.io — системе управления проектами для продуктовых команд.
Прежде чем перейти к описанию нашего процесса, хочу кратко напомнить о том, почему приоритизация так важна.
Почему без приоритизации не выжить?
«Управление продуктом» означает принятие решения о том, что мы делаем для продукта, а затем его реализацию.
Райан Сингер, продуктовая стратегия Basecamp
Управление продуктом состоит из трех больших блоков:
И не будем кривить душой — я думаю, что многие product managers кайфуют от такой «лепки». От возможности влиять на то, каким будет продукт.
Отвлекающие факторы буквально убивают стартапы. Строительство ради строительства подобно самоубийству. Поэтому наличие строгого и честного процесса приоритизации для разработки функций имеет решающее значение для контроля внимания и устранения лишнего.
Бен Йосковитц, автор Lean Analytics, инвестор и стартап ментор.
Легко взять и потратить бесценное время команды на разработку фич, которые никому не нужны. Особенно эта проблема актуальна для стартапов, время и бюджет которых очень сильно ограничены.
Заблуждается тот, кто считает, что новая добавленная фича сразу заставит людей захотеть использовать весь продукт.
Джошуа Портер, UX директор в HubSpot
Стоит вспомнить интуицию — нашего лучшего «помощника», который постоянно «шепчет» нам на ухо: «Вот эта фича ну точно всех порвет!» И в другое ухо: «А вот эта фича догонит и порвет всех, кого не порвала первая фича».
Мы делаем такие фичи и потом удивляемся, почему вообще ничего не изменилось в продукте.
Известный в Силиконовой долине Marty Cagan в своей книге Inspired выделил три типа менеджеров продукта:
Процесс приоритизации в Hygger
Теперь я хочу рассказать о процессе, который помогает нам в Hygger выбирать будущие фичи и делать продукт все лучше и лучше.
На самом деле, все просто: мы ставим себе цели на 2 месяца, выбираем метрики для контроля, собираем и отбираем идеи, которые могут улучшить эти метрики. Далее мы проводим бережливую приоритизацию идей, делаем скоринг фич, и, наконец, пишем ТЗ на фичи, которые выиграли. Вот и все — фичи готовы к разработке.
Если все это систематизировать:
Формулируем Цели
У нас в продукте есть 2-х недельный trial. Мы хотим увеличить число компаний, которые после триала покупают платную подписку. Это наша основная цель на ближайшие 2 месяца. Также нам нужно отстроиться от конкурентов, ибо на рынке порядка 500 систем для управления проектами.
Выбираем Метрики
У нас есть основная метрика и вспомогательные. Важно, что все эти метрики находятся в нашей зоне влияния.
Основная метрика — конверсия trial-to-paid.
У каждого продукта своя ценность. Например, в Tinder это успешный обмен сообщениями, в Facebook — просмотр непустой ленты в течение какого-то времени.
Пользователей, которые прочувствовали эту ценность мы называем активированными. Наша задача увеличить число таких пользователей. В Facebook посчитали и выяснили, что на активацию влияет число друзей — чем больше друзей, тем больше лента и тем больше времени юзер зависает в ленте и больше рекламы смотрит.
Собираем идеи
Вот главные источники обратной связи для нашего продукта:
Организуем идеи
Так как фидбэка у нас очень много, то мы постоянно наводим порядок в нашем продуктовом бэклоге. Это помогает нам быстро находить нужные вещи и не отвлекаться на ненужные.
Как мы структурируем наш product backlog:
Делаем Lean-приоритизацию
Периодически, по мере накопления новых идей мы оцениваем их с помощью метода Lean Prioritization. Это простая матрица 2×2 c двумя осями — сложность и ценность:
1) Улучшают метрики конверсии trial-to-paid (metrics movers)
2) Помогают привлечь новых пользователей (aha-момент)
Это фичи, которые помогают нам зацепить новых пользователей во время онбординга. Но не нужно забывать про то, что большинство юзеров «отвалиться» уже на второй день. Например, в SaaS отличным показателем для day 1 retention считается 15%. То есть 85% людей попросту уходят на второй день. Поэтому здесь следует думать про фичи, которые увидит как можно больше новых пользователей как можно ближе к моменту регистрации.
3) Помогают удержать старых пользователей
Клиенты купили подписку и теперь просят сделать какую-то фичу. Мы не «бросаемся» слепо делать все подряд. Мы накапливаем статистику по каждой фиче — сколько клиентов ее просили. И потом делаем самые востребованные фичи.
4) Добавляют ценности продукту и отстраивают нас от конкурентов
На рынке порядка 500 систем управления проектами. Чтобы выжить и преуспеть, нам нужно делать что-то совершенно новое, желательно кратно улучшающее жизнь пользователей или кратно сокращающее издержки.
Здесь мы ищем фичи, которые могут дать нам конкурентное преимущество, то есть создадут причину, из-за которой клиенты конкурентов придут к нам. Это конкурентное преимущество должно быть уникально, трудно повторимо и, в идеале, не воспроизводимо.
Planning Poker
Для оценки идей мы используем Planning Poker:
Техники приоритизации
Daniel Zacarias собрал в коллекцию 20 техник приоритизации и сгруппировал их по двум свойствам — внешняя/внутренняя и количественная/качественная техника.
Пример внешней количественной техники — модель Кано, где мы даем опросник пользователям. А пример внутренней количественной техники — Lean Prioritization (или Value vs Cost). Я описал этот метод выше.
Скоринг Фичей
Скорим мы не все фичи, а только те, которые выиграли в Lean Prioritization, потому что скоринг — трудозатратная операция.
Мы оцениваем каждую фичу по выбранным критериям, по шкале от 0 до 10. Далее эти значения умножаем на веса и получаем некую финальную числовую оценку, которая позволяет нам сравнивать фичи между собой.
Критерии для скоринга
Вот различные критерии, которые можно использовать для скоринга:
Результаты
Итак, какие результаты принес нам этот процесс:
О том, какими бывают фичи, и как они создаются, будет рассказано в данной статье.
Виды и задачи фич
Чаще всего различные фичи используются:
в игровой индустрии. Фичами в играх могут быть необычные поведение персонажей или система диалога, конструкторы или внезапные сюжетные ходы;
в ПО основной фичей является кардинально новое оформление интерфейса;
В концепции продукта фича решает следующие задачи:
формирует механизм возвращения. Фичи должны быть привлекательными для пользователей и вырабатывать у них привычку к использованию функций сайта или приложения;
дает возможность измерять активацию пользователей продукта с помощью специальных метрик;
служит для повышения числа возвращений, вовлечений и для повышения монетизации продукта.
Кроме того, фичи должны «работать» на формирование положительного пользовательского опыта (UX). Это важно для успешности релиза, который должен иметь, благодаря внедрению тех или иных фич, высокие метрики. Фичи, которые делают продукт компании уникальным и отсутствуют в продуктах конкурентов, называются киллер-фичами.
Как фичи внедряются в продукт
Как правило, создание фич происходит обособленно от разработки общего продукта и включает следующие этапы:
формулирование основных целей, которых поможет достичь внедрение фич в проект (например, увеличение числа пользователей, приобретающих платную подписку, или отрыв от конкурентов);
выбор основных и вспомогательных метрик (ими могут быть количество посетителей, которые зарегистрировались на сайте, активация пользователей, понимающих ценность фичи, удержание пользователей);
сбор идей с помощью интервью, опросов, А/В-тестирования, записей на видео пользовательских сессий, UX-тестирования, продуктовой аналитики и анализа конкурентов;
расстановка приоритетов создания фич. Фичи оцениваются по их ценности (вкладу в продукт) и по трудозатратам на их реализацию. В зависимости от этих критериев фичи делятся на: Quick Wins (дающие большую ценность и наиболее быстро создаваемые), Big Bets (ценные, но труднореализуемые), Maybes (те, что легко реализуются, не имеют большой ценности и могут быть разработаны позже), Time Sinks (фичи не в приоритете);
отбор (скоринг) фич по критериям и их оценка по шкале от 0 до 10. Сравнение проводится по целевым метрикам, увеличению прибыли, привлечению и удержанию клиентов, по стратегической ценности и по иным параметрам;
внедрение фич в продукт и тестирование результатов. На этом этапе устраняются фичи, блокирующие развитие продукта, а также может быть создан новый альтернативный функционал.
ЦРК БИ (ЦЕНТР РАЗВИТИЯ КОМПЕТЕНЦИЙ В БИЗНЕС-ИНФОРМАТИКЕ) НИУ ВШЭ приглашает всех желающих пройти обучение по созданию успешных и ценных фич для различных направлений IT. Записаться на данные курсы можно на нашем сайте.
Оценка важности «фичей» для нелинейных моделей
Задачи, которые сегодня решает машинное обучение, зачастую являются комплексными и включают в себя большое количество признаков (фичей). Из-за сложности и многообразия исходных данных применение простых моделей машинного обучения часто не позволяет достигнуть необходимых результатов, поэтому в реальных бизнес-кейсах применяют сложные, нелинейные модели. У таких моделей есть существенный недостаток: из-за их сложности практически невозможно увидеть логику, по которой модель присвоила именно этот класс операции по счету. Особенно большое значение интерпретируемость модели играет, когда результаты ее работы необходимо представить заказчику — он скорее всего захочет узнать, на основе каких критериев принимаются решения для его бизнеса.
В стандартных пакетах для машинного обучения, таких как sklearn, xgboost, lightGBM существуют методы для оценки важности влияния на конечный результат той или иной фичи (параметра). Однако эти метрики важности не дают представление о том, как именно эти признаки влияют на предсказания модели. Например, как время проведенной операции указывает на то, была ли сделка мошеннической? Или как сильно адрес прописки владельца карты смещает предсказание модели? Для ответа на эти вопросы необходимо найти комплексное решение, которое помогло бы повысить интерпретируемость нелинейных моделей. Таким инструментом является библиотека SHAP. В библиотеке SHAP для оценки вклада фичей в итоговое предсказание моделей рассчитываются значения Шэпли. Для оценки важности фичи происходит оценка предсказаний модели, которая была обучена на основе датасета с и без данной фичи.
Рассмотрим работу данной библиотеки на примере определения мошеннических операций. Рассмотрим поля, которые есть в нашей таблице. В таблице содержится 213 столбцов, что довольно много для ручного перебора с помощью метода обучения модели без каждого признака поочередно для выявления важности каждой из фич.
Приведенный ниже код взят с kaggle и доработан для демонстрации функций рассматриваемого инструмента.
Загрузим наши датасеты:
В данном датасете представлена информация о времени транзакции, времени последней транзакции, домены электронных почт продавца и покупателя, временной промежуток между последней и предыдущей транзакцией и другие параметры, смысл некоторых был скрыт из соображений конфиденциальности.
Для решения поставленной задачи, которая заключается в обнаружении подозрительных (мошеннических) банковских транзакций, необходимо провести предобработку данных, так как данные весьма разнородны. Необходимо заменить категориальные переменные, нормализовать числовые значения, заполнить пропуски, а также создать новые признаки для модели.
После обучения модели на обработанных данных была получена следующая картина важности признаков.
Сделаем график важности фичей:
Исходя из этого видно, что большую значимость на определение мошеннических действий влияют дополнительные признаки, которые не имеют детального описания. Возникает вопрос: каким образом влияют эти признаки на работу классификатора? В таком формате информативность таблицы оценки важности признаков очень мала. Мы точно не знаем, что это за признак и мы абсолютно не знаем, как он влияет на конечный результат. Для того, чтобы получить интерпретируемый результат, применим библиотеку SHAP. В результате получим график, который показывает влияние признаков на то, какой вердикт сделает модель: была ли транзакция мошеннической или вы действительно покупаете моющие средства на сумму 20 тыс. рублей или 50 арбузов.
Сделаем график важности признаков для нашей нелинейной функции:
На графике присутствует информация о том, как сильно каждый параметр влияет на результат предсказания модели. Сам график разделен на 2 части вертикальной чертой. Слева от него находится класс «0», а справа класс «1». Толщина линии на графике напротив параметра показывает нам, как много элементов присутствует в выборке с данным значением конкретного параметра. Чем краснее точки на графике, тем большее значение имеет фича в ней. Исходя из легенды, которую предоставляют нам разработчики, библиотеки и получившегося графика, можно сделать вывод: чем выше была сумма транзакции, тем выше вероятность, что она была мошеннической. Также на предсказание модели сильно влияет адрес владельца карты, а также его домен email.
На основе полученных данных можно облегчать модель, то есть оставлять только параметры, которые оказывают значимое влияние на результаты предсказания нашей модели. Кроме того, появляется возможность оценить важность фичей для отдельных подгрупп данных, например, клиенты из разных регионов, транзакции в разное время суток и т. д. Кроме того, данный инструмент можно применять для анализа отдельных случаев, например, для анализа «выбросов» и экстремальных значений. Также SHAP может помочь в поиске западающих зон при классификации негативных явлений. Данный инструмент в комплексе с другими подходами позволит сделать модели более легкими, качественными, а результаты интерпретируемыми.
Эффективный шаблон описания Фичей в SAFe®
Шаблон описания Фичи от Марка Ричардса, поддерживающий следование Lean UX.
Перевод статьи Mark Richards Effective Feature Templates for SAFe выполнен с разрешения автора.
Введение
Фича является ключевым драйвером потока создания ценности в SAFe®, но она также является источником большой путаницы среди практиков. Определение фреймворка такое: “Каждая фича включает гипотезу успеха и критерии приемки, и имеет такой размер или декомпозируется при необходимости, чтобы быть доставленной одним Agile Release Train (ART) в Инкременте Программы (Program Increment, PI)”.
Очевидно, что необходимо иметь больше информации по Фиче и поэтому, кажется, уже бесчисленное количество раз я участвовал в разработке шаблона Фичи с Продуктовым Менеджментом. Студенты моих тренингов просили меня дать им шаблон Фичи, но примеры, которые у меня есть, принадлежат моим клиентам, я не могу ими поделиться.
Новый акцент на Lean UX в SAFe 4.5 вдохновил меня потратить некоторое время на создание собственного шаблона Фичи, которым я мог бы поделиться. Результатом этого является синтез повторяющихся паттернов, которые я наблюдал во время своего коучинга, в котором основное внимание уделяется необходимым компонентам с рекомендациями по дополнительной информации, которая может потребоваться.
Как много деталей необходимо и когда?
Я разделил цикл уточнения Фичи на 2 этапа:
На этом этапе необходим такой уровень детализации, который позволяет оценить стоимость задержки (Cost of Delay) и определить размер Фичи. Информация — это инвентарь, и нам нужна простая схема хранения, пока приоритет Фичи не укажет, что ее необходимо подготовить для PI-планирования.
С этой целью в моем шаблоне ключевое внимание уделяется использованию канваса оценки WSJF (прим. ред. — Более Ценная и Короткая Работа Сначала — Weighted Shortest Job First, WSJF), и я даю несколько рекомендаций по возможному расширению деталей для подготовки к PI-планированию.
Канвас Фичи (Feature Canvas)
(прим. ред. — исходник Канваса Фичи)
Описание проблемы (Problem Statement)
Используя работу Джеффа Готельфа в Lean UX, мы основываем Фичу на определении проблемы, для решения которой она предназначена. Готельф предоставляет здесь два отличных шаблонна:
“Текущее состояние [домен] сосредоточено в первую очередь на [сегмент пользователей, болевые точки и т.д.].
Существующие продукты/услуги не могут решить [этот пробел].
Наш продукт/услуга восполнит этот пробел при помощи [видение/стратегия].
В первую очередь мы сфокусируемся на [сегменте пользователей]”.
“Наш [продукт/услуга] предназначена для достижения [целей].
Мы видим, что наш [продукт/услуга] не достигает [целей], что оказывает [негативное воздействие] на наш бизнес.
Как мы можем улучшить [услугу/продукт], чтобы наши клиенты были более успешными на основе [измеримых критериев]?”
Гипотеза Фичи (Feature Hypothesis)
Аналогично на основе работы Готельфа мы формулируем гипотезу о том, какое влияние может оказать наша Фича. Шаблон гипотезы имеет вид:
“Мы верим, что достигнем [бизнес-результат], если [сегмент пользователей] успешно достигнет [пользовательский результат] посредством [Фичи]”.
Цели и Ключевые Результаты (Objectives and Key Results, OKRs)
Фичи предназначены для достижения поддающегося проверке результата, эта деталь имеет решающее значение для обеспечения эффективной оценки стоимости задержки (Cost of Delay) и проверки влияния после развертывания. Мы хотим, чтобы поддающееся количественной оценке движение определенных опережающих индикаторов поддерживало текущую эволюцию нашей стратегии управления продуктами.
Как уже было описано в этой статье, я стал большим поклонником OKR, опробованной в Intel и популяризированной Google. Я считаю, это полезный инструмент для определения влияния Фичи.
Если OKR кажутся сейчас излишними, вы можете вместо этого перечислить опережающие индикаторы и ожидаемые изменения этих индикаторов.
Компоненты стоимости задержки (Cost of Delay Components)
Эффективность / объективность воркшопов по оценке стоимости задержки во многом определяется данными в таблице. Три раздела: «Ценность для пользователя / бизнеса (User/Business Value)», «Критичность сроков (Timing Criticality)» и «Снижение рисков / открытие возможностей (Risk Reduction/Opportunity Enablement)» предоставляют возможность выделить вспомогательные данные для оценки трех компонентов стоимости задержки.
Ключевые эксперты (Key Subject Matter experts)
Я редко, если вообще когда-либо такое было, работал с ART, в котором Продуктовый Менеджмент самодостаточны в экспертных знаниях предметной области. Важное значение имеет выявление и взаимодействие на ранних этапах жизненного цикла Фичи с экспертами в данной предметной области.
Внешние зависимости (External Dependencies)
Ничто так не тормозит Фичу, как невыявленные внешние зависимости. Они должны быть идентифицированы как можно раньше и использоваться для обсуждения приоритезации и разработки дорожных карт.
Нефункциональные требования (Non Functional Requirements)
Мы знаем, что ART имеет ряд нефункциональных требований, применимых ко всем Фичам, но иногда у конкретной Фичи есть свои нефункциональные требования.
Пример заполненного канваса Фичи
Придумать шаблон Фичи было невероятно сложно, потому что я все время думал о реальных Фичах, но в конце концов я остановился на придуманной Фиче для бронирования столиков в ресторане. 
Так вы могли бы визуализировать свой следующий семинар по оценке WSJF: 
Детали за пределами канваса
Когда Фича выбирается в качестве кандидата на предстоящий Инкремент Программы, запускается сбор дополнительной информации. Насколько детально стоит изучать Фичу зависит от конкретного ART и от его текущего этапа эволюции.
Как минимум, потребуются критерии приемки. Ниже перечисление других моментов, которые следует учитывать:
Настройка шаблона
Практически все ARTs, с которыми я работал относились к двум категориям: “Слишком много предварительной информации” или “Недостаточно предварительной информации”. Вы хотите знать достаточно, чтобы команды и Владельцы Продуктов могли эффективно планировать и доставлять итеративно, но не настолько, чтобы ограничивать возможности команд и Владельцев Продуктов вводить новшества и брать на себя ответственность за их интерпретацию.
Каждый Инкремент Программы — это возможность учиться. Подведите итоги через неделю после PI-планирования и посмотрите как на ту информацию, которую вы хотели бы получить, так и на свои наблюдения относительно ценностного предложения предоставленной вами информации.
Затем снова подведите итоги после Инкремента Программы. Посмотрите, как доставлялись Фичи и какие моменты вы хотели бы избежать в будущем.
Кто заполняет канвас Фичи?
Продуктовый Менеджмент является ответственным за уровень Бэклога Программы, следовательно, они являются основными владельцами. Однако, одним из приятных моментов, которые Lean UX привнес в SAFe 4.5, является реальный акцент на «совместном проектировании». Чтобы избежать ненужной передачи знаний, лучше всего проработать большую часть деталей (включая подготовку основы канваса) Владельцам Продуктов и командам, которые, вероятно, будут внедрять эту Фичу.
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.