Фича что это такое простыми словами в бизнесе

Фича — это сленговое слово, которое пришло в русский язык из компьютерного и в переводе с английского означает «особенность» (feature). Это не просто отличительная черта, а именно полезная дополнительная функция, классная доработка или привлекательная деталь гаджета, улучшенная характеристика продукта.

Программисты называют фичами доработки кода, которых не было в базовом варианте и без которых программа все еще будет корректно работать. Но такая доработка дает дополнительные возможности, расширяет функционал и привлекает пользователей.

Фича в маркетинге — это часть продукта с необычной полезной характеристикой, нестандартное решение, которое помогает привлечь покупателей или продать товар дороже.

Уникальный дизайн вещи или предмета тоже называют фичей: чайник с подсветкой, оригинальная застежка на сумке, технологичная деталь в автомобиле.

Виды фич

В среде компьютерщиков и маркетологов фича фактически приобрела статус термина и обрела классификацию.

Киллинг фича, от «killing feature» — убойная/убийственная фича. Уникальное свойство продукта, которое делает его лидером рынка и существенно отстраивает от конкурентов. Это может быть как часть продукта, так и весь продукт целиком. Прорывная технология в отрасли или особая функция, которой нет у конкурентов и не предвидится в ближайшем будущем.

Например:

• Киллинг фичей в мессенджере Телеграмм долгое время было шифрование данных. Специальное кодирование защищает чаты от посторонних атак и обеспечивает приватность. Но уже появились другие мессенджеры, в которых конфиденциальность — не дополнительный режим, а принцип работы.
• Скейтборд был изобретен серферами, чтобы кататься на берегу, пока нет волн. Первую модель выпустила компания Makaha Surf & Ski Skateboard и около десяти лет удерживала рынок, пока конкуренты не подхватили идею.
• Облачные вычисления, сенсорный экран, блютус, блокчейн — убийственных фич больше всего появляется в сфере технологий.

Киллинг фичи двигают прогресс вперед. Конкуренты стремятся создать подобный продукт или улучшить имеющийся, поэтому убойная технология может быстро потерять свой статус и превратиться в базовую.

Базовая фича — основная функция, которая определяет ценность продукта для потребителя и без которой он перестанет им пользоваться.

Например:

• Мессенджер Телеграмм без функции шифрования данных быстро растеряет своих поклонников.
• Чемодан с колесиками, ради которых его приобрели, без них станет обычным хранилищем хлама, потому что потеряет свою основную функцию — перевозить тяжелый груз.
• Смартфон с морально устаревшей камерой и низким качеством снимков, которое сильно отстает от флагманских моделей, вы, скорее всего, замените на новую версию.

Вау-фича — неожиданная фишка, которая делает пользование продуктом особенно приятным или удобным. То, чего не ждут. Но ради чего могут выбрать или купить этот продукт, оставить восторженные отзывы, похвастаться друзьям.

Например:

• Пользоваться чайником с подсветкой гораздо приятнее, чем обычным.
• Узнать стоимость поездки на такси Uber заранее — большой плюс для клиентов. Когда сразу знаешь, сколько платить, проще принимать решение.
• Сим-карта в Apple Watch позволяет заниматься своими делами и оставаться на связи независимо от того, где находитесь вы и где оставили смартфон.

Вау-фича будет привлекать пользователей только в том случае, если базовые функции продукта хорошо отлажены и работают. Сама по себе она бесполезна и нужна в качестве приятного дополнения к основным рабочим характеристикам:

• если чайник не греет воду, то от подсветки будет мало толку;
• если такси долго не едет, то неважно, сколько стоит поездка;
• если бы Apple Watch были неудобными, нефункциональными, неэстетичными, то только ради сим-карты их бы никто не купил.

Конкуренты очень быстро подхватывают идеи и используют в своих наработках, поэтому фишки из разряда «вау» в скором времени становятся базовыми характеристиками.

Какие задачи выполняет фича

Фичи нужны, чтобы привлекать покупателей, продавать товар и в конечном итоге приносить прибыль.

Основные задачи, которые помогают решить дополнительные функции:

• Делают продукт более удобным, дорабатывают недостатки, которые не были учтены при начальной разработке, добавляют пользы в конечный продукт.
• Выделяют продукт на фоне конкурентов (вау-фишки).
• Вырабатывают привычку и удерживают пользователей (базовые фичи).
• Захватывают новые сегменты рынка или отстраивают продукт от конкурентов (киллинг-фичи).
• Выстраивают оптимальную стратегию и направление развития. Даже неудачные обновления важны, так как показывают, в каком направлении не нужно двигаться, что сейчас не интересует потребителей.

Если не добавлять в продукт новые фишки, то он перестанет быть полезным аудитории, и она уйдет к конкурентам. Поэтому предприниматели, маркетологи, основатели стартапов постоянно ищут новые интересные идеи, тестируют и внедряют их, чтобы повысить ценность продукта для пользователя и развивать бизнес.

Как правильно выбрать фичу

Для начала ее нужно придумать. Главные идеи приходят от пользователей. Они могут быть явными или не очень, могут поступать в виде жалоб, советов, лайфхаков по использованию продукта, прямых запросов.

На что обратить внимание, чтобы найти идею:

• запросы пользователей в службу поддержки;
• самые посещаемые страницы сайта, вкладки приложения — возможно, это наиболее интересные направления для развития;
• отзывы клиентов — иногда люди напрямую просят добавить определенный функционал;
• жалобы — неудобно искать товар в онлайн-магазине, быстро оторвалась ручка сумки, кнопка устройства в неудобном месте;
• предложения разработчиков — людей, которые видят неочевидные подводные камни в продукте или, наоборот, перспективные возможности;
• случайные ошибки или баги — много фичей, особенно в игровой индустрии, появилось благодаря ошибкам. Например, криперы в Minecraf, прыжки Super Mario. Эти баги вовремя не заметили, они понравились пользователям и превратились в фичи.

Не каждая фича будет полезной и приведет к росту популярности у пользователей. Чтобы определить возможный потенциал, нужно понять, понравится ли фишка потребителям и повысит ли ценность продукта.

Прежде чем приступать к реализации новой функции, ответьте максимально подробно на следующие вопросы:

• Кому нужна эта фича?
• Какие проблемы пользователей она решает?
• За счет чего новшество улучшает основной продукт и его использование?
• Как люди узнают об этом обновлении, как оно активируется?
• Чем мотивировать потребителей, чтобы они заинтересовались фичей?
• Будут ли люди предлагать эту фишку знакомым, хвалиться ей?

Эти вопросы дадут ответ на начальном этапе запуска. Насколько новшество будет востребовано и не ухудшит ли базовые характеристики продукта. Это важно. Иногда лучше вовремя отказаться от лишних функций.

При дальнейшей реализации фичи необходимо систематизировать сведения, которые есть в распоряжении владельца продукта, чтобы отделить полезные фичи от ошибочных. При этом важны не только исходные характеристики, которые были заложены при разработке, но и обратная связь от пользователей.

Уточните следующие моменты:

• Как пользователи отзываются об этой фиче?
• Есть ли расхождения между вашим исходным мнением и точкой зрения потребителей?
• Какая часть потребителей будет пользоваться фичей?
• Кто эти люди?
• Как выделить этот сегмент из общей базы и сделать функционал доступным для них?
• Чем привлекать и где искать этих людей, по каким интересам?
• Как можно монетизировать основной продукт с помощью фичи?

Что получаем:

— придумали идею;

— определили ценность и полезность новой фичи,

— выяснили, вписывается ли обновление в концепцию продукта, соответствует ли ожиданиям рынка и насколько жизнеспособно в долгосрочной перспективе.

Если все сложилось в единый пазл, значит, новшество имеет ценность для клиентов и с высокой вероятностью будет востребовано.

Главные мысли

22.09.2020

Фича (от английского feature — особенность, необычное свойство) — это определенная деталь или часть продукта, которая имеет специфические характеристики. Также фичами называются механизмы, позволяющие добавлять новые функциональности, веб-части и элементы дизайна в продукт.

О том, какими бывают фичи, и как они создаются, будет рассказано в данной статье.

Виды и задачи фич

Чаще всего различные фичи используются:

• в игровой индустрии. Фичами в играх могут быть необычные поведение персонажей или система диалога, конструкторы или внезапные сюжетные ходы;

• в ПО основной фичей является кардинально новое оформление интерфейса;

• в создании сайтов — в роли фич на сайтах выступают различные подсказки и фильтры, нестандартные слайдеры и визуализация предлагаемых товаров или услуг, адаптивность под мобильные устройства.

В концепции продукта фича решает следующие задачи:

• формирует механизм возвращения. Фичи должны быть привлекательными для пользователей и вырабатывать у них привычку к использованию функций сайта или приложения;

• дает возможность измерять активацию пользователей продукта с помощью специальных метрик;

• служит для повышения числа возвращений, вовлечений и для повышения монетизации продукта.

Кроме того, фичи должны «работать» на формирование положительного пользовательского опыта (UX). Это важно для успешности релиза, который должен иметь, благодаря внедрению тех или иных фич, высокие метрики. Фичи, которые делают продукт компании уникальным и отсутствуют в продуктах конкурентов, называются киллер-фичами.

Как фичи внедряются в продукт 

Как правило, создание фич происходит обособленно от разработки общего продукта и включает следующие этапы: 

• формулирование основных целей, которых поможет достичь внедрение фич в проект (например, увеличение числа пользователей, приобретающих платную подписку, или отрыв от конкурентов);

• выбор основных и вспомогательных метрик (ими могут быть количество посетителей, которые зарегистрировались на сайте, активация пользователей, понимающих ценность фичи, удержание пользователей);

• сбор идей с помощью интервью, опросов, А/В-тестирования, записей на видео пользовательских сессий, UX-тестирования, продуктовой аналитики и анализа конкурентов;

• создание структуры идей — их отбор по компонентам, по сферам применения, по стратегической важности, по взаимосвязям проблем пользователей с востребованностью фич;

• расстановка приоритетов создания фич. Фичи оцениваются по их ценности (вкладу в продукт) и по трудозатратам на их реализацию. В зависимости от этих критериев фичи делятся на: Quick Wins (дающие большую ценность и наиболее быстро создаваемые), Big Bets (ценные, но труднореализуемые), Maybes (те, что легко реализуются, не имеют большой ценности и могут быть разработаны позже), Time Sinks (фичи не в приоритете);

• отбор (скоринг) фич по критериям и их оценка по шкале от 0 до 10. Сравнение проводится по целевым метрикам, увеличению прибыли, привлечению и удержанию клиентов, по стратегической ценности и по иным параметрам;

• внедрение фич в продукт и тестирование результатов. На этом этапе  устраняются фичи, блокирующие развитие продукта, а также может быть создан новый альтернативный функционал.

ЦРК БИ (ЦЕНТР РАЗВИТИЯ КОМПЕТЕНЦИЙ В БИЗНЕС-ИНФОРМАТИКЕ) НИУ ВШЭ приглашает всех желающих пройти обучение по созданию успешных и ценных фич для различных направлений IT. Записаться на данные курсы можно на нашем сайте.

← Назад к списку

Вы когда-нибудь сталкивались с выражением «тушить пожары»?
Это когда у вас постоянно появляется что-то важное и срочное, вы все бросаете и бежите сломя голову «потушить» этот срочный пожар, а потом еще и еще.
В итоге, вы тушили эти пожары целый год, и вроде бы хорошо тушили, а результата так и нет. Вдобавок вы еще сами «перегорели».

В этой статье я хочу вместе с Вами научиться уметь четко расставлять приоритеты, работать только на результат и радоваться каждому дню, которые не несет в себе кучи суеты и зашива.
И помните, зашив он «в голове», а теперь погнали

Что такое фича и в чем разница фичи от задачи?

Вы наверное слышали фразу «Это не баг, это фича». Это когда ошибку пытаются представить что «это так задумано». На самом деле, многие прикольные функции и правда появлялись случайно, в результате ошибки, а потом становились популярными у пользователей.
Так что же такое фича и в чем ее отличие от задачи?

Фича — это дополнительная функция или особенность продукта. Различают несколько видов:
— «базовая фича», которая является неотъемлемой частью продукта — например, возможность ответить на сообщение в мессенджере или поставить лайк в инстаграме;
— «киллер-фича» — это то чем мы значительно отличаемся от конкурентов;
— «вау-фича» — то, чего наш клиент не ждет, но такая функция может его покорить и сделать нашим клиентов навсегда.
Существенной разницы между фичей и задачей нет, это синонимы.
Но я бы все таки отметила, что фича больше описывает сам функционал и как с ним будет взаимодействовать пользователь, какую ценность он получит.
А задача это уже больше про исполнение. Вы решили сделать определенную фичу, и в свою очередь вы уже описываете требования к реализации этой фичи для исполнителя, т.е исполнителю вы уже ставите задачу.
А теперь представим, что в процессе проверки гипотез — у нас появилось 5 фичей и все они на первый взгляд кажутся важными и срочными, а разработчиков не хватает.

Зачем команде приоритизация задач?

Приоритизация задач в команде помогает понять, что следует выполнять в первую очередь, чтобы донести до пользователя максимум ценности продукта, заработать больше денег для компании и получать постоянные результаты в проделанной работе. Поверьте, команда профессионалов, которая не видит результатов своего труда, в скором времени покинет вас, поэтому не забываем о важности и двигаемся дальше.

Как расставить приоритеты, когда все кажется важным и срочным?

Существует тысяча способов и экспертных статей на эту тему в интернете, основная сложность — это изучить все эти методики и применить на практике, выбрать для себя «ту самую».
Но есть один главный вопрос на который вы должны ответить, прежде чем вы приступите осваивать методики приоритизации и становиться эффективным менеджером.
«Какая ваша Главная цель? Какой результат вы хотите по итогу достичь?»

Некоторым эти вопросы могут показаться довольно смешными и абсурдными. Но дело в том, что большинство так и двигаются, «по ощущениям»и «наитию».
Теперь предлагаю немного почитать как работать с бэклогом продукта, а далее я вам расскажу про технику приоритизации фичей с помощью юнит-анализа.

Что такое бэклог продукта и как работать с ним?

Бэклог — это упорядоченный (или нет) список задач для исполнителей. Проще говоря, в бэклоге собраны все ваши гипотезы, идеи, фичи, баги, которые рано или поздно будут реализованы командой.

Как работать с бэклогом?
Если сад надолго оставить без ухода, он зарастет. Так и бэклог продукта — когда им пренебрегают, он станет скоплением не нужных мыслей и идей. Ему нужны внимание, с бэклогом нужно постоянно работать.
Работа над бэклогом — непрерывный процесс, которые включает в себя:

Хотя владелец продукта отвечает за хорошее состояние бэклога продукта, работа над ним — это командный процесс.

Совместная работа над бэклогом продукта весьма продуктивна и интересна. Она порождает диалог как внутри команды, так и между командой.
Общение убирает разделение на «продукт-овнеров» и «технарей», требования становятся более ясными, к их разработке привлекаются коллективный опыт всей команды, создается ощущение причастности к общему делу.

Как приоритизировать задачи с помощью unit-анализа.

Юнит – это не единица товара, а одна продажа. Если мы продаем телефоны оптом, то юнит – это усредненная партия. Если у нас кафе, то юнит – это один усредненный заказ одного человека. Если мы сдаем склад для хранения личных вещей, то юнит – это усредненный объем хранения на одно домохозяйство.
Мы определили с вами, что называем юнитом. Теперь нам необходимо построить воронку продаж, т.е какой клиентский путь проходит пользователь чтобы узнать О Вас и в конечном счете Купить вашу продукцию.
Рассмотрим на примере покупки авиабилетов.
Допустим ваша воронка продаж выглядит так:
Количество показов — 1 000 (100%)
Количество переходов — 200 (20%)
Количество поиска авиабилетов — 100 (10%)
Количество броней — 10 (1%)
Количество покупок — 5 (0,05%)
Теперь смотрим на наш бэклог. У нас есть несколько фичей:
1. сделать чат, чтобы в случае вопросов, клиенты могли сразу к нам написать;
2. сделать кнопку Поиска авиабилетов ярче и больше;
3. сделать редизайн сайта, а то некрасиво сейчас;
4. сделать кнопку Забронировать без авторизации.
Вопрос — что будем делать в первую очередь?

На самом деле все просто. Главный наш инструмент — это воронка продаж. Посмотрите, где больше всего падает конверсия и теперь подумайте, что если эта конверсия вырастет в 2 два раза?
К примеру, что если мы увеличим количество броней с 1% до 3%?
Какое количество покупок мы получим? Верно, кол-во покупок вырастит прямопропорционально и покупок уже будет 15. Всего лишь 2 процентных пункта, а по продажам мы выросли в 3 раза.
Теперь смотрим в наш бэклог. У нас есть фича ,сделать кнопку Забронировать без авторизации. По сути, это даже не фича, а гипотеза. И каждый день мы должны генерить десятки таких гипотез, которые могут повлиять на изменение конверсии, конечно в большую сторону.
Дополнительно
Мы с вами определили точно какие задачи надо брать в работу с точки зрения бизнеса. Теперь нам надо отфильтровать задачи с точки зрения ресурсов.
Обязательно, приоритизированные задачи необходимо оценить уже с командой исполнителей и замерить сроки реализации.
Задачи имеющие высший приоритет и минимальный срок исполнения — это то что нас интересует. Конечно, бывают исключения, например авторизация поломалась, в таком случае мы все ресурсы кидаем на исправление чего-то супер критичного. В остальных случаях отталкиваемся от конверсии в воронках продаж и сложности исполнения.
Надеюсь, было полезно! Спасибо за внимание, делитесь в комментариях отзывами и вашим опытом)

«В Linux есть инновации. Есть некоторые действительно хорошие технические фичи, которыми я горжусь. В Linux есть возможности, которых нет в других операционных системах.»

Linus Torvalds, creator of Linux

Что такое Фичи и Капабилити?

Фича (Feature) — это сервис, который удовлетворяет потребности заинтересованных лиц. Каждая фича включает в себя гипотезу выгоды и критерии приемки, а также имеет размер или при необходимости декомпозируется, чтобы быть разработанной одним Agile Release Train (ART) за один Инкремент Программы (Program Increment, PI). Капабилити (Возможность, Capability) — это более высокоуровневое поведение решения, которое обычно охватывает несколько ART. Возможности определяются и разделяются на несколько фич, чтобы упростить их реализацию в одном Инкременте Программы.

Фичи также создаются, используя модель процесса Lean UX, которая включает в себя определение Минимальной Рыночной Фичи (Minimum Marketable Feature, MMF), гипотезу выгоды и критерии приемки. MMF помогает ограничить объем работ и инвестиции, повышает гибкость и обеспечивает быструю обратную связь. Капабилити (Возможности) ведут себя так же, как и фичи. Однако они находятся на более высоком уровне абстракции (имеют бОльший масштаб) и поддерживают определение и развитие крупных Решений.

В своей практике я практически регулярно встречаюсь с ситуацией, когда команда встает перед проблемой, что «эта История не декомпозируется». В результате в беклоге команды оказываются Пользовательские Истории и Истории Энейблеры достаточно большого размера, что приводит как минимум к высокой непредсказуемости результатов, а часто к невозможности завершить Итерацию (Спринт) вообще.

Связано это как правило с тем, что Владелец Продукта, а иногда и другие участники команды приписывают свойства MMF отдельной Истории. В SAFe эта проблема решена, поскольку «понятный и интересный для конечного пользователя функционал» (MMF) обязан существовать на уровне Фичи, но не является обязательным для Истории. Иными словами, элемент или часть ценности, доставляемый одной Историей, должен быть понятен команде, но необязательно конечному пользователю. Такой подход позволяет создавать более «технические» элементы ценности (Истории), повышая предсказуемость доставки и качество разрабатываемого решения. 

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

Фичи и Капабилити занимают центральное место в модели требований SAFe. Они имеют решающее значение для определения, планирования и реализации ценности Решения. На рисунке 1 представлен более широкий контекст для этих рабочих элементов:

Рисунок 1. Фичи в контексте SAFe

На рисунке 1 показано, что решения разрабатываются с использованием Фич. Каждая Фича отражает сервис, предоставляемый системой. Система в свою очередь удовлетворяет важные требования заинтересованных лиц. Фичи находятся в Беклоге Программы и имеют размер, позволяющий завершить их разработку за Инкремент Программы (PI). Таким образом, каждая Фича доставляет новую ценность за определенный период. Фичи могут возникать либо из локального контекста Agile Release Train (ART), либо в результате разделения Эпиков или Капабилити.

Канбан системы уровня Программы и Решения поддерживают поток фич и капабилити, где они проходят через все стадии: воронка, анализ, беклог, реализация, валидация, развертывание и выпуск. Этот процесс обеспечивает обоснованный экономический анализ, техническое влияние и стратегию для поэтапной реализации.

Менеджмент Продукта и Архитекторы (Инженеры) Систем владеют фичами и энейблерами соответственно. Нефункциональные требования (НФТ/NFR) определяют атрибуты системы, такие как безопасность, надежность, производительность, удобство обслуживания, масштабируемость и удобство использования. NFR выполняют роль требований или ограничений для проектирования системы во всех беклогах, к которым они относятся.

Фичи расставляются по приоритетам с помощью WSJF. Они планируются и рассматриваются на границах Инкремента Программы. Фичи разделены на истории и разрабатываются, интегрируются, тестируются и демонстрируются по мере появления соответствующей функциональности.

Поиск, выявление и описание Фич

Дизайн-мышление использует клиентоцентричный подход для создания желаемых и устойчивых продуктов. Инструменты дизайн-мышления, включая персоны (personas), карты эмпатии и карты пути клиентов (CJM), способствуют более глубокому пониманию клиентов и пользователей. Вместе они обеспечивают богатый контекст для лучшего понимания фич и их потенциальных выгод.

Фичи изначально определяются с помощью Матрицы Фич и Преимуществ (Features and Benefits, FAB Matrix):

• Столбец Фича – Короткая фраза, дающая имя и контекст (краткое описание и краткое обозначение области применения)
• Столбец Гипотеза Выгоды – Предполагаемая измеримая выгода для конечного пользователя или бизнеса предприятия

На практике при запуске SAFe часто возникают сложности с формулированием и использованием Гипотезы Выгоды. Эта важная часть клиентоцентричного подхода обычно обсуждается с представителями бизнеса, поскольку она напрямую связана с архитектурой потоков ценности в организации.

Ключевые вопросы, ответ на которые нужно держать в уме при формулировании Гипотезы Выгоды: «кто именно является клиентом для данной Фичи?» и «какая выгода делает данную Фичу востребованной со стороны этого клиента?»

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

Не определяйте фичи с помощью формата «голос пользовательской истории» (Голос Клиента / Голос Пользователя), который предназначен для поддержки одной роли пользователя. Обычно Фичи предоставляют функциональные возможности для нескольких ролей пользователей. Кроме того, использование одного и того же метода для описания пользовательских историй и фич может запутать большинство представителей бизнеса, тем более что они обычно не знакомы с Историями.

На рисунке 2 показан пример FAB с четырьмя разными фичами:

Рисунок 2. Матрица фич и преимуществ

Создание Фич и управление ими

Менеджеры Продукта в сотрудничестве с Владельцами Продукта и другими ключевыми заинтересованными лицами определяют фичи в локальном контексте Agile Release Train. Некоторые фичи возникают в результате декомпозиции эпиков.

Архитекторы Систем обычно создают фичи-энейблеры. Беклог программы используется для хранения энейблеров наряду с бизнес-фичами. Энейблеры «прокладывают путь» для реализации Архитектурного Русла, поддерживают исследования или могут обеспечить инфраструктуру, необходимую для разработки, тестирования и интеграции результатов.

Как и бизнес фичи, фичи- энейблеры могут возникать из эпиков или появляться локально на уровне Agile Release Train. Количество энейблеров, которые проходят через систему Kanban, регулируется аллокацией емкости в беклоге программы. Это позволяет добиться, чтобы внимание уделялось как работе над решением, так и расширению архитектурного русла. На каждой границе Инкремента Программы оценивается процентное соотношение ресурсов, которые выделяются на разработку новых бизнес-фич (или бизнес-капабилити) и работу с фичами-энейблерами (капабилити-энейблерами), чтобы направлять поезд в правильном направлении.

Приоритизация Фич

Модель приоритизации WSJF используется для определения последовательности выполнения работ (например, фич, капабилити) на основе экономики потока разработки продукта. Поскольку реализация необходимых работ в правильной последовательности дает максимальную экономическую выгоду, трудно переоценить важность этого процесса. Менеджент Продукта и Решения отвечает за приоритизацию фич, в то время как Архитекторы и Инженеры Систем и Решений — за приоритизацию энейблеров.

Оценка Фич

Оценка фич позволяет спрогнозировать доставку ценности с помощью модели приоритизации WSJF и определить размер эпиков, разделяя их на фичи и суммируя оценки каждой из них. Оценка фич обычно происходит на стадии анализа Канбана программы и опирается на нормализованные методы оценки. В ходе анализа профильные эксперты из Agile Release Train принимают участие в исследованиях и предварительной оценке размера. На стадии анализа определение размера фич не требует проведения декомпозиции их на истории или подключения всех команд, которые могут их разработать.

Приемка Фич

Критерии приемки Фич используются для определения того, является ли реализация правильной и обеспечивает ли она преимущества для бизнеса. На рисунке 3 приведен пример:

Рисунок 3. Фича с критериями приемки

Критерии приемки снижают риск разработки «неправильного» решения и позволяют на ранней стадии проверить гипотезу выгоды, обеспечивая согласованность между управлением продуктом, заинтересованными лицами и разработчиками. Критерии приемки также могут быть использованы в качестве источника для историй. Как и в случае с историями, критерии приемки часто трансформируются в приемочные тесты с помощью разработки на основе поведения (BDD).

Менеджмент Продукта несет ответственность за приемку фич. С помощью критериев приемки продуктовый менеджмент определяет, правильно ли реализована функциональность и выполнены ли нефункциональные требования.

Капабилити (Возможности)

Большая часть данной статьи описывает, как определить и реализовать фичи, так как они в первую очередь описывают поведение системы. Капабилити демонстрируют те же характеристики и методы, что и фичи. Например, они:

• Описываются с помощью фразы (краткие имя и контекст) и гипотезы выгоды
• Имеют размер, позволяющий разработать их за один Инкремент Программы. При этом обычно требуется вовлечение нескольких Agile Release Train.
• Обоснованы и одобрены с использованием Канбана Решения. Беклог Решения содержит утвержденные возможности (капабилити).
• Имеют связанные с ними энейблеры. Это позволяет описать и показать всю техническую работу, необходимую для поддержки эффективной разработки и доставки бизнес-капабилити.
• Принимаются Менеджерами Решения, которые используют критерии приемки для определения того, соответствует ли функциональность назначению.

Возможности (Капабилити) могут появляться в локальном контексте решения или возникать в результате разделения эпиков портфеля, которые могут охватывать более одного потока создания ценности. Другим потенциальным источником возможностей является контекст решения, где для некоторых аспектов среды может потребоваться новая функциональность решения.

Декомпозиция фич и капабилити

Капабилити должны быть декомпозированы на фичи для последующей разработки. Фичи в свою очередь разбиваются на Истории, которые команды берут в работу в рамках Итерации. SAFe предоставляет десять шаблонов для разделения работы, как описано в книге Leffingwell [1], глава 6.

• Шаги рабочего процесса
• Варианты бизнес-правил
• Значительные усилия
• Простой/сложный
• Различия в данных
• Различия в методах данных
• Выделение отдельных качеств системы
• Особенности эксплуатации
• Сценарии использования
• Выделение спайка (исследования, эксперимента)

На рисунке 4 показано разделение капабилити на фичи:

Рисунок 4. Декомпозиция капабилити на фичи

Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом статьи «Features and Capabilities».

Дополнительно читать:

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[2] Cтатья «WSJF, Weighted Shortest Job First»

Фича — это часть продукта с необычной характеристикой, с выделяющейся особенностью, со своей «фишкой». Это сленговое слово, которое используют в разработке и маркетинге.

Фича помогает:

• возвращать пользователей — интересные и необычные решения мотивируют всё чаще пользоваться продуктом;
• измерять активную аудиторию — фича может собирать данные по показателям;
• увеличивать монетизацию продукта — часто пользователи готовы платить за доступ к новым сервисам продукта.

Пример — одной из фич автомобилей марки Tesla является автопилот.

Рассказали также: что такое баг.