Как и кем реализуются фичи в нетворках

6 июня 2019
122
2
На чтение: 5 мин

Как и кем реализуются фичи в нетворках


Всем привет!

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

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


Как и кем реализуются фичи в нетворках

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

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

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


Как и кем реализуются фичи в нетворках

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

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

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


Как и кем реализуются фичи в нетворках

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

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

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

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


Как и кем реализуются фичи в нетворках

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

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

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


Как и кем реализуются фичи в нетворках

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

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


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

Есть что рассказать об арбитраже трафика?
Стань автором ZorbasMedia!
Оставить заявку