Startup manager Станислав Жуковский рассказывает о том, что такое минимально жизнеспособный продукт и концепция ленивого пользователя, а также объясняет, как правильно применять эти понятия на практике.
В своей я рассматривал этапы подготовки и заказа мобильного приложения, а также предлагал возможные варианты взаимоотношений между заказчиком и исполнителем.
Но мы не рассмотрели такой важный и актуальный для обеих сторон вопрос, как MVP.
MVP: что, зачем и как
Аббревиатура MVP расшифровывается как minimum viable product - минимально жизнеспособный продукт. В теории данная концепция приносит свою положительную выгоду тем, кто пытается ее внедрить в жизнь. Не всегда это получается удачно (особенно в России), но об этом чуть позднее.
Поговорим об идеальной модели MVP, как ее видят некоторые эксперты из российского интернет-сообщества: предположим, вы хотите делать и продавать автомобили. Минимальной жизнеспособной моделью, с точки зрения некоторых экспертов, будет являться велосипед, ну, или скажем, скейтборд. Мол, так вы проверите спрос пользователей на колесный транспорт, убедитесь в том, что он есть, сделаете опрос пользователей и поймете, в каком направлении вам дотачивать следующий релиз: делать трехколесный велосипед, мопед или скутер.
Но что вы получите? Сэкономите время на разработку? Может быть. Сэкономите деньги на разработку? Может быть. Даже нервы тоже, казалось бы, сэкономите. Но это далеко не факт.
Но что вы потеряете? Если так примитивно трактовать модель минимально жизнеспособного продукта, то вы потеряете все: и время, и деньги, и нервы.
Давайте рассмотрим конкретный, не метафоричный пример: фирма «А» решила создать сервис по доставке продуктов из сетевых магазинов города. Сервис кросс-платформенный: есть веб-версия, приложения для iOS, Android и даже Windows, а также админ-панель для обработки заказов, сервер и база данных. Но это все в планах. Ребята начитались статей про MVP и решили, что минимально жизнеспособный продукт надо делать только в веб-версии. Правильное решение, на первый взгляд. Таким образом, они серьезно и действительно сэкономили средства и время на разработку приложений, значительно облегчили разработку бэкэнда.
Но дальше… Дальше они также скупо и прагматично подошли к минимальному функционалу своей веб-версии и админ-панели для обработки заказов. После первой же демонстрации в одной из городских сетей их проект зарубили, как не представляющий интереса для сети, так как они предлагают доставлять слишком короткий список продуктов и функционал админки слишком беден. Короткий список был продиктован их беглым анализом по покупательскому спросу на доставку и возможности курьеров. А функционал админки был сделан сугубо по пунктам MVP.
Да, у них еще есть шанс все переработать и снова прийти на презентацию, но оправдываться всегда намного тяжелее, чем сразу произвести нормальное впечатление. Вот по какой причине модель MVP в вакууме смотрится хорошо, а когда доходит до дела, то нужно включать ум. И включать его в нужном направлении.
А какое направление будет нужным? Естественно, пользователь.
При этом концепция MVP говорит о том, что вектор развития продукта будет зависеть от пользовательского спроса на тот или иной функционал. Но модель не объясняет, как и о чем спрашивать пользователя, и что самое ужасное, она не говорит, как сделать продукт таким, чтобы было о чем спрашивать.
Поэтому множество разработчиков на свой «экспертный» взгляд предлагают заказчику во время разработки урезать функционал лайка, чата, возможности оплатить через смс и прочего, так как это скорее «дополнения» к основному функционалу. Но на основании чего они делают такие предложения? На основании чего, какой-то функционал признается основным, а какой-то дополнительным? Разве пользователя уже кто-то о чем-то успел спросить? Нет. Есть предположения, анализ, чужие платформы и чужой опыт. Ну, так на то он и чужой и, скорее всего, менее успешный, раз вы решили развивать свой сервис в противовес конкурентам.
Что такое LUC и с чем его едят
Поговорим о Lazy User Concept или концепции ленивого пользователя. Ее суть сводится ко взгляду на любую бизнес-модель со стороны ленивого пользователя.
Кадр из мультфильма WALL-E
Основные положения LUC:
Пользователь всегда стремится к состоянию комфортного покоя (ничего не делать, ничего не платить, получать удовольствие). То есть его раздражает все, что его хоть как-то беспокоит, даже если эти изменения будут положительными.
Пользователь готов сделать изменения только в том случае, если они в ближайшем будущем принесут ему еще большее состояние комфортного покоя.
Пользователь готов заплатить за изменения только в том случае, если планируемый профит значительно улучшит его положение.
Пользователя нельзя просто спрашивать, ему надо предлагать и анализировать реакцию на предложенное.
По стандартной пользовательской статистике вы можете исследовать и внедрять любой пользовательский функционал, которым хотите насытить свой сервис: как только более 2% пользователей тыкнут в соответствующую кнопку pre-function - вы тут же бросаетесь реализовывать данный функционал в полном объеме. Не тыкают - ваше счастье: вы ведь все сделали по правилам - деньги сэкономили, время сэкономили и даже пользователя спросили.
Кроме pre-function, есть еще несколько немаловажных моментов, вытекающих из принципов поведения ленивого пользователя:
При разработке и визуализации вам нужно по всем правилам UI/UX эти цели поставить настолько близко к носу пользователя, чтобы он не смог пройти мимо них;
Гиперважный момент: при разработке пункта №2 необходимо убрать все лишнее, что может отвлечь пользователя от поставленной вами пользовательской цели. Про это забывают почти все. Запомните: пользователя нельзя отвлекать.
Итак, рассмотрим на конкретном примере, как это работает. Вы - заказчик, пришли к разработчику. Делаете заказ на навигационное приложение, которое показывает, где находятся ваши друзья и знакомые, у которых также установлено это приложение. В прототип приложения вы уже «напихали» чат, обмен фотографиями и другими файлами, кнопку «заказать такси» и кучу всякой всячины, которую разработчик в первом релизе в рамках модели MVP предлагает вам не делать. А сделать сначала «сухую» карту и точки на ней. Максимум с именами, чтобы пользователи видели, кто есть поблизости и как его зовут. Прибавляем к модели MVP еще Lazy User Concept и задаем себе вопросы:
Какую цель я ставлю для себя в первом релизе?
Что я должен сделать для пользователя?
Что пользователь должен сделать для меня?
Цель в первом релизе может быть действительно такой, как видит ее разработчик: сделать карту и показать на ней друзей. Но что уникального вы хотите дать своим пользователям дальше? Какую фишку вы добавите, которая будет вас отличать от прочих, уже накачанных богатым функционалом приложений? Что вы сделаете для пользователя?
Надеюсь, мои объяснения с примерами помогут вам разобраться в том, как делать первый релиз и в каком направлении его развивать. MVP + Lazy User Concept шикарный инструментарий для создания и выпуска в жизнь любых цифровых продуктов, потому что позволяют вам не только делать предположения, но и проводить анализ поведения целевой аудитории в реальном времени.
В разработке продукта минимальный жизнеспособный продукт (MVP ) - продукт, который имеет только достаточные возможности, чтобы собрать проверенную информацию и его дальнейшем развитии. Сбор такой информации об MVP часто дешевле, чем при использовании продукта с более широкими возможностям, которые увеличивают затраты и риск провала проекта, например из-аз неправильных предположений. Этот термин может включать в себя проведение анализа рынка заранее.
Минимально жизнеспособный продукт имеет только те основные функции, которые позволяют продукту быть развёрнутым и не более того. Продукт обычно запускается для подмножества возможных клиентов, например на первопроходцах (early adopters), которые, как считается, более либеральны и более вероятно готовы дать обратную связь, а так же в состоянии понять концепцию продукта с раннего прототипа или маркетинговой информации. Эта стратегия направлена на предотвращение создания продуктов, которые не нужны клиентам, то есть на максимизацию количества информации, полученной от клиента за израсходованную денежную единицу.
Минимальный жизнеспособный продукт - такая версия нового продукта, которая позволяет команде получить максимальное количество информации от потребителя при минимальных усилиях.
Использование слов максимум и минимум означает, что это точно не шаблонное. Необходим анализ для каждого отдельного случая, чтобы понять имеет ли MVP в данной случае смысл.
MVP может быть частью стратегии и процесса, направленного в сторону создания и продажи продукта клиентам. Это является основным артефактом в итерационном процессе генерации идей, прототипирования, презентации, сбора данных, анализе и обучения. Необходимо стремится минимизировать общее время, затраченное на итерации. Процесс повторяется до тех пор, пока не получается желаемое соответствие продукта и рынка, или пока продукт не считается нежизнеспособным.
Если обобщить, то минимальный жизнеспособный продукт имеет минимальный набор функций.
Зачем так делать?
- Возможность проверить гипотезу о продукте с минимальными ресурсами
- Ускорение обучения
- Сокращение траты времени разработчиков
- Создание продукта для ранних потребителей как можно скорее
- Основа для других продуктов
- Оценить возможность создания требуемого продукта
Тестирование
Результаты тестирования минимального жизнеспособного продукта нацелены на определение потребности в создании. Тестирование оценивает насколько первоначальная проблема или цель решаются способом, который является разумным для дальнейшего развития.
Вы продаёте видение и представляете минимальный набор функций визитерам, а не для всех.
Стив Бланк
Техники
Минимальный жизнеспособный продукт может быть прототипом, целым продуктом или подмножеством продукта (например, особенности).
Для продуктов
Каноническая стратегия MVP для веб-приложения состоит в том, чтобы создать простой сайт для продукта и закупить интернет-рекламу с прямым траффиком на сайт. Сайт может быть просто посадочной страницей со ссылкой на получения дополнительной информации или для покупки. Ссылка по факту не оформляет заказ, вместо этого снимаются клики для измерения покупательского интереса.
Для сервисов
Обычно используется для услуг, где есть гипотеза взимать плату с клиента для ручного выполнения услуги сервиса без какой-нибудь разработки продукта. Например, сервис онлайн радио проигрывает музыку, исходя из индивидуальных предпочтений. Можно было бы протестировать ценообразование на клиенте, находясь физически рядом с ним и вручную создать плейлист, исходя из предварительного выбора клиентом музыки и явных эмоциональных ли физических реакций на музыкальные композиции. Можно проверить готовность платить за эту услугу консьержа. Готовность платить за такую личную службы будет служить основанием, чтобы упомянутый клиент готов заплатить за менее личный музыкальный онлайн-сервис.
Для функций
Ссылка на новую функцию в веб приложении может находиться на видимом мест на уже существующем вебсайте. Функция не обязательно должна быть полностью внедрена, однако, должно быть что-то вроде посадочной страницы. Клики по ссылке анализируются и являются индикатором заинтересованности клиентской базы в этой новой функции. Так же это можно назвать методом сперва деплой, а код пишем потом.
Различие
Создание и оценка воздействия минимального жизнеспособного продукта являются стратегией тестирования рынка,которая используется, чтобы показать идею продукта вскоре после её появления. Это облегчается благодаря быстрым инструментам разработки приложения.
MVP отличается от обычной стратегии тестирования рынка на инвестирование времени и денег. MVP предназначен, чтобы гарантировать, что рынок хочет продукт перед тем, как будут сделаны большие временные и денежные инвестиции. MVP отличается от методологии выпускай раньше, выпускай чаще, которая слушает пользователей, позволяя им определить особенности и будущее продукта. MVP начинается с видения продукта, которые сохраняется на весь жизненный цикл продукта, хотя это основывается на явной и неявной (косвенной) обратной связи от потенциальных будущих покупателей продукта.
MVP — стратегия, которая может быть использована в качестве части потребительской методологии развития Бланка, которая сосредотачивается на непрерывном повторное продукта и обработке, основанной на обратной связи с потребителями. Кроме того, презентацию несуществующих продуктов и функций можно усовершенствовать, используя метод статистического тестирования гипотезы, например в виде A/B тестирования.
Что такое MVP? Аббревиатура, которую от стартаперов подхватили клерки, продолжает свой путь в инфосреде. Увы, первоначальный смысл заколочен в гробу интерпретаций от тех, кто услышал звон. А знать надо - понимание основ MVP жизненно необходимо в IT-бизнесе.
MVP - сокращение от minimum viable product. На русский переводится как минимально жизнеспособная версия продукта. В этой фразе каждое слово наполнено смыслом, и смысл этот однозначен. Начну с конца.
Продукт
Смотрите на картинку, это прототип айфона:
А это первая жизнеспособная версия айфона:
Можно долго цитировать Джобса про буквальное вылизывание иконок на рабочем столе, но в первом айфоне не было огромного количества фич, которые на тот момент были у большинства конкурентов. Первая партия была выпущена ограниченным тиражом. Первая партия была привязана к одному оператору.
Это был функционально обрезанный и глючный продукт. Отличие продукта от прототипа - его можно продавать. Продукт внедряется в рынок, а прототип - это одна из итераций на пути к этой цели.
Версия
Слово «версия» говорит об итеративном подходе. Попытки достичь MVP без промежуточных шагов похожи на красное лицо худощавого подростка, который первый раз пришёл в спортзал и сразу хватается за 200-килограммовую штангу.
MVP - это точка на временной оси, когда прототип превращается в продукт, которой предшествуют другие точки.
Жизнеспособная
MVP - это та итерация, когда продукт удовлетворяет хотелку клиента. «Жизнеспособность» следует читать в контексте выживаемости внутри рынка. Угадали с болью и подтвердили ценностное предложение, но боль уже давно решается на рынке крупным игроком на недостижимо качественном уровне? До свиданья, продукт нежизнеспособен. Именно поэтому выживаемость - штука относительная.
Минимально
А вот и главное, важнейшее - MVP находится в точке равновесия между хотелкой клиента, и затраченными усилиями команды.
Теперь откровение - недолёт лучше, чем перелёт. Если продукт, который вы выкатили на рынок, не найдёт пути к сердцу клиента, вы всегда можете его допилить. А вот ресурсы нужно экономить, потому что их мало.
А теперь определение
Каноническое определение дал Френк Робинсон, СЕО SyncDev Inc. Я переведу его на русский:
MVP - это версия продукта с максимальным отношением коэффициента возврата инвестиций к рискам. Это место между версией продукта, которая провалится на рынке из-за отсутствия требуемых функций, и версией продукта, которая содержит слишком много функций, что уменьшает коэффициент возврата инвестиций и повышает риски.
Главный риск, самый актуальный для стартапов - фейл в Customer Development’е и, как следствие, людям нафиг не нужно то, что вы делаете.
Что не является MVP
- Лендинг с предоплатой - с помощью этого инструмента обычно исследуют спрос и пытаются понять, каким должен быть MVP. Это поиск той самой заветной точки равновесия. Если проще, то на лендинге добавляете и убираете фичи из описания, смотрите на изменение конверсии и понимаете, что важно, а что нет.
- Flipchart-продажи. Это та же история, что и лендинг и предоплатой - вы исследуете спрос и понимаете, за что готовы люди отдать деньги.
- Продукт, который тестируется на рынке, отличном от планируемого. Частая ситуация: «Я щас на России потесчу, а потом выбегу в Калифорнию с тем же самым продуктом». Найденная точка равновесия на одном рынке очень редко коррелирует с точкой равновесия на другом рынке.
- Прототип/Альфа-версия. Если вы идёте к инвестору, он просит MVP, а вы показываете прототип, шансы на успех резко падают. Помедитируйте пару минут на картинки с айфонами абзацами выше. MVP можно продавать, прототип - нет.
При создании и развитии любого IT-продукта всегда имеют место быть люди от технологий и люди от бизнеса. С MVP так или иначе знакомы обе категории, с той лишь оговоркой, что последняя намного больше первой.
Концепция MVP (от англ. minimum viable product) минимально жизнеспособного продукта была разработана в рамках методологии Customer development - тестирования идеи или прототипа будущего продукта на потенциальных потребителях. Термин ввел в 1990-х годах американский серийный предприниматель Стив Бланк. Customer development часто противопоставлялся продуктоориентированному подходу («сделай классный продукт, а покупатель найдется»).
Сейчас термин больше используется для обозначения функционала, способного удовлетворить основные потребности заказчика и недорогого по стоимости разработки и внедрения. Несмотря на то, что фокус сместился с тестирования на поиск дешевого решения, концепция MVP осталась той же: минимально жизнеспособный продукт - решение не от бедности, а от рациональности и приоритезации.
Однако, в нарастающей конкурентности продуктового IT-рынка оказалось недостаточно одного лишь работающего прототипа функционала, который решал бы большинство проблем. Как известно, решать проблемы можно разными способами, но не за всякий люди готовы платить.
Рынок рождает множество аббревиатур, и в этот раз такой стала MMP - minimal marketable product (он же в некоторых статьях minimal sellable product). Такой минимальный набор возможностей продукта, за который люди готовы платить.
Как подружиться этим двум понятиям? Тут все относительно просто - одно следует за другим.
Ответ нам дает математика:
Сумма версий MVP в итоге дают нам MMP. А фактически:
MVP ver. 1 + MVP ver. 2 + MVP ver. 3 + … MVP ver. n = MMP
То есть, тестируя и расширяя (а иногда сокращая) потенциал продуктового решения, мы постепенно приходим к его положительному коммерческому наполнению.
Не всегда за минимально функциональную версию готовы платить и, конечно же, почти никогда люди не готовы отдавать деньги за работающий прототип полного решения.
И, если до этого момента все было хорошо, то теперь мы дошли до эмоций. Немного выше я упоминал конкурентность рынка, со временем все еще немного усложнилось. От измерений стандартных NPS чаша весов от лояльности склонилась в сторону любви клиента.
Теперь для качественного IT продукта недостаточно просто удовлетворять потребности заказчика . С этого момента нужно сделать все возможное, чтобы пользователь полюбил ваш продукт. Для обозначения минимального состояния, которого должен достичь продукт, чтобы быть любимым, выведена новая аббревиатура MLP - minimal loveable product. Концепция «минимально любимого продукта» заключается в идее, что не всегда нужно удовлетворять все нужды, чтобы быть любимым.
На языке рынка это означает, что юзер продолжает платить за ваш продукт, даже если он не до конца ему подходит. Только лишь потому, что он его любит.
И не спрашивайте меня, как это измерить (может так же, как NPS? :)
Данная короткая статья ни в коем случае не претендует на полноту в объяснении вопросов «минимальных продуктов». Тем не менее, надеюсь, что она сможет направить тех, кого эта тема заинтересовала, в нужном направлении.
Удовлетворяющих, любимых и продаваемых вам продуктов.
В начале 90-х годов компания Microsoft ввела в обиход статус под названием Microsoft MVP. Аббревиатура MVP расшифровывается как Most Valuable Professionals или говоря простым языком – это наиболее ценные профессионалы и эксперты в своей области. Статус Microsoft MVP присуждается сроком на один год и каждый новый год, человек, имеющий данный статус обязан подтверждать это звание своими делами. Кроме этого каждый человек, имеющий определенный вес в сообществе и славящийся своими достижениями по линии Microsoft, может претендовать на статус MVP. Чтобы побольше узнать о том кто такие MVP, как в Microsoft ведется работа с MVP и что нужно сделать, чтобы стать MVP, мы решили встретиться с Юлией Беляниной, MVP Lead Microsoft, которая отвечает за это направление в русском представительстве компании.
Наше досье
- В 1996 году окончила филологический факультет Московского Государственного Открытого Педагогического университета.
- С 1996 по 2004 год работала системным администратором, а затем руководителем IT-департамента в компании Grand Vision (один из крупнейших поставщиков контактных линз и средств ухода за ними).
- С 2004 года по 2007 год работала в ритейл-подразделении компании Телефон.Ру в должности руководителя IT-департамента головного офиса, затем в должности CIO.
- В 2007 году начала карьеру в российском офисе Microsoft на должности MVP Lead, каковую и занимает по настоящее время.
Станислав Горнаков: Юлия, здравствуйте! Очень рад, что вы согласились дать интервью. Юлия, как давно вы работаете в Microsoft и, как и откуда пришли на эту работу?
Юлия Белянина: В Microsoft я работаю с 2007 года, куда пришла из компании Телефон.Ру, одного из самых ярких и известных брендов на рынке сотового ритейла. В тот момент я приняла для себя стратегическое решение о том, что хочу попробовать работать в Microsoft, т. к. в должности CIO уже принимала участие в масштабных IT-проектах со стороны заказчика, и не видела для себя перспективы развития, которая бы была мне интересна с точки зрения дальнейших шагов в карьере.
Вопрос: В Microsoft сразу начали работать по линии MVP или до текущей должности попробовали себя и в других ролях?
Ответ: Я сразу начала работать в текущей должности, и единственное изменение состоит в том, что в момент прихода в Microsoft Россия эта должность предполагала работу по контракту, который продлялся на ежегодной основе. Спустя какое-то время это положение дел изменилось, и должность стала постоянной.
Вопрос: Чем вы конкретно занимаетесь и что курируете по линии MVP в Microsoft Россия?
Ответ: По сути дела я – account manager, только я работаю не с клиентами или партнерами, а с представителями сообщества, с лучшими, не побоюсь этого слова, представителями. Что обычно делает account manager? Если исключить коммерческую составляющую, каковая в моем случае отсутствует, то останется следующее – поддержка предоставления официальных привилегий, которые доступны участникам MVP Award Program, сопровождение участия MVP в различных проектах для сообществ, решение проблем, возникающих в процессе взаимодействия MVP с локальным офисом или штаб-квартирой в Редмонде, проведение мероприятий для MVP, а также привлечение их к работе на наших ключевых конференциях, таких, как TechEd Russia или DevCon, которые все MVP могут посетить абсолютно бесплатно.
Для всех MVP я – главное контактное лицо в Microsoft, и они могут обращаться ко мне по любым вопросам, касающимся наших технологий, организации работы с сообществом, продвижения и разработки наших продуктов. В мои обязанности также входит продвижение бренда MVP на территории России. Все вопросы, касающиеся PR и имиджа MVP Award Program в данном регионе также находятся в моем ведении. Кроме всего вышеперечисленного, я занимаюсь поиском новых MVP и принимаю решения о продлении статуса MVP на уровне регионального менеджера, прежде чем финальное решение будет принято в штаб-квартире.
Вопрос: В целом команда MVP Award Program Russia по составу большая? Кто вам еще помогает и работает в этом направлении в российском офисе?
Ответ: В данный момент команда состоит из двух человек – это ваша покорная слуга и Валерия Полякова, являющаяся моей правой рукой, которая работает в должности координатора MVP Award Program и помогает мне решать непростые вопросы, порой возникающие у MVP, а также занимается еженедельными рассылками, отправкой приглашений на различные мероприятия, которые мы организуем для MVP либо предоставляем им право привилегированного участия в них, и прочими вопросами, в процессе решения которых может понадобиться помощь в работе с MVP.
Вопрос : Вы работает только с российскими MVP или ведете это направление и по всем странам СНГ?
Ответ : Я отвечаю не только за Россию, но и за все страны СНГ за исключением Прибалтики.
Вопрос: Сколько у нас MVP по России и по всему СНГ в частности?
Ответ: На данный момент в регионе 132 MVP, из них 100 – в России, 25 – в Украине, 4 – в Казахстане, 2 – в Беларуси и один в Молдове.
Вопрос: А в целом по миру какова статистика?
Ответ: В целом в мире более 4000 MVP, проживающих более чем в 100 странах и говорящих на более чем 40 языках.
Вопрос: Что такого дают эти люди и почему Microsoft очень сильно ценит своих MVP?
Ответ: Об этом можно говорить часами, и этого будет недостаточно, чтобы рассказать, как именно MVP помогают нам, что мы получаем от них и каким образом взаимодействуем.
MVP всегда вовлечены в процесс создания наших продуктов еще на этапе их разработки – они получают доступ к бета-версиям продуктов раньше других, общаются с продуктовыми командами в рамках специальных мероприятий, направленных на улучшение качества наших продуктов, различных онлайн-инициатив, доступных только для MVP , а также при помощи специального сервиса MS Connect, ограниченно доступного также другим клиентам и партнерам. О большинстве багов в рамках тестирования продуктов как правило нам сообщают именно MVP. Они же в немалой степени способствуют продвижению наших продуктов на рынке, их популяризации, и это также неотъемлемая часть результатов их деятельности. Поддержка, которую MVP оказывают сообществу, заказчикам и партнерам на волонтерской основе, является поистине бесценной, т. к. зачастую их уровень знаний соответствует таковому, а в некоторых случаях и превосходит уровень знаний специалистов, работающих в региональных офисах Microsoft по всему миру.
Одним из важнейших постулатов MVP Award Program является тот факт, что MVP – это прежде всего независимые эксперты, свободные в своих суждениях и оценках от привязки к точке зрения текущего работодателя, так как они не являются сотрудниками Microsoft. Конструктивная критика, которую они предоставляют нам, показывает все ошибки и недочеты, допущенные нашими разработчиками в процессе работы над тем или иным продуктом, и это помогает нам взглянуть на то, что мы делаем со стороны, услышать наших клиентов, конечных потребителей, а во многих случаях последовать их советам.
MVP включены практически во все сферы нашей деятельности, начиная от мероприятий и заканчивая тестированием продуктов, с одним единственным ограничением – все, что делают MVP в рамках MVP Award Program, не должно касаться продаж или получения иной коммерческой выгоды от результатов их деятельности.
В целом, вклад MVP в развитие наших продуктов сложно переоценить, и именно поэтому Microsoft высоко ценит возможность обмена мнениями с лучшими экспертами технического сообщества.
Вопрос: Каким образом происходит обратная связь между MVP и Microsoft?
Ответ: Как я уже упомянула, обмен мнениями происходит в рамках различных мероприятий – как offline так и online, при помощи сервиса MS Connect, путем участия в тематических рассылках, доступных MVP по каждой экспертизе. Интенсивность такого взаимодействия зависит от потребностей продуктовой команды в получении обратной связи, но в целом ее можно оценить как высокую.
Вопрос: Можно утверждать, что для MVP по некоторым вопросам «тайные» двери Microsoft открыты несколько шире, чем для других людей?
Ответ: Безусловно. Прежде всего, это касается более тесных контактов с разработчиками в Редмонде, среди которых довольно много наших соотечественников а также программистов из других стран СНГ, где широко распространен русский язык. Кроме того, как я уже сказала, о большинстве важнейших анонсов MVP информируются заранее, они также получают доступ к бета-версиям наших продуктов значительно раньше других. Это элита технического сообщества, интересы которой Microsoft всегда учитывает в работе с сообществом.
Вопрос: Много ли примеров MVP, которые впоследствии устроились и успешно работали в компании Microsoft?
Ответ: За последние 2 года только в том регионе, за который я отвечаю, более 10 человек перешло на работу как в российский офис Microsoft, так и присоединилось к нашим продуктовым командам в Редмонде. В США этот показатель еще выше, но Россия в данном контексте далеко не на последнем месте, как одна из стран с большим потенциалом.
Вопрос: Статус MVP присуждается сроком на один год. Одни MVP его продляют благодаря своим достижениям, другие становятся MVP в первый раз. Человек, желающий стать MVP, что должен сделать такого, чтобы его заметили и оценили?
Ответ: Есть два ключевых момета, являющихся основополагающими для кандидатов, желающих получить MVP Award. Во-первых, человек, претендующий на это звание должен быть признанным гуру в своей области, экспертом, к мнению которого прислушиваются в сообществе. Во-вторых, такой кандидат должен постоянно делиться знаниями на волонтерской основе – выступать на мероприятиях, отвечать на вопросы пользователей в форумах и т. д., и количество таких выступлений и ответов должно быть сравнимо с достижениями других кандидатов на получение MVP Award во всем мире. Баланс между этими двумя составляющими определяет результат процесса номинации.
Вопрос: А есть ли какой-то рецепт или требования, гарантирующие получение MVP? Не знаю, например, написать 1000 сообщений в блоге, 1000 сообщений в форуме или где-то еще. То есть, имеются какие-то четкие критерии отбора кандидатов для номинации в MVP?
Ответ: Таких критериев не существует, так как получение MVP Award в каждой конкретной экспертизе зависит от многих факторов – востребованности и распространнености продукта, желания и возможностей команды разработки по взаимодействию с сообществом, количества претендетов на получение статуса во всем мире. Подобные цифры могут существенно различаться от экспертизы к экспертизе, и поэтому предоставить какой-то единый рецепт не представляется возможным.
Вопрос: Кто может предложить новую кандидатуру на статус MVP?
Ответ: Любой эксперт, уже обладающий статусом MVP, может предложить кандидата на получение MVP Award, кроме этого, любое техническое сообщество, обладающее значительными достижениями, известное в регионе, может предложить кандидата. Мы детально рассматриваем каждую поступившую к нам заявку вне зависимости от того, кто именно ее прислал.
Вопрос: А сами работники Microsoft могут предлагать кандидатов на MVP?
Ответ: Любой сотрудник Microsoft может заполнить специальную форму на внутреннем сайте чтобы порекомендовать кандидата на получение MVP Award. В таких случаях в приоритетном порядке рассматриваются заявки от сотрудников групп разработки наших продуктов.
Вопрос: Каким образом в Microsoft происходит та самая закулисная процедура оценки кандидата с последующим его награждением или отказом?
Ответ : Процедура не настолько закулисная, как это может показаться на первый взгляд. Раз в квартал, в начале номинационного цикла (циклы начинаются соответственно 1-го января, 1-го апреля, 1-го июля и 1-го октября) мы собираем заявки кандидатов, желающих продлить свой статус, а также заявки тех, кто претендует на получение MVP Award в первый раз. Каждый кандидат заполняет специальную форму, в которой перечисляются все его достижения за предыдущий календарный год. Далее данная форма рассматривается на региональном уровне при участии MVP Award Program Team в регионе, а также, при необходимости, технических специалистов, работающих в региональном офисе страны проживания кандидата, если таковой офис существует. Оценивается количество активностей, релевантность экспертизе, в которой кандидат желает получить MVP, качество контента и некоторые другие параметры. Далее информация вносится в специальную базу данных, и на следующем уровне ревью проводят наши коллеги из MVP Award Program Team в Редмонде при участии сотрудников из групп разработки наших продуктов. Далее каждая продуктовая группа, исходя из своих стратегических приоритетов, решает, сколько MVP по данному продукту/технологии достаточно для плодотворного взаимодействия с сообществом. И вот тут как раз начинаются те самые различия, о которых я упоминала выше – одна из групп может решить, что им нужно N кандидатов, где в одном случае N= 200, а в другом – N=10, при этом в отборе участвуют как новички, так и те, кто реноминируется уже не в первый раз. Далее из общего количества заявок отбирается TOP-N по каждой экспертизе в соответствии с потребностями продуктовой команды, и именно эти кандидаты получают статус, а остальные заявки отклоняются. Именно поэтому (таковы особенности программы) не существует общего руководства с конкретными цифрами на тему «Как получить MVP Award».
Вопрос: Почему процедура номинации на получение MVP Award не является полностью прозрачной? Возможно, более правильным было бы руководствоваться результатами голосования в сообществе, и тогда уже принимать решение о вручении награды.
Вопрос: Существуют ли годовые обязательства, по которым MVP Lead должен номинировать как можно больше кандидатов, и получает ли MVP Lead бонусы за количество номинированных кандидатов в регионе?
Ответ: Нет, таких обязательств не существует, и каждый MVP Lead руководствуется исключительно соответствием уровня знаний и волонтерских активностей конкретного кандидата статусу MVP. Финальное решение о количестве кандидатов, а также о том, получит ли конкретный кандидат MVP Award, принимается на уровне штаб-квартиры, и никаких бонусов за количество кандидатов не предусмотрено.
Вопрос: MVP не получают за свой статус каких-то денежных вознаграждений или зарплату, но Microsoft конечно же поощряет таких людей. Какие именно бонусы Microsoft предлагает своим MVP?
Ответ: Прежде всего, я хотела бы заострить внимание на том факте, что MVP Award Program – это дорога с двусторонним движением. Нельзя сказать, что в рамках взаимодействия MVP и Microsoft выгоду получает только Microsoft, несмотря на то, что никаких материальных бонусов для MVP не предусмотрено. Люди, которые делятся знаниями о наших продуктах, существовали задолго до появления MVP Award Program, и в Microsoft просто создали программу поддержки таких волонтеров. Если бы MVP Award Program никогда не существовало, такие люди все равно бы делились знаниями с теми, кому эти знания нужны, мы же просто стараемся создать для них режим наибольшего благоприятствования, помогать им в тех областях, где нужна наша помощь, делиться с ними информацией (во многих случаях – конфиденциальной) и с их помощью делать наши продукты лучше. Поэтому главный бонус MVP Award Program – это возможность влиять на будущее наших продуктов, на стратегию их развития, на то, по какому пути движется Microsoft.
В списке бонусов также есть бесплатные подписки MSDN и TechNet, три бесплатных обращения в нашу службу поддержки (для России и Украины при поддержке локальных офисов мы предоставляем неограниченное количество support-инцидентов для MVP), это также возможность участия на льготной основе в глобальных и региональных конференциях, таких как TechEd и многие другие, а также мероприятия, которые мы проводим только для MVP – ежегодные конференции MVP Open Days и MVP Global Summit. И если на MVP Open Days приезжают MVP из одного региона (такого, например, как Россия и СНГ), и у них есть возможность пообщаться друг с другом и с сотрудниками регионального офиса/представительства, то на MVP Global Summit они могут напрямую задать вопросы разработчикам, получить ответы, предложить новый функционал или обсудить острые вопросы использования продукта/технологии Microsoft. MVP Summit – крупнейшая технологическая конференция, которая проходит непосредственно в кампусе Microsoft в Редмонде, и она уникальна с точки зрения контентной составляющей – многие участники неоднократно отмечали, что нельзя даже сравнить TechEd с MVP Summit, т. к. именно на последнем предоставляется огромное количество конфиденциальной информации, которой нет в открытом доступе, и она предоставляется на условиях NDA.
Список бонусов включает в себя еще несколько пунктов, таких как, например, Award Gift, или Executive Recognition Letter, возможность использования всемирно известного логотипа MVP на своих визитках, в блогах и на форумах. Их состав периодически меняется, но одно остается неизменным – признание Microsoft, признание сообщества и возможность активного участия в работе над нашими продуктами, настолько активного, насколько оно возможно для человека, не являющегося сотрудником компании – это и есть самый главный бонус для кандидата, получившего MVP Award.
Юлия, большое спасибо за интересное интервью, удачи вам и всего самого наилучшего.
——————
На заметку
Если вы хотите продвинуть свой сайт, и не уверены в своих силах, то всегда можете обратиться к профессионалам, которые помогут вам сделать качественную раскрутка сайта , а также выполнить любые работы по поисковому продвижению Интернет-проектов.
