Эффективный евангелизм. Часть III

Это первый из двух заключительных постов, посвященных эффективному евангелизму в трактовке Дж.Пламондона. Как и обещал, указываю первоисточник всего этого великолепия – сайт Groklaw (он давно висит у меня в уголочке «Полезные ссылки»). Там есть раздел, посвященный судебному делу «Comes vs. Microsoft» (одно из нескончаемой череды разбирательств с Microsoft на антимонопольную тему) - вот в этом-то разделе и лежит документ общим объемом более сотни страниц. Правда, большинство этих страниц представляет сканы распечатанных презентаций Пламондона, предназначенных для «внутреннего потребления» в Microsoft (забавно, что одна из этих презентаций представлена в отцензурированном виде – два десятка страниц, на которых видны только замазанные черным контуры слайдов). Но есть и два текста – введение в эффективный евангелизм (его я перевел и опубликовал самым первым) и практическое руководство «Типовой график Евангелизма» («Generalized Evangelism Timeline»), краткое изложение которого я опубликовал несколько дней назад, а развернутые тезисы по каждому из 12-ти пунктов графика, наконец-то, публикую сейчас.

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

Конечно, найдутся те, кто обвинит меня в манипулировании переводом… Приходится признаться – действительно манипулировал :). Я посчитал, что некоторые прописные маркетинговые истины будут неинтересны тем, кто знает в этой области гораздо больше меня. Зато, надеюсь, всем читателям будет интересно взглянуть на «закулису» глянцево-гламурного маркетинга Microsoft.

Наиболее ударные фрагменты текста и отдельные фразы я позволил себе выделить жирным шрифтом – они того стоят.

Джеймс Пламондон

Типовой график Евангелизма (фазы 1..4)

1: Начало Евангелизма

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

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

Задолго до появления детальной спецификации необходимо решить (вместе с технологической командой), поддержка каких НВ является (а) наиболее критичной для успеха технологии и (b) может быть получена наиболее легким способом – по тем или иным причинам. На условиях конфиденциальности и с поддержкой со стороны технологической команды, обсудите технологию неформально с небольшим числом (четыре, плюс-минус два) таких критически важных НВ, чтобы получить реалистичную оценку отношения НВ к технологии. 

Теперь вы готовы к разработке плана Евангелизма. Во-первых, определите цель технологии. Обычно это достаточно просто: стать де факто стандартным отраслевым механизмом для [решения некоторой задачи]. Для достижения этой общей цели, по пути необходимо будет достигнуть нескольких конкретных, измеримых целей. Примерами целей могут быть:

• Заручиться обязательствами N инструментальных вендоров о поддержке технологии в своих инструментальных средствах к [некоторой конкретной дате]
• Обеспечить демонстрации M поставщиками ПО поддержки технологии в бета-версиях своих приложений в рамках [конкретных мероприятий]
• Выпустить Y книг по технологии к [конкретная дата], чтобы помочь разработчикам с реализацией поддержки технологии в их приложениях

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

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

НВ, намеченные для Евангелизма, должны быть категоризированы по четырем уровням:

1. Уровень A. Наиболее влиятельные вендоры - либо по занимаемой доле рынка, либо по степени воздействия на умы. Состав их обычно очевиден, но всегда нужно провести небольшое исследование, чтобы убедиться, что вы никого не упустили из виду.
2. Уровень B. Менее влиятельные вендоры, которые могут оказаться полезными для Евангелизма по какой-либо причине – возможно, потому что они:

a)       Являются легкой добычей

b)       Обычно считаются принадлежащими к вражескому лагерю, так что поддержка ими вашей технологии будет шоком (и, возможно, приведет к разброду и шатаниям в стане неприятеля)

c)        Совершенно бесполезны с евангелической точки зрения, но вы можете вынудить противника затратить массу ресурсов на их евангелизацию, если ему станет известно, что «Microsoft проявляет интерес» к этим компаниям.

3. Уровень C. Вендоры, которым совершенно не достает влияния, но к которым вы могли бы обратиться с рассказом о технологии, если вы сможете пообщаться с ними в стиле «один ко многим» - возможно, когда вы находитесь в их городе для встречи с представителем Уровня А.
4. Уровень Z. Вендоры, которые вообще не должны знать, что вы существуете, чтобы они не могли написать вам по электронной почте, позвонить или как-то еще отнять у вас время.

Для некоторых технологий более подходящими могут оказаться независимые поставщики контента (ICP - Independent Content Provider), а не независимые вендоры ПО. Для других вы можете захотеть привлечь поставщиков «железа», рекламные агентства или других провайдеров евангелических «рычагов». Термин НВ используется здесь для общего обозначения всех этих разнообразных мишеней Евангелизма – вы можете подставить на его место любой другой, подходящий для вашей конкретной технологии, сервиса или чего-то еще.

В дополнение к выявлению и категоризации соответствующих НВ, Евангелизм должен также в ходе первой фазы определить и классифицировать влиятельных отраслевых авторитетов. Существуют три категории отраслевых авторитетов:

1. Провайдеры евангелической инфраструктуры: Авторы технических книг, разработчики и преподаватели обучающих курсов, авторы технических статей, организаторы конференций, консультанты по программному обеспечению и контрактные разработчики – Евангелизму необходимо привлекать всех этих людей на различных этапах евангелистской кампании, чтобы быть уверенным, что НВ и индивидуальные разработчики имеют информацию, необходимую для (a) принятия решения о поддержке технологии, и (b) реализации технологии в своих приложениях.
2. Пресса: Практически каждая евангелистская кампания включает в себя работу с прессой, напрямую или через PR-агентства. Наш план Евангелизма должен определить конкретных представителей прессы, которых мы можем сделать мишенями для технического евангелизма (в отличие от обычной, нетехнической PR-обработки).
3. Аналитики: Аналитики – это люди, которым платят за то, чтобы они занимали определенную позицию, при этом всегда стараясь выглядеть незаинтересованными наблюдателями (потому что видимость независимости максимизирует цену, за которую они могут продаться). Обращайтесь с ними так же, как вы обращались бы с ядерным оружием – как с важнейшей составляющей вашего арсенала, которую вы хотели бы держать подальше от неприятельских рук. Купите их для создания «исследования», которое подтверждает, что ваша технология имеет преимущество перед вражеской, и что она набирает обороты быстрее.

После определения преследуемых целей, НВ, чья поддержка вам необходима, а также конкретных «кнутов и пряников», которые вы собираетесь применять, чтобы заручиться их поддержкой, вы готовы к тому, чтобы задокументировать свой план в качестве Плана Евангелизма.

После завершения разработки Плана можно начинать подготовку к представлению вашей технологии избранной группе НВ – Презентации Дизайна.

2: Подготовка к Презентации Дизайна

Презентация Дизайна представляет собой собрание мишеней Евангелизма, которым Microsoft представляет раннюю весию технологии. Цели Презентации Дизайна:

1. Убедиться, что технология действительно полезна для НВ, без каких-либо вопиющих недостатков, которые воспрепятствуют ее использованию предполагаемым способом – и собрать любые мнения, которые могут ее улучшить.
2. Дать участникам возможность почувствовать себя почетными, уважаемыми и вовлеченными в происходящее, с тем, чтобы они эмоционально связали себя с технологией, и с большей вероятностью склонились к поддержке ее в своих продуктах.
3. Действовать в качестве дополнительного стимула для технологической команды, требуя от нее создания более четких описаний, демо и спецификаций.
4. Генерировать позитивную прессу, посвященную технологии.

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

До начала Презентации должны быть предприняты различные закулисные шаги, чтобы убедиться, что результат будет положительным. Большинство этих шагов можно найти в книге «Чему Они Не Будут Вас Учить В Гарвардской Школе Бизнеса», или в руководствах «Как Победить В Офисной Политике», или в подобных. Например, вы всегда до Презентации должны знать, что ваши НВ собираются говорить на Презентации, чтобы это не стало для вас неприятным сюрпризом. Лучше всего (хотя не всегда возможно) евангелисту встретиться с каждым участником Презентации до ее начала – возможно, под предлогом персональной доставки спецификации, которая будет обсуждаться на Презентации. На этой предварительной встрече евангелист может поверхностно «пробежаться» по спецификации и почувствовать, к каким высказываниям и поступкам склонен вендор. Если ожидается, что комментарии вендора будут положительными, нужно способствовать выступлению такого вендора в ходе Презентации, а докладчики должны быть сориентированы на обращение к такому участнику. Если комментарии вендора ожидаются негативными, евангелист может попытаться среагировать на них до Презентации. Они могут, например, быть учтены путем пересмотра спецификации – или, возможно, подбором других НВ, которые будут противостоять негативным комментариям в ходе Презентации (так что Microsoft будет выглядеть учитывающим пожелания других вендоров, а не затыкающим своей спецификацией рты ее противникам).

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

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

Приглашения должны быть разосланы дружественному подмножеству НВ Уровня A, а также провайдерам евангелической инфраструктуры (см. выше). Прессу обычно не приглашают. Аналитиков нужно приглашать, только если они уже куплены. Группа поддержки продукта должна прислать своих сотрудников, которые наиболее сведущи в поддержке этой новой технологии.

3: Проведение Презентации Дизайна

Цели Презентации Дизайна описаны выше. Подобные презентации относительно неформальны по своей природе – никто не ожидает, что будут соблюдаться правила парламентского этикета. Конечно, презентаторы должны быть соответственно подготовлены, демо-примеры не должны «падать» (слишком часто), закуски должны быть приличными (и в нужном количестве) и т.п.

Евангелист должен вести программу Презентации Дизайна. Ответственность ведущего включает:

• Приветствия прибывающим НВ и поощрение других евангелистов к приветствию их собственных аккаунтов
• Уверенность в том, что случайные проблемы приглашенных (проблемы с заказом такси, изменение времени рейсов, лопнувшие по шву брюки, неожиданное недомогание и т.п.) решаются оперативно и аккуратно
• Объявление каждого докладчика и обеспечение соблюдения регламента выступающими
• Помощь при проведении сессий вопросов и ответов
• Сумасшедший «дружеский треп» в перерывах – сбор отзывов от максимально возможного числа участников, представление участников со сложными вопросами или великолепными идеями соответствующим докладчикам
• Уверенность в том, что докладчики болтаются поблизости во время перерывов, ланча и вечерних мероприятий
• Сбор написанных и подтвержденных цитат от НВ для использования в пресс-релизе по окончании презентации
• Выполнение всего необходимого, что может еще потребоваться (в пределах здравого смысла и вкуса) для того, чтобы участники получили всю необходимую информацию, предоставили нам устраивающие нас отзывы и хорошо провели время.

 

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

Самое главное – к участникам нужно все время относиться с уважением. Каждый участник должен уйти с мероприятия с ощущением, что Microsoft действительно прислушался к тому, что этот участник говорил.

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

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

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

4: Ограниченный релиз для разработчиков

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

Начиная с Ограниченного релиза для разработчиков, Евангелизм должен присутствовать на всех совещаниях руководителей проектов (РП) и совещаниях по приоретизации ошибок, будучи готовым предоставить данные в поддержку изменения приоритетов ошибок и порядка реализации новых возможностей, базируясь на отзывах НВ.

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

  

Программа ранних последователей (или «Первая Волна») для технологии финализируется во время этой фазы (первоначальные «кнуты и пряники» предложены еще на самой первой фазе Евангелизма). Программа «Первой Волны» предлагает конкретным НВ Уровня A возможность получения конкретных технических и маркетинговых выгод в обмен на их готовность обеспечить поддержку технологии в их приложениях к нужному моменту времени. Все элементы программы излагаются очень подробно в документе «Меморандум о Взаимопонимании», также известном как «Письменное Соглашение» (Letter of Agreement – LOA). Соглашение должно быть подписано топ-персоной НВ – Директором, Вице-президентом, Генеральным директором или Президентом, чтобы быть уверенным, что декларируемая готовность всерьез воспринимается вендором. Если Соглашение подпишет РП, вендор всегда может впоследствии заявить, что РП не имел необходимых полномочий. Аналогично, со стороны Microsoft Соглашение должен подписывать Директор по Евангелизму. Соглашение – это не юридический, обязательный контракт, и поэтому у каждой стороны остается пространство для маневра. Оно должно трактоваться как уточняющий документ, который гарантирует, что не осталось недопониманий относительно того, о чем было договорено и кем. Мы не можем заставить соблюдать Соглашение, но мы определенно можем помнить, кто соблюдал его, а кто нет.