Корпоративные блоги

  kimrgrey   27.02.2017 18:19:58   0

У меня тут как-то так сложилось, что в течение последних двух месяцев я одновременно в нескольких компаниях наблюдаю за попытками основать своего рода корпоративную культуру. С некоторыми из этих компаний я связан напрямую, то бишь просто работаю в них, а с другими косвенно: работают друзья, или друзья друзей, или просто кто-то что-то мне рассказывает о них время от времени. Надо признать, наблюдение это довольно занимательное, хотя иногда и хочется вскочить со своего мягкого дивана, раскидав попкорн по комнате, и закричать: "Да что ж вы делаете-то? Да ну кто ж так делает...?", - потом, правда, отпускает :-) Под высоким словом "культура" я здесь подразумеваю не красивые слоганы с ценностями компании, а, скажем так, процесс и правила взаимодействия сотрудников между собой и с внешним миром. Сейчас объясню подробнее, что именно я имею в виду и почему вдруг решил об этом написать, запилив первый пост аж с ноября позапрошлого года.

Я cразу предупреждаю моего уважаемого въедливого читателя, что все ниже написанное - это просто мои умозаключения из увиденного и услышанного вокруг. Вообще говоря, тут стоит заметить, что моя профессиональная карьера сложилась так, что к этому дню мне удалось посмотреть изнутри и по-настоящему гигантские корпорации, и совсем маленькие, новорожденные конторки, и что-то среднее между ними. Не то, чтобы я из спортивного интереса это делал - просто карма такая. Так вот из этого опыта можно сделать простой вывод: в какой-то момент в абсолютно любой it-шной или около it-шной компании наступает кадровый и творческий кризис. Старые умники и умницы уходят, унося с собой и ответы на ключевые вопросы вида "почему получилось именно так, как есть сейчас", новые приходят с непостижимой скоростью ("мы растем на 200% в год", "каждый второй сотрудник работает у нас меньше полугода", etc), технические процессы стремительно катятся в ад, всем больно. Некоторые команды счастливо выруливают из этого состояния и потом пишут бодрые посты о том, как они все наладили, и рассказывают об этом на всех конференциях, другие же кризиса не переживают.

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

Технической компании - технический блог

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

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

Во-вторых, потому что профессиональный контент, как ни странно, не может написать непрофессионал, даже если у этого человека прекрасный слог и отличная подготовка в жанре "SEO, разработчики, нанимаем, высокие зарплаты, топовые технологии, cloud, machine learning, искусственный интеллект, кухня в офисе, без смс и регистрации" и вот этом всем. Чтобы впечатлить и заинтересовать девелопера, нужен контент. Нормальный, человеческий, интересный контент.

Оформление - это важно

Вторая ошибка в моем личном хит-параде - взять WordPress, натянуть на него тему в более или менее корпоративных цветах и запустить то, что в итоге получилось. Верстка, адаптивность, оформление, продуманные иллюстрации к постам - кому на фиг интересна вся эта визуальщина, правда? Беда в том, что блог компании, призванный привлекать внимание разработчиков, не может быть плохо сделан. Не может - и все тут. Вот этот блог, который вы сейчас читаете, сделан сравнительно так себе. Плохо сделан, прямо скажем. Но это потому что я пилил его 5 лет назад, по выходным и по вечерам и с целью поковыряться с новыми технологиями. Он не решает никакой иной задачи, поэтому ему и можно быть таким, каким он получился сам по себе. А официальному инженерному блогу технологической компании - нельзя.

Блог - это личное

Третье место по праву занимает отсутствие в блоге компании чего-то для нее специфичного, личного, живого. Если пост можно легко и свободно перенести с одного сайта на другой, а никто и не заметит разницы - на фиг такой пост нужен? Проблема эта касается и постов "ни о чем", и постов "ну так, о чем-то". Девять шагов к личной эффективности, семнадцать практик серверной производительности, девяносто одна поза для вдохновенного программирования - вся эта чушь в корпоративном блоге нечитаема, если в ней нет крутых примеров из практики конкретных людей в живой ситуации. Узнать, как Gitlab чинил свою базу, после того как невыспавшийся админ по ошибке дропнул папку с данными PostgreSQL на основном сервере вместо недонастроенной реплики - интересно. Ибо это про жизнь, а в жизни случается дерьмо. Слушать про то, как и почему Github перевозил API с REST на GraphQL - интересно. Потому что там есть примеры, как надо и как не надо. История должна быть любопытной, иначе зачем кому-то ее читать?

Блог - это игра "в долгую"

Четвертое место - отсутствие редакторской политики. Ну, или редактора как такового. То бишь человека, который отвечает за наполнение блога, понимающего что у него ушло на публикацию сегодня, что пойдет через неделю и какой пост допишется к 4 июля. Да, план публикаций должен быть и желательно более или менее равномерный. Нет, "как-нибудь" не получится. Ну, просто потому что поисковики так устроены, что охоты высоко ранжировать сайты, молчащие по несколько месяцев, у них нет. Да и люди запоминают место, где читают что-то интересное время от времени, а не два раза в год.

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

Контент - это все, что вы делаете

Это прямое следствие из наличия редактора. Если в компании проводятся всевозможные R&D Talks и Tech Discussions, если есть внутренняя презентация новых фич, если проводится митап для локального сообщества - все должно идти в блог. Пишите про код, пишите про то, как вы общаетесь, выкладывайте видео и фото. Естественно, это требует довольно высокого уровня разумной публичности. То есть, если на самом деле вы бьете своих сотрудников деревянной ложкой по голове за каждый баг, то спрятать сей факт не получится.

Кроме того, подумайте о том, что блог, в общем-то, вполне может делиться на публичный и внутренний. Если генеральный директор время от времени пишет письма всем сотрудникам компании с, например, рассказом про ключевые ценности компании или поздравляя всех с запуском чего-то нового и важного, то имеет смысл, согласитесь, опубликовать это во внутреннем блоге. Там же имеет смысл проводить внутренние дискуссии, типа "внедрять ли нам в стек Java" и "хорошим ли выбором является beego для микросервисов на Go". Если такие вещи идут оффлайном или письмами, то они исчезнут через минуту после завершения. Но если все получили email сегодня, а человек вышел на работу завтра - это же не значит, что ему не интересно и не нужно почитать, почему все так, как есть, и какие были аргументы, когда это решалось. Так ведь?

Вместо заключения

Ну, вот какие-то такие у меня об этом всем сложились впечатления... Причем если бы эти ошибки были каким-то разовым сценарием, то и ок: опыт, он, как известно, сын ошибок трудных. Но наблюдать одно и то же от компании к компании как-то скучно.

В общем, короче, чего ради я это все решил написать? Технические блоги - это отлично, это здорово и прекрасно. Но надо понимать, что уж если начинать писать, то с той позиции, что это такая же часть работы компании, как любая другая. Может быть, не жизненно важная, но это не повод лепить как придется. Вкус, стиль, честность, открытость, оригинальность - это все важные составляющие. Иначе лучше уж и не начинать. Я так считаю.

P.S. А, и еще. Не делайте, пожалуйста, доменным именем слово "engineering". Три раза уже видел. Нет, ну правда, не все ваши писатели и читатели native speaker-ы, а кто из не native speaker-ов с первого раза и с правильным количеством букв "i" и "e" напишет без ошибок слово"engineering", тот молодец и исключение. Я попробовал на своих друзьях - со скрипом. Возьмите "tech" - упростите жизнь тем, кто хочет ссылкой на вас поделиться по памяти :-)

Комментарии

Может быть, вы хотите оставить комментарий? Войдите на сайт или зарегистрируйтесь.