Фича что это такое простыми словами в бизнесе
Не баг, а фича. Что это значит и откуда появилась эта фраза?
Велик и могуч язык программиста. Иногда этот язык наполнен таким количеством сленговых слов, что его трудно понять не то чтобы простым пользователям, а даже молодым и начинающим программистам. Сегодня мы разберем, что значит довольно популярное выражение : « Э то не баг, а это фича» и когда оно применяется.
«Не баг, а фича!»
Что так ое «баг» в программировании?
Это довольно частый вопрос, потому что слово «баг» не всегда связано с программированием. В программировании «баг» — это ошибка в программе или в приложении, которая приводит к тому, что программа или приложени е не работают как следует. Само слово «баг» происходит от английского слова «bug». По причине воздействия бага на программу мы получаем продукт, при работе которого происходит нежелательный конечный результат.
Баг имеет широкую градацию по способу собственного возникновения и влияния на конечный продукт. Сегодня мы не будем на этом останавливаться, отметим лишь, что все возникающие баги объединя ю т следующие свойства:
Что такое « фича » в программировании?
Фича в программировании — это некая новая функция или особенность программы, которая ранее не была о г оворена, но в результате не нарушает функциональность программы, а приносит какое-то дополнение в ее работу. Фича происходит от английского слова «feature». Ее цель — улучшить характеристики программы или просто привлечь внимание пользователей своей необычной функцией.
Понятие «фича» существует не только в программировании, оно уже часто употребляется и в обыденной жизни. К примеру, фичами в быту именуют нестандартные функции или дизайн какого-нибудь устройства.
Фича в программировании — это контролируемый результат, который создается специально руками программиста, чтобы улучшить разрабатываемую программу или просто удивить пользователей или заказчика. Фичи часто не нужно исправлять, потому что они очень органично приживаются с самой программой.
Мы можем предположить, что такое выражение может употребляться в качестве оправдания разработчика перед заказчиком, когда тот обнаружил баг в программе. Но часто это совсем не так.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Как понять, что новая фича принесет пользу продукту, а не навредит ему?
Когда продукт выходит на рынок и находит целевую аудиторию, работа над ним не заканчивается. Предприниматели и продакты всегда ищут идеи повышения ценности для пользователей.
Как понять, что функция понравится потребителям и будет для них полезна? Для этого используют критерий feature/product fit. Он помогает определить ценность новой фичи и ее влияние на развитие продукта в целом. Далее мы более подробно поговорим об этом показателе, а также приведем несколько интересных примеров из практики.
Что такое Feature/Product Fit?
Регулярное улучшение продукта — способ развития и привлечения новых клиентов. Если не добавлять в приложение или сервис новые функции, рано или поздно аудитория уйдет. Им просто надоест пользоваться одним и тем же, или появится конкурент, который сделает круче.
Поэтому команды занимаются постоянным поиском новых идей для дополнений и их реализацией. Главная проблема — отсутствие понимания, что подтолкнет продукт вверх и понравится пользователям, будет ценно для них и поможет решать проблемы.
Процесс оценки полезности новой фичи, в целом, схож с определением соответствия продукта ожиданиям рынка. Но есть и некоторые отличия.
Определяя product/market fit есть три основных компонента:
Возвращение. Доля клиентов, которые выработали привычку пользоваться сервисом и регулярно взаимодействуют с ним.
Монетизация. Возможность и конкретные способы заработка на привычке пользователей.
Привлечение. На основе двух первых пунктов определяют оптимальную стратегию по привлечению новой аудитории.
Кстати, недавно мы подробно рассказывали, что такое product/market fit, для чего он нужен и как измеряется. Советуем почитать для лучшего понимания определения ценности и полезности новых функций.
Feature/product fit показывает, вписывается ли новая фича в общую концепцию продукта:
У функционала должен быть свой механизм возвращения.
Должна быть своя измеримая активация.
Функционал должен улучшать возвращение, вовлечение и/или монетизацию основного продукта.
Очень хорошо, когда новая функция привлекает новых клиентов и они регулярно взаимодействуют с ней. Но релиз можно считать проваленным, если она не улучшает UX продукта в целом. В таком случае новая фича каннибализирует на другой части продукта.
Поэтому задача команды — еще на стадии планирования определить, как повлияет новая функция на продукт в целом. Поможет ему вырасти или нет. Для оценки этого используют показатель feature/product fit.
В чём заключается работа команды?
Часто команда разработчиков занимается каким-то конкретным функционалом, и она не ставит перед собой задачу улучшения UX продукта. Специалисты хотят добиться, чтобы все использовали именно их решение. То есть они не концентрируются на продукте в целом. Такой подход имеет краткосрочный эффект, в долгосрочной перспективе это не принесет успеха.
Хороший пример работы — ориентирование на продукт, поиск подходящего места новой фичи в приложении или сервисе. Иными словами — определение своего feature/product fit.
Для этого оценивают метрики, о которых говорили ранее: возвращение и активацию в фичу и возвращение, привлечение и монетизацию в основной сервис. Наравне с этим не забывают определить, среди каких потребителей новый функционал будет пользоваться спросом.
Некоторые нововведения осознанно ориентируют на небольшой процент от общей аудитории. Это помогает сделать функционал инструментом, способствующим росту компании и увеличению общей доли возвращений в продукт, вовлечения и монетизации.
Чего команде стоит избегать в работе?
Более подробно остановимся на ошибках, которые чаще всего совершают команды. Избегайте их и тогда сможете достичь feature/product fit.
Рассылки обзора нового функционала всей базе клиентов
Всех интересует выгода, получаемая от использования сервиса, приложения, инструмента и т.п. Нет смысла отправлять всей аудитории сообщения об изменениях в одной функции, потому что ценность такой рассылки для конечного потребителя будет нулевой. В результате от email-рассылки может отписаться много людей, что негативно скажется на возвращении в основной продукт по этому каналу.
Используйте email-рассылку по базе клиентов для оповещения о глобальных изменениях в основном продукте, от которого потребители получают наибольшую ценность.
Рассказывать всем о новой функции
Новые функции, как правило, направлены на узкую аудиторию, то есть ими пользуются далеко не все потребители продукта. Несмотря на это, некоторые команды часто размещают на виду у всех крупный баннер с информацией о новой фиче.
Это приводит к снижению вовлеченности новых пользователей. Ведь им сначала интересно познакомиться с продуктом в целом. А если в лоб давать информацию о новых функциях, которые полезны далеко не всем пользователям, можно отвлечь потенциальных клиентов от продукта.
Преждевременная публикация новостей о новой фиче
Пиар нововведения сразу после выпуска обновления не поможет найти feature/product fit. Сначала надо убедиться, что новый функционал занял правильное место в продукте и понравился аудитории. Только после этого приступайте к распространению информации об обновлении: на официальном сайте, в самом приложении, социальных сетях и т.п.
Многие фичи не пройдут отбор
Не все функции, реализованные командой, приживаются в продукте и работают долгое время. Если новая фича не соответствует feature/product fit, удаляйте ее без угрызений совести. Росту продукта она не поможет, тогда в ней нет смысла.
Не забывайте про анализ старых возможностей проекта. В мире быстро меняются тенденции. То, что нравилось пользователям вчера, может сильно раздражать их сегодня. Поэтому в крупных компаниях регулярно проверяют функционал на соответствие этому показателю. Если какая-то функция перестает ему соответствовать, ее удаляют.
Например, раньше в социальной сети ВКонтакте у каждого пользователя был рейтинг. В конце 00-х пользователям нравилось осознавать свою популярность и то, что она больше, чем у кого-то другого.
Но со временем аудитория ВКонтакте поняла, что в этом нет никакого смысла. Когда фича перестала соответствовать feature/product fit, ее убрали (это было аж в мае 2011 года!).
До 2016 года в социальной сети Pinterest в каждой карточке были кнопки Like и Save. Но многие пользователи не понимали разницы между ними, думая, что нажатие Like автоматически сохраняет изображение в их галереи. Это приводило к неудовлетворенности некоторой части аудитории, поэтому в компании приняли решение удалить кнопку Like.
Инстаграм в начале 00-х годов позволял не только общаться и обмениваться фотографиями, но и организовывать с друзьями путешествия, объединяться в группы и т.п.
Каким был Instagram раньше (сложным и непонятным) и каким простым стал
Анализ показал, что весь этот функционал не пользуется популярностью у пользователей. Им больше нравилось публиковать фотографии и отмечать конкретные места. Но не все добирались до этого сквозь дебри других возможностей. После долгих обсуждений и тестов основатели компании решили отказаться от непопулярных функций, оставили основные и довели их до соответствия показателю feature product/market fit.
В физических продуктах feature/product fit также имеет место. Например, раньше все iPhone выпускались с физической кнопкой разблокировки экрана. Но в 2017 году в компании от нее отказались, отдав предпочтение Face ID (разблокировка сканером лица). Этому решению способствовала тенденция дисплеев с минимальной или полностью отсутствующей рамкой. Чтобы улучшить продукт в целом, Apple отказались от старой фичи.
Как найти фиче место в продукте или Feature/Product Fit?
Новый функционал редко выкатывают сразу на всю аудиторию (если речь идет о крупных проектах). Его тестируют определенный период времени на некоторых пользователях, чтобы собрать необходимую информацию и сделать выводы.
Например, Instagram в апреле 2019 году тестировал отказ от лайков. Для некоторых пользователей по всему миру эта функция оказалась недоступна. С того момента прошло уже больше года, больше об этой инициативе ничего не говорили. Возможно, результаты тестов не устроили компанию и они отказались от нововведения.
Обычно крупные компании в рамках тестирования распространяют новые фичи на 1-2% от общей аудитории. Конечно, если у вашего проекта не так много постоянных пользователей, «выкатывайте» новые функции на всю аудиторию. Только так вы получите сведения в том объеме, который необходим для принятия верного решения.
Разработка хорошего функционала, который понравится пользователям, начинается с анализа данных и исследования пользователей. И здесь нужно предугадать правильное время, когда вовлеченность аудитории будет на максимуме, а предвзятость — на минимуме.
Аналогичным образом действовал Instagram перед запуском IGTV. Одной из проблем сервиса были короткие видео. Из-за этого хромала «вовлеченность», а часть аудитории отдавала предпочтение YouTube из-за своих кумиров, которые там размещали длинные видео.
Так появился IGTV, который сегодня используют для публикации длинных роликов (более 60 секунд). То есть изначально компания провела анализ, узнала, чего не хватает пользователям, а затем придумала функционал для закрытия потребности. После нескольких тестов и достижения feature/product fit фичу «растянули» на всех пользователей.
Еще один хороший способ найти feature/product fit — прямое общение с пользователями продукта. Они оставляют жалобы, рекомендации, отзывы и просьбы в социальных сетях, форумах, блогах и т.п. Анализируйте эту информацию, возможно, удастся найти крутые идеи, которые помогут довести функционал до идеала.
The Feature/Product Fit чеклист
Если вы не уверены, будет ли пользоваться новая фича популярностью, задайте себе несколько вопросов и дайте на них подробные ответы:
Какие есть данные по использованию этой фичи?
Что говорят пользователи об этой фиче?
Как можно использовать основной продукт, чтобы новая фича принесла пользу?
Как можно использовать уведомления, чтобы активировать в эту фичу?
Какие стимулы я могу использовать, чтобы активировать в фичу?
Как люди могут помочь активировать в фичу?
Когда вы убедились в соответствии feature/product fit, задайте себе еще несколько вопросов:
Какой у этой функции retention? Достаточный ли?
Какой сегмент пользователей использует функцию повторно?
Как сделать этот функционал доступным только для них?
Какую измеримую стратегию активации в эту фичу можно применить для этих пользователей?
Как эта фича влияет на возвращение, вовлечение и монетизацию основного продукта?
Если вы только создаете продукт или уже вышли на рынок, ставьте для себя цель о его постепенном улучшении. Без доработки функционала, внедрения новых фич рано или поздно проиграете конкуренцию другим компаниям.
Для нового и старого функционала измеряйте feature/product fit. Это можно делать примерно так же, как с product/market fit. Об этом мы подробно рассказывали ранее.
Перед «выкатыванием» новых фич на всю аудиторию проверяйте, повышают ли они ценность продукта в целом. Если нет, отказывайтесь от внедрения. Пользуйтесь описанным выше чеклистом для упрощения проверки. А если у вас остались какие-то вопросы по feature/product fit, пишите их в комментарии, мы с радостью ответим.
Еще подробнее о Feature/Product Fit можно узнать на нашем годовом курсе «Профессия: Продакт»
«Не баг, а фича» — учимся понимать язык программистов
Понять смысл IT-терминов можно, только узнав, как они употребляются
Программисты говорят на особом языке, в котором полно терминов и сленга. Эта речь не всегда понятна не только обычным людям, далёким от компьютеров, но и начинающим айтишникам — новичкам в разработке.
Есть куча статей, объясняющих смысл терминов, но неподготовленному человеку от них мало пользы. И если вы общаетесь с программистами или собираетесь стать одним из них, то, скорее всего, во всём придётся разбираться самостоятельно. Иначе можете оказаться в ситуации, похожей на ту, что в клипе:
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Гораздо проще понять, что значит «пичупидо», если знать контекст, в котором употребляются все эти слова. Поэтому попробую объяснить некоторые термины и сленг на примере истории одного программиста (вымышленного).
Дисклеймер. Все совпадения случайны, а персонажи и ситуации вымышлены. В художественных целях они наделены негативными качествами, поэтому не берите с них пример: это касается как профессиональных качеств, так и отношения к алкоголю, курению и энергетическим напиткам. Также некоторые слова используются и в других сферах.
Новая задача
Ваня — обычный джун в веб-студии. Его работа — поддержка бэкенда сайтов старых клиентов студии.
Джуниор ( англ. junior — младший) в данном случае — младший разработчик в веб-студии. Также бывают мидл- ( англ. middle — средний) и сеньор-разработчики ( англ. senior — старший).
Бэкенд или бэк ( англ. back end — задний край) — серверная часть сайта или приложения, которая нужна для обработки и хранения данных. Его противоположность — фронтенд или фронт ( англ. front end — передний край) — видимая часть приложения или сайта. Если же разработчик занимается сразу фронтендом и бэкендом, его называют фуллстек-разработчиком ( англ. full stack — полная куча / полный набор).
Рабочая неделя Вани начинается с митингов, потому что спринт в его компании длится всего неделю.
Митинг — собрание, на котором обсуждается, что успели или не успели сделать сотрудники, а также чем они будут заниматься в новом спринте.
Спринт — период от одной до четырёх недель, за который сотрудники должны успеть выполнить задачу или задачи. Спринты являются частью Скрам.
Скрам ( англ. scrum) — метод управления проектами. Относится к гибкой методологии разработки эджайл ( англ. agile — гибкий).
На этот раз он получил задачу по добавлению валидации в один из интернет-магазинов. До этого вся валидация была на стороне пользователя.
Валидация — проверка данных, которые вводит пользователь.
До пятницы ещё целая неделя, поэтому с митинга Ваня пошёл сразу в курилку. Достав сигарету, он стал слушать разговор мидла и сеньора:
— Недавно залез в репозиторий, а там одни foobar’ы. Целый час голову ломал, а потом махнул рукой и заново переписал.
— Как наберут новых джунов, так всегда говнокод появляется. Как он вообще код ревью проходит?
— Надо проверить в гитхабе историю коммитов.
Тут Ваня поперхнулся, затушил сигарету и заторопился на рабочее место — от греха подальше.
Репозиторий — хранилище исходных файлов проекта.
Foo и Bar — имена функций или переменных, по которым невозможно понять, зачем они нужны. Использование таких имён допускают в учебниках и документации, но не в реальных проектах, потому что они замедляют чтение и понимание кода другими программистами.
Говнокод — очень плохой код.
Код ревью — проверка кода.
Гитхаб — сервис для хранения репозиториев IT-проектов и совместной работы над ними.
Коммит — запись изменений в репозиторий. Коммит содержит в себе данные об изменениях, комментарий и имя автора коммита.
У стола его уже ждал тимлид:
— Ваня, после того как ты добавил функцию загрузки фотографии в личном кабинете, появился баг. Теперь всё ломается, если ввести промокод.
— Вы уверены, что это из-за меня? Мой код вообще промокодов не касался.
— Уверен. Откати сайт и исправь всё до конца недели — нельзя ждать, пока клиент заметит, что одна из фич пропала.
— Но у меня уже есть задача на эту неделю, я не успею всё исправить.
— Это далеко не первый твой факап, поэтому, если не успеешь, мы поставим новый рекорд — так быстро мы джунов ещё не увольняли.
Тимлид ( англ. team leader — лидер команды) в данном случае — программист, который выполняет роль менеджера. Тимлид редко пишет код, вместо этого он следит, чтобы его команда хорошо справлялась с задачами.
Баг ( англ. bug — жук) — неожиданный результат или неожиданное поведение программы, ошибка.
Откатить ( англ. rollback) — отменить изменения, вернуться к прошлой версии.
Фича ( англ. feature — особенность) — полезная (а иногда забавная) функция / особенность программы.
Исправление багов
Дебажить было сложно, но Ваня не мог облажаться и в этот раз. За год его уже успели уволить из трёх компаний, после четвёртого увольнения его резюме будет испорчено окончательно.
Дебаг (англ. debug — устранение багов) — исправление ошибок в коде программы.
Три дня и три ночи Ваня корпел над кодом, но ничего не выходило. В отчаянии он обратился к коллеге, который проводил код ревью для его коммита в прошлый раз.
— Прости, но если бы я знал, что не так в твоём коде, я бы твой пул реквест не заапрувил.
— Но ты же написал lgtm в комментарии!
— И теперь мне за это прилетело. Слушай, я уже сто раз пожалел, что помог тебе сюда устроиться. Тимлид просёк, что я сквозь пальцы смотрю на твой код, поэтому сейчас проблемы у нас обоих. В случае чего я найду новую работу, а ты — вряд ли. Так что сейчас у тебя отличный повод подтянуть знания.
— Ладно, разберусь как-нибудь.
Апрув ( англ. approve) — подтвердить что-нибудь.
Пул реквест ( англ. pull request) — запрос на подтверждение коммита.
LGTM ( англ. looks good to me — На мой взгляд, хорошо) — сокращение, которое часто встречается на гитхаб в комментариях к подтверждению коммитов. Обычно его используют, когда не получается сказать ничего конструктивного по поводу кода.
Осталось всего два дня, чтобы исправить баг и добавить новую фичу, а у Вани не было почти никаких продвижений. После работы он, как обычно, зашёл в магазин, но вместо энергетиков решил взять пиво, потому что вспомнил о Пике Балмера.
Пик Балмера — шуточная теория, что при содержании алкоголя в крови между 0,129 и 0,138% (примерно 2 бутылки пива) программист получает сверхспособности к написанию кода. Теорию выдвинул Стив Балмер, CEO Microsoft с 2000 по 2014 год.
Бессонные ночи и пиво сделали своё дело, поэтому Ваня заснул прямо за компьютером.
Наутро он не сразу понял, что проснулся, и, лёжа лицом на клавиатуре, продолжал слушать разрывающийся будильник. Прошло всего несколько минут, но Ване они показались вечностью.
Ненавидя себя, он поплёлся на работу. Сев за рабочий стол и посмотрев в код, внезапно понял, в чём была ошибка (известно, что многие проблемы в разработке приложений решаются, когда программист спит). Исправив всё за пару минут, он пошёл к тимлиду.
— Я разобрался с багом.
— Отлично, но странно, что у тебя ушло так много времени. Давай протестируем твой код и выгрузим на прод.
Прод или продакшн ( англ. production environment — рабочее окружение) — компьютер (чаще всего сервер), на котором запускается готовое к работе приложение.
Тестирование прошло успешно. И хотя Ване стало спокойнее, он не спешил радоваться — за полтора дня нужно было успеть выполнить задачу, на которую требовалась как минимум неделя.
К счастью, недавно он начал изучать JavaScript, поэтому мог просто скопировать код валидации с фронта и переделать его для бэкенда.
JavaScript — язык фронтенд-разработки.
Помучившись день, он всё-таки закончил. Тимлид оценил усилия:
— Ну вот, можешь же, когда захочешь. Тебе повезло, что мы не деплоим на прод по пятницам, поэтому у тебя ещё есть время до середины понедельника, чтобы ещё раз всё проверить и поправить.
Деплой ( англ. to deploy) — процесс перевода кода в рабочее приложение, чтобы запустить его на каком-нибудь компьютере.
Воодушевлённый успехом, Ваня ещё раз всё протестировал, поэтому к следующему митингу он был спокоен — больше исправлять старые баги ему не придётся.
По крайней мере на этот спринт.
Заключение
Научила ли чему-нибудь Ваню эта история? Возможно. Но вы наверняка стали на один шаг ближе к пониманию программистов. Или даже к тому, чтобы стать одним из них.
Фича что это такое простыми словами в бизнесе
Фича — это сленг, название тех или иных признаков предмета, либо явления. Другими словами, это его особенности, необычные свойства.
Слово пришло к нам от английского «feature» — особенность.
Что такое фича? Фича в IT это может быть необычное программное решение, возможности, особая функциональность, уникальные характеристики, которые привлекают внимание.
Чаще всего термин употребляется в сленге, но сегодня он уже перекочевал в обычную жизнь. Фичами называют необычные функции бытовой техники, уникальный дизайн, не стандартную функциональность. Часто слово фича в сфере, не связанной с IT заменяют на созвучную «фишка». От фичи образовалось словосочетание fetch request, хорошо известное программистам, а также появилось крылатое выражение-неологизм: «Это не баг, а фича».
Сегодня фичей называют любую характеристику продукта, которая имеет специфические особенности. Это могут быть механизмы, которые добавляют новую функциональность, элементы, превращающие продукт в уникальный. Это слово наиболее распространено в игровой индустрии, в сфере программного обеспечения, создания сайтов.
В роли фичи могут выступать различные фильтры, нестандартные слайдеры, уникальная визуализация, кардинально новое оформление интерфейса, необычная экипировка и поведение персонажей, схема диалогов, сюжетные ходы.
Фича — эффективный инструмент в позиционировании продукта, который играет важную роль в формировании уникального торгового предложения: она формирует механизм возвращения, потому что делает товар или услугу привлекательной для пользователей. Благодаря этому повышается монетизация проекта, формируется его положительный имидж, презентабельность в глазах целевой аудитории.
Баг или фича?
Баг происходит от английского «bug» и означает ошибку в программе или приложении. В результате бага вы получаете нежелательный результат. Крылатая фраза «это не баг, а фича» часто используется разработчиками для оправдания совершенных ошибок.
Как отличить баг от фичи? Если у вас что-то не работает или работает не корректно, то это точно баг. А если работает, но не совсем так как ожидалось, то возможно это фича 🙂 Понять это можно при тестировании продукта.
Настроить интеграцию без программистов ApiX-Drive
Статьи о маркетинге, автоматизации и интеграциях в нашем Блоге