Пиарщик: «Наши реселлеры попросили подготовить раздаточные материалы. О чем в них написать?».
Топ-менеджер: «Через пару дней у меня важная презентация перед потенциальными клиентами. Как их убедить дать заказ именно нашей компании, а не индийским конкурентам?»
Дизайнеры: «Решили создать на корпоративном сайте ленту новостей. Какая информация достойна публикации?»

Отсутствие знания, как решать подобные проблемы, приводит к тому, что в рекламных материалах содержится ряд типовых ошибок:

Рекламируются технологии: Java, .NET, ASP, Perl, C/C++, а не готовые проекты и задачи. Контрпример: строительная компания рекламирует дома, а не бетон и кирпич.
Рекламируется город, в котором находится компания, а не сама компания и ее достижения. Например: «Мы находимся в Москве, столице Российской Федерации» или «В Москве расположено много ВУЗов».
Употребляются эпитеты, хвалебные слова, не подкрепленные конкретными примерами. Многие слова уже стали штампами: «большой опыт», «методология быстрой разработки приложений», «квалифицированная команда разработчиков», «креативный подход». Они не несут никакой конкретики и напоминают рекламу гербалайфа на рынке труда.
Используются аналогии, содержащие «образ-вампир»¹. Например, на рекламном плакате одной софтверной компании присутствовало изображение головного мозга. Задумка авторов: мозг должен показать качество и креативность разработок. Однако клиенты подумали иначе: плакат посвящен анатомии или рекламе врачебных услуг.

Кто виноват?

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

Клиента беспокоит:

Будет ли программа сдана в срок?
Смогут ли его разработчики разобраться в исходном коде?
Не воспользуются ли доступом, который он предоставил в свою корпоративную сеть подрядчику, с иными целями, помимо самого заказа?

Разработчики сталкиваются с проблемами:

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

А отдел рекламы принимает решения примерно в следующем стиле:

«Давайте сделаем нечто крутое!»
«Мне нравится этот журнал. Давайте дадим в нем рекламу?»
«А что, если устроить бесплатный обед и пригласить на него наших потенциальных клиентов? Они будут обедать, а мы - будем рассказывать о нашей компании».

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

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

Есть ли выход?

Как же следует поступать добросовестному рекламисту? Существует ли способ, позволяющий сконцентрировать усилия различных подразделений компании на одном выигрышном направлении? В качестве возможного варианта, интересно рассмотреть способ, который называется «Присоединение к потоку проблем»². В общем виде, метод заключается в выявлении системы проблем клиента и использовании выявленных трудностей и найденных решений для «отстройки от конкурентов»³. Метод состоит из двух шагов: 1)собрать проблемы/стереотипы клиентов, 2)«овеществить»⁴ собранные стереотипы в виде рекламных текстов и услуг.

Шаг 1. Собрать проблемы/стереотипы клиентов.

Для сбора проблем/стереотипов клиентов можно применить разные способы: провести опрос среди самих клиентов, понаблюдать за ними: «Какие программы они заказывают?», «Для каких целей?». Провести опрос среди менеджеров и программистов: «О чем клиенты говорят? Что их беспокоит?». В данной статье мы не будем детально останавливаться на всех способах выявления проблем, а дадим рекомендации относительно того, как следует проводить опрос.

При опросе можно воспользоваться «методикой неоконченных предложений»⁵. Ее суть: опрашиваемый продолжает фразы, начатые рекламистом. Также важно соблюдать определенные правила⁶. Следует задавать не общие, а конкретные вопросы. Вопросы вида: «Что такое демократия?» или «Дайте, пожалуйста, определение программного обеспечения» - поставят клиента в тупик и, соответственно, не дадут каких-либо значимых результатов. Для получения четкого ответа необходимо формулировать вопросы через частицу «не». «Что вам не нравится?», «Почему вы не обратитесь?», «Почему вы не купите?». При таких условиях клиенту легче дать искренний ответ, чем придумать какую-нибудь отговорку. В результате, он назовет либо реальную (существующую) проблему, либо свой стереотип, свой страх. Следует заметить, что не всегда названная проблема будет существовать объективно. Нередко клиент высказывает только свои опасения, которые ему мешают воспользоваться услугой или приобрести тот или иной товар. В последнем случае рекламная кампания должна быть направлена на то, чтобы развеять эти опасения.

Подобный опрос был проведен на форуме «Открытые методики рекламы и PR. Рекламное измерение». Вопросы звучали следующим образом:

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

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

Результаты опроса

Тема Отрицательные стереотипы, проблемы

Компания «Компания пропадет, исчезнет, а программу некому будет сопровождать».
«Сделают сайт и "испарятся" вместе с исходниками. А если потом переделывать понадобится?»

Качество работы «Сделают не так, как мне нужно, а переделывать будет уже поздно».
«Будут проблемы с сопровождением».
«Я вообще боюсь шаманства soft-подрядчиков и стараюсь по возможности найти стандартный продукт».

Цена «Будут раздувать цены, ссылаясь на “трудности”, в которых я не разбираюсь».

Авторские права «Сделают с нарушением авторских прав: надергают картинок с чужих сайтов. Зачем мне потом эти проблемы?»
«Будут проблемы с сопровождением».
«Боюсь, что продадут исходный код программы моим конкурентам или используют его в каком-нибудь другом проекте».

Исходный код «Есть ли у них единые требования к оформлению исходного кода? Соблюдаются ли они разработчиками?»
«Напишут код таким образом, что потом никто в нем не сможет разобраться».

Тестирование «Не знаю, сколько должно выделяться времени на тестирование. Не имею об этом представления».
«Все ошибки тестеры выявят за пару дней, остальное время тестирования ПО - просто оправдание низкой скорости работы сотрудников фирмы и бюрократические проволочки».
«Тестеры все равно все ошибки не найдут, и мне проще попросить 10-20 своих знакомых (студентов, друзей, сотрудников), чтобы они тот же результат получили скорее».

Документация «На сайте не приведены примеры документации. Боюсь, что не смогут написать».
«Боюсь, что не смогут написать так, чтобы было понятно моим ничего не понимающим в программировании сотрудникам».

Шаг 2. «Овеществить» стереотипы клиента в виде рекламных текстов и услуг.

Некоторые из найденных стереотипов можно «овеществить», т.е. открыто назвать и представить в виде рекламных текстов, речевых модулей, примеров успешно выполненных заданий, а также в виде стандартных услуг.

Наглядные примеры

Рассмотрим пару примеров, иллюстрирующих применение метода «Присоединение к потоку проблем».

Пример 1. В софтверную компанию обратился клиент с просьбой разработать плагин для Microsoft Office. Компания приняла заказ и выполнила работу. В результате, у компании накопился какой-то опыт. Этот опыт включает: трудности, с которыми разработчикам пришлось столкнуться в ходе работы над проектом, решения, которые были выработаны для преодоления этих трудностей и набор базовых классов, которые не зависят от проекта. Далее с накопленным опытом можно поступить по-разному:

Бизнес-процесс Рекламные и маркетинговые материалы, сайт

Вариант 1 Оставить без изменений. Опыт содержится в головах разработчиков. Оставить без изменений.

Вариант 2 Формализовать опыт. Разработать внутренние документы:

«Типовые шаги разработчика при создании плагина к Microsoft Office».
«Перечень типовых задач и их стандартных решений при создании плагина к Microsoft Office».
«Перечень типовых ошибок в плагинах к Microsoft Office».
Написать анонс, что компания умеет разрабатывать плагины к Microsoft Office, и создать соответствующий раздел на корпоративном сайте.
Последний может включать:

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

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

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

Из приведенного примера видно, что «овеществление» стереотипа в услугу требует изменений не только в рекламных и маркетинговых материалах, но и в технологическом процессе.

Пример 2. Одна из проблем, которая волнует клиента, - это сопровождение. Клиент беспокоится: «Компания пропадет, исчезнет, и программу некому будет сопровождать. Исходный код окажется нечитаемым, и к нему не будет написано никакой документации». Это беспокойство можно устранить, «овеществив» стереотип клиента в виде набора текстов и услуг. На сайт компании можно выложить: правила оформления исходного кода, примеры исходного кода, оформленного по указанным правилам, стандарты на оформление технической документации, примеры технической документации для программы.

Любая программа требует обучения и подготовки персонала. Не редкий случай, когда компания, разрабатывающая программы, открывает свое издательство и свои учебные центры. Например, при компании “Microsoft” существует издательство “Microsoft Press”, а при компании «1С» - издательство «1С-Паблишинг». Софтверной компании не стоит забывать об этом варианте. Конечно, программы, которые разрабатывает аутсорсинговая компания, не рассчитаны на массового пользователя. Тем не менее, это не означает, что услуги по написанию документации и обучению пользователей не будут востребованы. Их просто нужно продекларировать и продемонстрировать качественные примеры.

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

Автор благодарит И.Л. Викентьева и С.В. Сычева за помощь в подготовке статьи.

Дизайн и поддержка: Silicon Taiga

Обратиться по техническим вопросам