что такое фич лист
Оцениваем проекты
Одной из основных моих активностей на работе является оценка проектов. И в данной статье я постараюсь поделиться своим опытом в данной области.
По данной теме написано очень много книг и статей, но зачастую все примеры из них описывают многомиллионные проекты расчитанные на несколько лет, и адаптировать их под нужды небольших проектов до 1000 часов довольно проблематично, для таких проектов необходима «экспертная» оценка — т.е. оценка человека, который знаком с технологиями и разрабатывал или рукводил разработкой подобных проектов. И так предположим, что Вы и есть тот самый человек, кому прийдется оценивать проект.
Дабы не ходить вокруг да около, лучше всего будет привести пример, поэтому возьмем абстрактный проект со следующими мутными требованиями:
«Хочу сайт, где пользователи смогут писать посты с картинками, оставлять комментарии, выставлять рейтинги, обмениваться сообщениями, а так же на сайте будет магазин с книгами, книги будет добавлять администратор сайта, он так же будет следить за порядком на сайте. Сайт должен иметь „лёгкий“ дизайн и соответствовать web 2.0»
Данный пункт требует определенных навыков, дабы расшифровать требования и ничего не упустить, и вот некоторые советы по составлению фиче-листа:
В итоге у меня получился фиче-лист с очень приблизительной оценкой, впрочем описание тоже не радует деталями. В действительности после выяснений всех деталей, может оказаться, что заказчик хотел всего лишь что-то наподобие WordPress MU, а магазин представлял бы всего-лишь — ссылки на Amazon с указанием реферала, хотя, с таким же успехом, заказчик может хотеть и социальную сеть, со всеми соответствующими атрибутами…
Если Вам интересна данная тема, могу посоветовать прочитать еще статейку о клоне YouTube.
Анализ функционала: как создавать фичи, которые будут полезны продукту, или что такое Feature/Product Fit
Что такое Feature/Product Fit?
Любая команда старается сделать свой продукт лучше. В большинстве компаний это происходит с помощью запуска новых фич в надежде, что они будут полезны. У компаний нет отлаженных процессов, которые помогали бы им понять, будет эта функция полезна конечному потребителю или нет. Этот процесс должен напоминать поиск соответствия продукта рынку (product/market fit). Но есть и различия.
В случае product/market fit есть три основных компонента, которые вам нужны:
Feature/product fit определяет, насколько ваша фича входит в общую концепцию продукта. Тут похожий процесс:
Это может быть слегка непонятно и сбивать с толку. Фича не только должна использоваться систематически и привлекать клиентов сама по себе, но она также должна улучшать UX продукта в целом. Это очень сложно, поэтому многие релизы проваливаются. Что происходит, когда фича работает на собственное возвращение и вовлечение, но не увеличивает эти же метрики всей компании? Это значит, что она каннибализирует на другой части продукта. Иногда это нормально. До тех пор, пока все эти три показателя не снижаются, запуск фичи может быть оправдан.
Самый популярный пример — это запуск стриминга от Netflix, который каннибализировал на рассылке DVD по почте, но в долгосрочной перспективе оказался стратегическим шагом.
В чём заключается работа команды?
Команда, работающая над конкретным функционалом, концентрируются на улучшении UX своей фичи, а не всего продукта в целом. Им хочется, чтобы все использовали эту фичу и сами иногда усложняют работу сервиса, отвлекая от основного продукта.
Если вы отвечаете за какую-то фичу, ваша работа заключается не в том, чтобы как можно больше людей использовали её. Ваша работа в том, чтобы как раз найти своё место в продукте, свой feature/product fit. Это можно сделать, проверяя метрики, о которых мы говорили выше (возвращение и активацию в фичу, а также возвращение, привлечение и монетизацию в основной сервис). В это время вы также должны определить, для кого подходит этот функционал как часть продукта (скорее всего, это не будут новые пользователи). Некоторые функции должны быть направлены на маленький процент пользователей. Тогда функционал становится инструментом, который может быть максимально использован командой для роста своей компании и увеличения общей доли возвращений в продукт, вовлечения и монетизации.
Какие ошибки совершают команды?
Ошибка №1. Рассылать анонс нового функционала по всей емейл-базе
Ваших пользователей интересует только выгода, которую они получают от использования вашего сервиса. Рассылая информацию об обновлениях в одной фиче, вы не доказываете ценность этой функции. Такие письма работают обычно хуже, чем письма об изменениях в основном продукте, зато легко могут повлиять на ценность емейл-канала, а это уменьшит возвращение в основной продукт.
Ошибка №2. Делать баннер на самом видном месте на сайте и рассказывать всем пользователям о вашей новой фиче
Обычно новые фичи нужны очень узкой аудитории и не так нужны всем остальным. Особенно они бесполезны для новых пользователей, которые пытаются освоить самые основы вашего продукта. Такие оповещения отвлекают их от основного функционала и снижают процент активации. Это приблизительно как предлагать участие в марафоне тем, кто только научился ползать.
Ошибка №3. Везде публиковать информацию о новом функционале
Пиар для конкретной фичи — это хорошо, но он не поможет найти feature/product fit. С другой стороны, пиар может пригодиться, когда вы убедитесь, что фича заняла правильное место в продукте и найдёте свою аудиторию. Если это не сделать заранее, пиар вас не спасёт.
Спасибо! Мы уже отправили всё на почту
Многие фичи не пройдут отбор
Многие фичи, над которыми работают продуктовые команды, не нашли своего места в продукте. Когда так происходит, фичи надо удалять. Бывает и так, что старые фичи перестают соответствовать. Если их нельзя актуализировать, их тоже надо удалить. Если вы не измеряли feature/product fit для старых функций, вернитесь и сделайте это. Удаляйте без сожалений, если понимаете, что это не работает. Вот пара примеров того, как Pinterest удаляет части своего функционала:
1. Кнопка like (удалено в 2016).
Люди не понимали разницу между кнопкой Like и Save и это приводило к путаннице.
2. Пины мест (удалено в 2015)
Pinterest пробовал создать особый тип пинов и специальные доски для пинов-мест. Во время экспериментов команда поняла, что это отдаляет их от основной концепции Pinterest.
3. Подпись пользователей/досок в сетке (удалено в 2016).
Указывать пользователей и их доски в самом пине стало бессмысленно после того, как Pinterest сделал пивот от социальной сети к сети по интересам. Это загромождало интерфейс и уменьшало количество выводимых пинов.
Как найти фиче место в продукте или Feature/Product Fit?
Запускайте все фичи в виде теста и смотрите, что выстрелит. Ваша цель — за время этого эксперимента показать новую фичу достаточно большому количеству людей, чтобы можно было сделать выводы. Маленьким компаниям можно тестировать прямо на всей базе клиентов. Для компании вроде Pinterest достаточно будет захватить около 1% аудитории. Обычно для таких экспериментов используют существующую базу, но можно привлекать и платный трафик.
Вот несколько тактик, которые помогли разным компаниям найти свой feature/product fit. Разработка хорошего функционала обычно начинается с анализа данных и исследования пользователей. В этом исследовании важно подгадать правильное время: исследование необходимо проводить так, чтобы у людей была достаточная вовлечённость, и можно было предотвратить предвзятость. Например, при запуске мобильного приложения Grubhub увидели, что оценки пользователей ниже, если они используют геолокацию, чем у тех, кто просто вводил свой адрес. Оказалось, что это проблема в точности определения местоположения, поэтому эту возможность отключили до тех пор, пока не исправили баг.
При анализе Grubhub заметили, что пользователи сомневаются, какой ресторан из поиска выбрать. В браузере можно открыть много вкладок и сравнить, но в приложении так сделать нельзя. Команда выбрала информацию, которая могла бы помочь пользователям принять решение, и начали добавлять ее в результаты поиска. Сейчас в выдаче отображается тип кухни, приблизительное время доставки, минимальный чек, рейтинг в звёздах, количество оценок. На первый взгляд страница стала более загромождённой, но это увеличивает конверсию и удержание.
Так как Grubhub — это агрегатор сервисов по доставке еды, необходимо было оценивать стимулы как стратегию поиска соответствия функционала продукту. Первоначальные данные показали, что у людей, которые начали использовать мобильное приложение, LTV был вдвое выше, чем у тех, кто заказывал через интернет. Поэтому Grubhub предложил скидку 10 долларов на первый заказ через мобильное приложение. Это помогло переключить пользователей из сети в мобильные. Стратегия оказалась очень успешной, и LTV увеличился, несмотря на дополнительное побуждение и скидки.
Также Grubhub использует собственных пользователей, чтобы найти feature/product fit. В то время мобильные приложения только входили в моду, поэтому команда Grubhub мониторил все жалобы в соцсетях и немедленно отвечали.
(не все жалобы такие эмоциональные)
В Pinterest запустили Related Pins (связанные пины) в 2013 и ввели уведомления. Когда вы запинили что-нибудь, вам будут приходить емейлы с предложениями связанных пинов, которые могут вам понравиться. Эти письма были очень успешны.
Pinterest также использует основной функционал продукта. Когда пользователи прокручивали пин, им показывались связанные пины. Но мало людей скроллит дальше самого пина, поэтому их поместили справа от основного, и это увеличило вовлечённость. Поэтому Pinterest начали вставлять связанные пины и в те, которые вы сохранили, что также увеличило вовлечённость.
The Feature/Product Fit чеклист
Отвечайте себе на эти вопросы, когда запускаете новый функционал, чтобы убедиться в успехе.
После подтверждения feature/product fit вы должны спросить себя:
Каждая компания хочет со временем улучшать свой продукт. Вам необходимо начать измерять, как на ваши планы влияют функции, которые вы внедряете. Не забывайте проверять, приносят ли ценности существующие фичи, а если нет, начните их убирать. Задавая себе эти вопросы, вы будете уверены, что вы на пути к созданию фич, которые соответствуют общей концепции вашего продукта и добавляют ценности и вашему бизнесу.
Елена Туровская
Тимлид команды продакт-маркетинга Carrot quest
Составление требований к разработке фичей: Курс «Создание программного продукта и управление его развитием»
Привет, Хабр! Продолжая серию публикаций по продуктовому менеджменту, сегодня мы обсуждаем требования к разработке. В этом посте речь пойдет о том, как продуктовый менеджер взаимодействует с разработчиками из R&D, зачем нужны требования, как правильно их сформулировать, и какие выводы из требований к разработке должны делать различные специалисты, включая самих разработчиков, менеджеров, QA и так далее. С другой стороны будущие и уже состоявшиеся разработчики узнают, что может (и вообще-то должен) предоставлять вам менеджер продукта. Все подробности — под катом.
Оглавление курса
Как читают Feature Description?
Каждая категория пользователей может почерпнуть из требований полезную информацию для себя. И поэтому очень важно иметь в виду, что требования будут читать разные люди:
При составлении документа нужно быть максимально краткими и не оставлять непонятных мест. Requirements в любом случае будут занимать несколько страниц. Его должны прочитать много человек, и нужно, чтобы он был читабельным.
Руководствуйтесь простым правилом: начинайте с главного и только потом добавляйте детали. Кроме этого нужно получить обратную связь от QA, Developers, DevOps и других заинтересованных лиц. Скорее всего, Feature Description обрастет новыми деталями после общения со стейкхолдерами.
Постарайтесь подумать над неочевидными сценариями. Желательно сразу определить, что должно делать ваше приложение в нештатных ситуациях. Подумайте, какие внешние компоненты влияют на вашу фичу. А когда все уже будет готово, еще раз задайтесь вопросом: “Что еще можно протестировать кроме шагов, описанных в пользовательских сценариях?”
Заключение
В следующем материале мы поговорим о бизнес-плане и ценообразовании для нового продукта.
А пока делитесь в комментариях вашим опытом работы с требованиями, как со стороны менеджера, так и исполнителя. Расскажите, был ли в вашей практике пример, когда функциональный заказчик хотел одного, а в итоге получилось совсем другое из-за непонимания?
Лекция про дорожную карту и требования для разработки:
Разговариваете со своими разработчиками на разном языке? Сроки все время едут? Качество продукта оставляет желать лучшего? Пишите в личку, обсудим что с этим можно сделать.
Как правильно нарезать Фичи для Инкрементов Программы SAFe®
Как подготовить Фичи к планированию Инкремента Программы?
Перевод статьи Ian Spence и Keith de Mendonca Right-sizing Features for SAFe® Program Increments выполнен с разрешения авторов.
Одной из ключевых активностей, необходимой для успеха вашей реализации SAFe®, является аккуратная подготовка Фич (Features) перед планированием Инкремента Программы (PI). И существенной частью этой подготовки является нарезка тех целевых Фич, реализация которых требует более чем одного PI.
В этой статье мы хотим поделиться нашим опытом нарезки Фич. А также, вслед за Ричардом Лоуренсом с его популярным постером о Нарезке Историй, дать вам бесплатный постер с правилами Нарезки Фич, который вы сможете использовать в своей SAFe программе. Вот такие мы добрые.
Фичи — это ведь просто большие истории, разве не так?
Для Владельцев Продуктов (Product Owners) и Менеджеров Продуктов (Product Managers) очень соблазнительно рассматривать Фичи как гигантские Пользовательские Истории (User Stories) и работать с ними в бэклоге программы, используя те же подходы, что и для Пользовательских Историй в бэклогах команд.
Но мы обнаружили, что описание Фичи в формате Историй может приводить к проблемам (подробности вы найдете в статье Features and Capabilities на сайте Scaled Agile Framework), и также не стоит применять к Фичам те же правила нарезки, что и к Пользовательским Историям.
В Scaled Agile Framework Фичи и Истории (включая как Пользовательские Истории, так и Enabler-истории) четко различаются с точки зрения целей, структуры и содержания:
Существует целый ряд источников, описывающих правила нарезки Историй, наши самые любимые из них — опубликованные Ричардом Лоуренсом (включая его знаменитый постер о Нарезке Историй) и Дином Леффингвеллом (детали вы можете найти в статье Story на сайте Scaled Agile Framework). Эти правила актуальны и при использовании Фич: они реально помогают командам выявлять, разделять и упорядочивать Истории, которые требуются для разработки Фичи. Но эти правила перестают быть такими действенными в нарезке Фич.
Например, мы никогда не будем рекомендовать выносить требования по производительности в отдельную Фичу, которая будет сделана позже, даже несмотря на то, что реализация этих “Историй производительности” будет производиться в конце разработки Фичи. Это также касается обработки ошибок, CRUD и изменениям данных — мы можем отложить разработку Историй, связанных с этими важными атрибутами программного обеспечения, и сделать их ближе к концу разработки Фичи, но мы не будем группировать их в отдельную Фичу.
В ходе нарезки Фич важно помнить, что это реальные элементы релиза системы, которые должны предоставлять пользователям надежное и готовое к использованию решение. Да, Фичи создаются путем последовательной реализаций Историей, но сами по себе они должны описывать готовое к использованию решение. Заметьте, что готовность решения к использованию подразумевает отсутствие недоделок, а вовсе не реализацию всех возможных Историй.
Есть еще одно важное отличие в декомпозиции Историй и Нарезке Фич. Когда мы декомпозируем Историю, мы обычно делим ее на несколько примерно одинаковых по размеру новых Историй, которые в совокупности полностью заменяют оригинальную Историю. При нарезке Фич мы обычно просто находим наиболее важную часть и оставляем остальное на потом.
Нарезка фич
Итак, давайте представим, что команда только что оценила Фичу (обычно в Story Points) и обнаружила, что она слишком большая и не может быть поставлена целиком в следующем Инкременте Программы. Далее, чтобы разделить Фичу на части, им нужно выбрать такой способ нарезки, который позволит снизить приоритет или отложить разработку части функционала на потом. После они выберут только те кусочки бизнес-ценности, которые максимально быстро принесут выгоду клиенту.
Какие стратегии нарезки вы можете использовать? Мы выбрали 10 наиболее полезных моделей для нарезки:
Примеры плохой нарезки
Мы выявили несколько опасных ловушек, которые могут подстерегать вас в ходе нарезки:
Конечно, бывают ситуации, когда ограниченный релиз Фичи все же может быть проведен, с целью получения обратной связи, но в этом случае число нефункциональных требований, которым надо соответствовать, снижается исключительно за счет того, что такой релиз затрагивает очень небольшую группу пользователей. Необходимо очень внимательно следить за тем, чтобы ни у кого не сложилось впечатления, что такая Фича может быть открыта всем пользователям без дополнительной работы и добавления новых Фич.
Постер о нарезке фич
Как функциональная спецификация поможет сделать более точную оценку проекта?
Функциональная спецификация: описать механику и технологии для каждой функции продукта
Коротко: как в Skipp описывают задачу разработчикам
У традиционного ТЗ, даже если это документ на сто страниц по ГОСТу, много проблем. На рынке все пишут ТЗ по-своему, заказчику в принципе сложно написать полное ТЗ самому, а разработчикам сложно однозначно оценить его.
Когда клиент обращается в Skipp, мы не пишем ему ТЗ, а вместе проходим три этапа предпроектной подготовки. Ими можно заниматься параллельно, но общий логический порядок устроен так:
Концептуальное проектирование, которое клиенту поможет сделать продакт-менеджер. Они вместе разберутся, какой нужен продукт, и создадут USM.
Визуальное проектирование, которое поможет сделать UX-дизайнер. Он продумает интерфейсы, набросает базовый дизайн и создаст прототипы разной степени детализации.
Функциональная спецификация, которой займётся руководитель проекта — продакт, проджект или скрам мастер. Он создаст фич-лист: опишет механику и технологии функций, которые придумали в USM, даст ссылку на прототип или приложит скриншоты.
USM, прототип и фич-лист мы отправим на оценку нескольким командам разработки. По опыту мы знаем: с таким ТЗ клиент получает более однородные и точные оценки от команд, а разработчикам проще провести декомпозицию и собрать бэклог.
Третий и заключительный этап описания задачи в Skipp — это функциональная спецификация.
Здесь мы подробно объясняем механику каждой функции и описываем требования к используемым технологиям.
Функцию описываем так: берём User Story, из которой она родилась, объясняем условия её возникновения или действия, которые совершает пользователь, затем описываем результат функции и прикладываем скриншоты дизайна.
Чтобы быстро создать функциональную спецификацию, важно заранее провести два предыдущих этапа предпроектной подготовки: концептуальный и визуальный. Тогда у вас всегда будет ответ на вопрос «зачем нужна эта функция?» и «как эта функция выглядит?». Функциональная спецификация будет логичным продолжением предыдущих этапов и её подготовка не займёт много времени.
Спецификация, как и другие этапы, помогает сделать более точную оценку стоимости проекта. В спецификации могут вскрыться технические тонкости, которые превратят разработку в нестандартную или просто будут незнакомы разработчикам. Если они увидят что-то новое для себя, то зададут уточняющие вопросы, заложат больше времени.
В Skipp функциональная спецификация состоит из двух элементов. Первый — фич-лист, формат которого мы адаптировали из статьи на Хабре. Это таблица из функций или фич, которые будут в ИТ-проекте. Каждую описывают по шаблону: User Story / Условия возникновения и действия пользователя / Результат / Дизайн. По такому фич-листу легко провести декомпозицию: превратить его в список задач и собрать бэклог.
Второй элемент — описание архитектуры продукта. В некоторых проектах в Skipp используют микросервисную архитектуру. Это значит, что система не монолитная, а состоит из самостоятельных частей — сервисов. Так продукт легче менять и масштабировать. Если потребуется, например, доработать сервис авторизации, разработчик сможет заниматься им, не затрагивая работу других сервисов.
Чтобы показать, какие микросервисы нужны в продукте и как они будут взаимодействовать друг с другом, рисуют схему — описание архитектуры продукта. В простых или типовых проектах схемой архитектуры можно пренебречь.
В Skipp на этом этапе также могут подготовить дорожную карту разработки для заказчика. Это календарный план работы, где наглядно показывают, сколько продлятся верхнеуровые задачи и какие технологии будут использовать в проекте.
Почему важно сделать
Функциональная спецификация обуславливает выбор технологий. Это удобно для работы: разработчикам не придётся додумывать, предпроектная оценка будет более точной, процесс подбора команды ускорится.
Функциональная спецификация помогает согласовать все ключевые моменты разработки до старта. Значит, получится точнее создать смету, будет меньше проблем и ошибок, меньше времени уйдёт на тестирование и доработки. Ещё будет намного проще составлять сопутствующую документацию по проекту. Например, инструкции и руководства для пользователей и документы для испытаний. Александр Лаптев Руководитель команды системных аналитиков, которая работает со Skipp
Что будет, если не сделать
Если не подготовить функциональную спецификацию, разработчики соберут функции, как захотят. Каждая команда будет трактовать задачу по-своему, использовать привычные решения, шаблоны и технологии. Иногда это плохо для проекта: приводит к некорректной оценке, усложняет работу и интеграции с другими системами, снижает гибкость и масштабируемость продукта, накладывает другие технические ограничения.
Если заранее не продумать архитектуру в сложном ИТ-продукте, будет трудно вводить новые сущности, характеристики объектов или пользователей, настраивать взаимодействие между разными компонентами системы. В базах данных могут сделать разную логику. Всё это усложнит работу для команд, которые будут развивать проект.
Кто делает в Skipp
Руководитель проекта, который будет общаться с разработчиками: продакт-менеджер, проджект-менеджер или скрам-мастер.
Если в проекте сложная архитектура, функциональную спецификацию делает системный архитектор или системный аналитик.
Вовлечённость заказчика
Минимальная: функциональную спецификацию для разработчиков готовят руководители проекта, архитектуру — аналитики. Заказчику будет важно изучить только дорожную карту.
Артефакт этапа в Skipp
Фич-лист, описание архитектуры продукта, дорожная карта разработки.