День 18 ноября 2014 года стал датой публичного релиза редактора Optimizely’s для iOS. Это было весьма значимым событием, так как релиз ознаменовал собой окончание многомесячного публичного бета-тестирования, на протяжении которого сотрудники компании получили массу пользовательских отзывов, в соответствии с которыми занимались внедрением множества недостающих функций (о том, как зарабатывать на продукте или сервисе до его запуска — здесь). Но до момента запуска приложения оставалась одна проблема, в процессе решения которой сплотилась вся команда: они не чувствовали гордости за свой продукт. Для исправления этой проблемы ребята и вышли за рамки концепции MVP (англ.: «Minimum Viable Product» — «Минимально жизнеспособный продукт»), расширив её до MVPP: «минимально жизнеспособный продукт, которым мы гордимся» (англ.: «Minimum Viable Product we’re Proud of»). Ниже — история о том, как все это было, чему сотрудники из Optimizely научились по ходу работы, а также — советы по разработке, которые должны помочь читателям создавать классные продукты. Советы с точки зрения тех, кто только что прошёл этот путь.
Как возникла концепция MVPP
Первая публичная бета-версия редактора Optimizely’s iOS была выпущена в июне 2014 года. К тому времени продукт не был завершён. Но для компании важным фактором дальнейшего развития и поиска багов была обратная связь от реальных клиентов. И после нескольких месяцев работы, усиленной пользовательскими отзывами, бета-версия продукта показалась достаточно подготовленной для публичного релиза. Оставалась лишь одна проблема: команда не испытывала ощущения гордости за свой продукт. Он не соответствовал их планке качества. Возникало чувство, что перед людьми — набор функций, прикрученных друг к другу без единого, целостного образа. Для решения этой проблемы было решено тщательно изучить пользовательский опыт — весьма сомнительная цель, которая запросто могла растянуть сроки работы вплоть до бесконечности, но так и не достичь заветной стадии разработки под названием «Готово!».
Перед началом тщательного анализа, дабы направить его в нужное русло, были четко обозначены две основополагающие вещи:
- во-первых, определен дедлайн, который не позволит впасть в цикл бесконечной полировки пользовательского интерфейса;
- во-вторых, источником вдохновения стала методология Lean Startup (англ.: «Скромный стартап») и было принято решение позаботиться лишь о таком наборе функций, который составит тот самый MVP – «минимально жизнеспособный продукт».
- Концепция MVP подразумевает ограничение масштабности проекта. Сознательное ограничение, позволяющее успеть к дедлайну. Но MVP ничего не говорит о качестве. Итак, чтобы уяснить для себя, что отныне во главе угла — качество и желание гордиться финальной версией продукта, к аббревиатуре MVP добавили ещё одну букву «P» — «Proud» («гордость»). Так родилась концепция MVPP – «минимально жизнеспособный продукт, которым мы гордимся».
Создание целостного образа
Согласовав подборку функций для релиза MVPP, автор этой статьи и его коллега — дизайнер продукта, замуровались на самую лучшую (хоть и короткую!) часть недели в комнате для обсуждений, чтобы систематизировать пользовательские отзывы. Мы классифицировали и упорядочили пользовательские сценарии, построив грубую модель дальнейших действий. Эта модель предназначалась для дальнейшего обсуждения видения проекта с расширенным составом команды. К счастью, под рукой уже были некоторые предварительно собранные результаты исследований юзабилити.
Эти макеты оказались чрезвычайно полезными при планировании работы по дизайну и функционалу. Вместо абстрактных разговоров об идеях перед разработчиками оказались конкретные функции и цельный образ. К примеру, каждый понимал, что имеется в виду под фразой «Улучшенная адаптация сценариев». Имея на руках эскизы, членам команды стало гораздо проще общаться между собой, их работа обрела конкретные очертания, а ребята получили заряд вдохновения для упорной работы по достижению цельного образа продукта, над которым работали.
Шесть недель календаря… и вперёд!
Для завершения работы над MVPP нам понадобилось три «спринта». Под «спринтом» в фирме Optimizely большинство команд подразумевают двухнедельный цикл работы. Сроки были заданы жёстко, но цель выглядела вполне достижимой — в точности к тому времени, которое и было запланировано — как и должно быть в случае хорошо продуманного дедлайна.
В первый «спринт» команда добилась потрясающих результатов. Были собраны все основные шестерёнки механизма, притом – без серьёзных изменений или перепроектирований. Оставались ещё и ошибки, виднелись и задачи по «допиливанию», и шероховатости для обсуждений. Но, в общем, цельное ядро продукта было собрано.
Импульс первого «спринта» перенёсся и на второй, во время которого исправляли наиболее значительные баги, заполняли пробелы функциональности и доводили до ума пользовательский интерфейс.
Третий, заключительный, «спринт» прошёл с новым лозунгом: «Запуск на неделю раньше». Хотя ребята уже сконцентрировались на идее MVPP, теперь работа шла ещё более прицельно-снайперская. Каждый день во время «летучек» они смотрели на схему на доске и спрашивали себя: «Над чем бы шла работа сегодня, если запуск намечался бы уже на завтрашний день?»
При расстановке приоритетов не щадили те задачи, которые оставались важными, но не были действительно необходимыми для запуска.
В первую неделю заключительного «спринта» во время каждого совещания ребята также пробегались по всем закоулкам продукта, чтобы лишний раз подумать: гордятся ли они новым редактором для iOS. При этом они рассматривали продукт с точки зрения пользовательского опыта, отлавливая баги, способные снизить качество работы. В это же время было найдено и исправлено множество ошибок функционала. К концу недели в Optimizely испытывали гордость за получившийся результат и были уверены в его релизе.
Про адреналиновый выброс и «плюсы» раннего релиза
10 ноября — на неделю раньше запланированного срока! – команда Optimizely тихо и скромно выпустила в мир свой продукт, сработаннный по концепции MVPP. Ранний запуск хорош не только сам по себе; он позволил ещё и набрать полную грудь кислорода для дальнейшего «допиливания» дизайна и охоты на баги. Также ускоренный релиз дал компании время для реорганизации всех компонентов с целью подготовки сопутствующих MVPP продуктов.
Команды, работающие над отдельным продуктом, не выпускают своё творение в одиночку; этот процесс требует полноценного сотрудничества между отделами продаж и маркетинга. Чтобы клиенты Optimizely могли пользоваться продуктом, коллеги из разных подразделений также должны подготовить материалы для продвижения и продаж.
К 18 ноября, моменту публичного анонса окончательной версии продукта, им искренне гордилась уже вся компания.
Уроки, которые были выучены в процессе
При написании этой статьи и описании проекта в целом, ребятам из Optimizely стали ясны некоторые приёмы, которые пригодятся в любой команде, настроенной на высокое качество и своевременный запуск своих продуктов (а том, что советует Оливер Эмбертон, чтобы воплощать мечты и достигать целей, можно прочесть здесь):
Добавьте букву «P» к «MV»: P, Proud, Гордость. При таком подходе качество станет обязательным предрелизным требованием. Проект, разработанный под девизом «минимально жизнеспособный продукт, которым мы гордимся» гарантирует, что каждый член команды будет работать над продуктом, держа в уме его качество. Каждый проект — компромисс между сроками релиза, качеством и масштабностью. Сложно, очень сложно одновременно работать над всеми тремя показателями. Будем честны: одновременно реалистичны лишь два из них. Назвав свой проект «MVPP», в Optimizely уяснили для себя: качество страдать не должно.
Назначить дедлайн. Дедлайн, нависающий над каждым членом команды, сосредотачивает усилия и направляет их в нужное русло. Он не даст дизайнерам уйти в бесконечное выпиливание интерфейсов, не позволит разработчикам вновь и вновь итерировать каждый редчайший случай того или иного применения функционала. Дедлайн должен быть жёстким, но и обязательно реальным, внушающим команде чувство срочности, безотлагательности.
Сфокусируйтесь над наименее возможным набором функций, способным обеспечить максимальную пользу клиентам. В компании точно уяснили себе, какие именно функции следует переделать (прочитайте о том, насколько это полезно для конверсии и формирования лояльности). И, не менее точно, какие функции можно переделать вовремя. Этот подход не позволил масштабу проекта расползтись до невыполнимых размеров и смог заставить команду сосредоточиться над выполнением нужных задач.
Макет начинается до разработки. В нашей отрасли это азбучная истина, но её стоит повторять вновь и вновь. Создайте реалистичные пользовательские сценарии, заранее наметьте на макетах точки обсуждений. Такой подход позволит избежать неопределённости и быстро объяснит всем членам команды целостный образ продукта. Также он сплотит команду для выполнения конкретной задачи.
Ежедневно пробегайтесь по продукту. В случае Optimizely анализ продукта обеспечил два ключевых достоинства. Во-первых, было выявлено несколько багов в дизайне и в коде. И, во-вторых, постоянный анализ не давал забыть о дополнительной букве «P» в «MVPP». Каждый член команды соглашался, что гордится результатом и уверен в его запуске. Пусть разборы полётов и делали наши «летучки» на полчаса длиннее, но оно того стоило.
Спрашивайте себя: «А чем бы мы занимались сегодня, будь релиз назначен на завтра?». Чем ближе дата релиза, тем лучше этот вопрос отсекает обязательные перед запуском задачи от тех, которыми лучше заняться уже после релиза.
«Намылить. Смыть. Повторить»
Расширив границы MVP до «минимально жизнеспособного продукта, которым мы гордимся», в Optimizely гарантировали качество как одно из требований перед запуском. А, пользуясь инструментом под названием «дедлайн», они сосредоточили усилия исключительно на критически важных для релиза задачах. Благодаря грамотно проработанному видению проекта, моделям и макетам, а ещё — не столь отдалённой дате релиза, можно сплотить команду для создания такого продукта, которым гордились бы все принявшие участие в его создании.
А затем повторить это ещё раз.
Автор: youngbabik
