Фичи в программировании это

Что такое фича и как приоритизировать фичи с помощью Unit-анализа

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

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

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

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

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

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

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

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

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

• Выявляются и описываются новые задачи, а существующие при необходимости изменяются или удаляются.
• Расстановка приоритетов. Самые важные задачи передвигаются наверх.
• Высокоприоритетные задачи подготавливаются к ближайшему обсуждению и к планированию спринта. Они декомпозируются и детализи­руются.
• Команда определяет масштаб набора задач в бэклоге продукта. Это необходимо ввиду внесения в него новых элементов, изменения существующих и исправления оценок.

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

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

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

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

Источник

Фича: что это значит?

Сленговое слово «Фича» происходит от английского слова «feature», и переводится как «Особенность».

Время чтения — 3 минуты

Поделитесь статьей в социальных сетях

Что такое фича в программировании?

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

Часто слово фича ставят как синоним к слову фишка, что означало какую-либо изюминку в изделии.

Это довольно распространенное сленговое слово, которое связанно с тем, что разработанная программа работает не так, как изначально планировалось. Иногда программисты используют данное фразу: «Это не баг, а фича!».

В чем цель фичи?

Цель фичи состоит в улучшении характеристики программы или привлечение внимания пользователей своей необычной функцией.

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

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

Выводы

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

Источник

Фича — что это значит

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

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

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

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

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

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

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

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

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

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

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

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

Источник