Начиная с очередным владельцем сайта разговор о том, что бы он хотел получить от вывода его детища (проекта) в социальные сети, я для начала разговора делюсь подборкой публикаций по этой теме. Чтобы, так сказать, сверить позиции. Почетное место в этом комплекте занимает небольшая, но очень емкая статья Наталии Прытковой '13 правил успешного сообщества', которую можно прочесть здесь. И ни разу не было случая, чтобы кто-то возразил, оспорил приведенные специалистом рекомендации. Проблемы начинаются потом. А именно: в процессе реализации проекта.
То есть, если вообще – то да, все советы Наталии принимаются с полным пониманием. Но если вот конкретно и именно в нашем случае, то тут же нужно учесть особенность конкретной ситуации, имеющиеся ресурсы, накопленный ранее опыт работы с сайтом и его продвижением – и сделать все попроще и побыстрее. И тогда принятые ранее Владельцем в общем и целом рекомендации приходится конкретизировать, показывать, где и как они должны быть использованы в ходе выполнения работ. Другими словами, встает задача адаптации, привязки к конкретному технологическому процессу того, что в статье называлось 'правила'. Теперь же их следует называть 'требованиями, подлежащими выполнению', ведь они изначально возражений не вызывали, ну так значит нужно выполнять.
Вот что из этого получается у меня, и вот что хотелось бы обсудить с заинтересованными коллегами, с Наталией Прытковой, естественно, в первую очередь.
1 Общий алгоритм
1.1 Транслируем Правила в Требования.
1.2 Накладываем Требования на техпроцесс.
1.3 Выставляем оценки: получилось или не получилось, возможно, баллы или ранги.
1.4 Там, где оценки особенно низки и невыполнение требований особенно заметно, планируем мероприятия по доведению до требуемого уровня.
Выставлять оценки и планировать мероприятия мы по ходу этой стати не будем, ограничимся для краткости первыми двумя пунктами – это наиболее важные этапы и в значительной мере универсальные.
2 От Правил к Требованиям
На первый взгляд это чисто техническая процедура, хотя это и не совсем так. Берем исходный текст рекомендаций (см. ссылку) и редуцируем его до кратких названий пунктов-требований. Получается примерно так:
2.1 Определение целевой аудитории
2.2 Старт-контент
В начале проекта 'Старт', а затем по мере продвижения используются, например, 'Стабилизация' или 'Раскрутка', т.е. название фазы проекта.
• План фазы
• Реализация плана
2.3 Клиенты
• Постоянные (более одного контакта)
• Реальные (один контакт)
• Потенциальные (нет контактов, но есть принадлежность к нужному сегменту)
2.4 Онлайн-регламент, ресурсы
2.5 Онлайн-политика
2.6 Негатив-политика
2.7 Процедура адаптации
2.8 Регламент обратной связи
2.9 Искренность как основа доверия
2.10 Концепция сообщества (интересы его членов во взаимодействии с интересами Владельца)
2.11 Реклама - стоп
2.12 Общение (перекрестное, с учетом особенностей составных кластера – см. http://www.e-xecutive.ru/community/articles/1570543/ )
• Корпоративный сайт
• Форумы
• Блоги
• Рассылки
• Аккаунты соцсетей
• Сообщества соцсетей
2.13 Экспресс-конвертация - стоп.
Требования приведены без пояснений, так как это уже сделано в упоминавшейся статье. Конечно, в процессе такой вот детализации можно что-то сделать и по-другому, но это не принципиально. Важным является вопрос о том, как теперь все это ляжет на технологическую схему или технологический процесс проекта ввода сайта данного конкретного Владельца в соцсети. То есть обретет вид конкретных документов технического характера, образующих проектную документацию.
Сделаем еще два замечания. Первое касается №9: искренность (корпоративная ценность) здесь рассматривается как технологический инструмент завоевания доверия, что кажется очень интересным само по себе. И второе замечание по №№11 и 13 – заслон рекламе и ожиданиям немедленного и массового прихода людей из соцсетей прямо… ну, если и не в магазины Владельца, так уж на сайт – это точно. Названные для краткости 'стоп' они не предполагают полного отказа от такого рода ожиданий. Только от требования немедленной результативности соцсети в качестве придатка, продвигающего сайт по уже ставшей привычной сателлитной схеме.
3 Технологический процесс
Итак, что же получится, если зафиксировать наши требования в некоторых документах технического характера и включить их в процесс разработки? Наверное, примерно так:
4 Главный вопрос
Но как донести до Владельца, что такого рода навороты – практически обязательны. Что все это действительно нужно делать, если требуется реальный результат, а не имитация 'выхода в соцсети'. Как доказать, что любой проект требует для его успешного завершения использования определенной осознанно зафиксированной технологии выполнения работ. Что качество разработки, если только оно подразумевается, не может само по себе взяться из воздуха, без заботливого к себе отношения, без скрупулезного взращивания на всех этапах выполнения работ.
И если все эти вопросы не решать для себя (хотя бы зафиксировать для начала), то проект как судно 'без руля и без ветрил' поболтается-поболтается некоторое время, да и замрет неподвижным памятником хорошим намерениям разработчиков, не подкрепленным адекватной технологией разработки. Сколько их на просторах Сети. Но почему же так происходит?
В самом общем виде ответ может выглядеть следующим образом: Владельцу и (или) нанятому им персоналу не хватает знаний, опыта, понимания того, что важно или критично для успеха, а что второстепенно. А теперь давайте попробуем конкретизировать, а каких же именно знаний не хватает, какого понимания? Ведь это все - компетенции, если их не найти, не определить поточнее их дефицит, то и новые проекты пойдут под тот же откос. А если найти, то тогда можно нацелить персонал соответствующим образом, подготовиться получше и достичь результата. Что именно заказчик и его персонал (каждый, естественно, в той мере, которая присуща для его роли в общей схеме) должны освоить?
Для большей убедительности ответа вспомним, как раскручивалась спираль компетенций персонала, занятого в этой сфере, по мере развития сетевых технологий. При этом отметим, что переход к следующей фазе, как правило, не отменяет требования наличия полной или частичной компетенции предыдущего уровня.
Но если уж мы вспомнили об агентах по продажам, то не кажется ли вам, что текущая ситуация с соцсетями напоминает то, что в 90-е годы происходило с освоением бизнесом теории продаж? Сначала все это было совершенно неясно, потом появились книжки Деревицкого, которые ценились на вес золота. А потом пошел вал публикаций, растолковавших все вдоль и поперек. Так будет, по-видимому, и с работой в соцсетях. Хотя, нужно признать, продажи - это просто один из производственных процессов, выход в соцсети - это смена образа жизни или философии ведения бизнеса. По-крайней мере, в какой-то его части. И теперь настало время вернуться к нашей схеме техпроцесса, но уже на новом уровне.
Откуда она, собственно, взялась, эта схема? Мы просто распространили опыт разработки программного обеспечения, его технологический аппарат или инструментарий на новую сферу. Можно назвать это оболочкой или скелетом, но это в любом случае нечто вроде рамки без содержательного наполнения. Т.е. наличие 'технологического скелета' - необходимое, но отнюдь не достаточное условие. Это мехи, но чем их наполнить по смыслу? Именно тем, что должен дать блок ПССП. Наверное, в каждом конкретном случае это будет что-то новое, наиболее адекватно отвечающее видению Владельца. Вряд ли стоит фантазировать – нужно просто в каждом конкретном случае переводить общий смысл сведений, приведенных в литературе, на язык конкретных требований данного проекта и фиксировать их в тех технических документах, о которых шла речь выше.
5 Выводы
Итак, к 13 рекомендациям от Наталии Прытковой добавим еще две:
- Применять некоторую более-менее документированную технологию разработки.
- И обращать внимание на блок ПССП при подготовке персонала. Но не только персонала. Если Владелец выступает в качестве руководителя проекта – ему тоже нужно вникать. Между прочим и по наитию не проходит.
Хорошая статься. Несколько технологизированная и из-за этого сложна для меня лично, как для гуманитария. В общем и целом суть верна. Я очень рада, что мои статьи подталкивают людей к размышлениям и дополнениям - это приятно.
Личное пожелание, Вадим, пишите короче и конкретнее)) Иначе большая часть потенциальных читателей закроет статью даже не начав читать)
Добрый вечер всем, Наталье спасибо за отклик - и еще раз - за хороший начальный материал, там где 13 советов.
Насчет сложности согласен, на этом и горю постоянно, не могу убедить Заказчиков. То есть, они, конечно, вежливо кивают, да, да, именно так, но когда доходит до реализации - тут туго. Но я об этом и написал.
Рассчитываю на коллег, наиболее - на тех, кто сам писал коды, выпускал техдокументацию, т.е. был программистом или аналитиком в более-менее сложных проектах, там, где без этого невозможно. Будем ждать.
С уважением В.Петриченко