Про корпоративный Knowledge Base и яичницу

June 14, 2016 - 6 minute read -
ru notech education

Немного предыстории. Существовал такой себе ресторанчик. Совсем небольшой - человек 15. Готовили фастфуд годный и полезный. Дело шло хорошо, подтягивались новые клиенты, набирались новые поварята. Спустя пару лет - совсем неожиданно вырос бизнес, всяких разных ресторанов открыли немерено. И оказалось, что почти все поварята в каждом ресторане готовят одинаково-разный стафф - всякие там гамбургеры хитровыдуманные, салатики разномастные, да только все равно из мяса и овощей. И каждый новый повареныш на кухне спотыкается на одни и те же грабли - те самые, на которые уже наступил каждый шеф-повар. То картофель фри недосолит, то котлету не знает когда с гриля снять, чтобы прожарка без кровушки получилась. Собрались такие значит повареныши и стали думать, как бы это самим себе помочь со своими проблемами. И придумали решение - Корпоративная База Рецептов.

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

Когда все меню описали, оказалось что 20 рецептов только получилось. Опять сели администраторы думу думать - бюджетов-то аж на 100 штук попилили, где еще 80 взять? Что-то там поварята намудрили, раз так мало получилось, помочь им надо. Начали с яичницы.

SEC Fall

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

  1. Возьмите яйцо в доминантную руку
  2. Держите его между большим пальцем и первыми двумя пальцами
  3. Решительно ударьте яйцо животом о твердую поверхность
  4. Откройте половинки яйца
  5. Слейте яйцо в миску или кастрюлю
  6. Готово

Неплохо, подумали администраторы. Только все равно мало. Такая серьезная тема ведь, а всего два рецепта получилось. Рецептов мало, значит поваренышам мало пользы будет и себе бонусов. Кстати, ведь тут совершенно не раскрыта тема плиты - как сковородку-то накалить? Это ведь вообще для каждого блюда нужно, значит, опять же, рецепт популярным станет. Поварята в ответ: “Так это в инструкции к плите описано, да и плиты в каждом ресторане разные”.

- “Да что эти инструкции, главное ведь - опыт! Его-то и нужно описать. А раз плиты разные, значит и подходы разные. Т.е. просто для каждой плиты отдельный рецепт нужен”

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

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

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


О чем весь этот абсурд?

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

А теперь наш кейс реализации. Менеджерами было принято решение - нам нужно 100-150 крутых “рецептов”, а там дальше посмотрим. Откуда родились эти цифры? Видимо, маленькие менеджеры выбивали у больших менеджеров бюджеты, хитро обосновывая, что именно 100 статей помогут инженерам решать большие задачи быстро и эффективно. Появляется другой вопрос - откуда (практически одномоментно) родить столько крутых технических решений? Крутые решения на то и крутые, что их немного и они должны быть уникальными. Видимо, до сотки придется просто добивать hello world’ми. Но даже их может оказаться недостаточно. Что делать? Правильно - добавить топики о том, как разбивать яйца. Итак, проблема №1 - директивное формирование скоупа - т.е., по сути, контента базы знаний. Просто потому, что столько “продали”. Отсюда сразу же вытекает проблема №2 - отсутствие качественного контента. Примеры из жизни - “Как написать первый тест с помощью XXX”, “Как собрать проект с помощью XXX”. Детский сад. Эти темы - основа базового курса учебной лабаратории. По сути, мы просто берем главы из официальной документации различных инструментов и путем нехитрого ctrl-c-ctrl-v создаем нашу “базу знаний”. Как следствие - проблема №3 - отсутствие грамотных контрибьюторов. Почему? Потому что ни один вменяемый человек не станет тратить свое время на копипаст. Техническая публика не оценит, остальным это не нужно. Человек, у которого есть крутые идеи в голове, не захочет класть их туда, где лежит один мусор. Кстати, о мусоре: проблема №4. Спрос на такую базу знаний можно будет сформировать только директивно. Или вы думаете, что корпоративная вики действительно будет круче чем google? Ну и напоследок, проблема №5 - белорусы слишком толерантныемы молчим. Разговаривал недавно с одним из тех, кто пишет статьи для базы знаний, задал вопрос - нравится ли ему самому структура тем. Парень ответил, что, конечно, он бы все сделал по-другому. Т.е. человека “попросили”, он сделал работу, но вообще-то он не считает ее качественной. Так а чего молчал-то?

В общем, одни проблемы, что же делать? Решение, на мой взгляд, достаточно очевидное - полностью поменять отношение к такого рода инициативам. Я не зря применяю тут два термина - Knowledge Base и Knowledge Sharing. Мне кажется, попытки “скопипастить интернет” - тупиковый путь. Это никому не нужно, это все есть в гугле.

Что действительно нужно делать, так это работать над культурой шаринга знаний. Различные конференции, мини встречи, блоги - что-то более живое, чем эти ваши сухие документики. Как насчет купить Github Enterprise (или просто задеплоить обычный веб-сервер для статического контента) и сделать его площадкой для внутренних блогов (gh-pages + jekyll). Пускай постит каждый кто хочет и что хочет. А чтобы мотивировать людей - раз в квартал дарить лучшему блоггеру айпад. И не говорите, что это дорого. Давайте посчитаем. Прямо в айпадах. Директивное управление требует наличия менеджера проекта. Месячная заработная плата ПМа любого проекта (включая ПМа нашей текущей базы знаний) - это 5 айпадов как минимум. Если убрать “управление” и уйти в блогосферу, то ПМа можно отпустить на другой проект заниматься чем-то действительно важным. А на его место посадить любого HRа, который будет заниматься организационной работой (те самые встречи, кофе брейки, рассылки и т.д). ЗП HRa - уже два-три айпада, т.е. за один месяц у нас уже как минимум два айпада, которые можно раздарить. Два в месяц, Карл!

Далее. Ввести какую-нибудь хитрую рейтинговую систему (топ блоггеров) и разбавить все это дело ежемесячными живыми обсуждениями публикаций и еженедельными рассылками самых интересных статей. Т.е. опять же добавить какой-то живой динамики. И будет успех. И главное - будет польза. Потому что когда люди начнут контрибьютать то, что они сами считают интересным - уровень качества контента повысится в разы. Между “делать, потому что это круто” и “делать, чтобы это было” – пропасть. Первое – это инициатива, второе – это совок.

Итак, подытожим. 5 простых правил построения корпоративной базы знаний:

  • Выбросить правило “нам нужно сто”. Завернуть его в упаковочку с бантиком и занести на ближайший государственный завод.
  • Ввести ограничение - “если я могу нагуглить это за 5 минут, значит тема не подходит”. Контент должен содержать опыт и best practices. А не копипаст документации.
  • Максимально развивать культуру шаринга знаний в целом. Конференции, кофе-брейки, живые обсуждалки в помощь.
  • Ввести рейтинговую систему и награждать ништяками тех, кто генерирует качественный контент. Постоянно подкармливать энтузиастов.
  • Сделать удобный поиск или просто страницу визитку, сгруппировав статьи по категориям для удобной навигации.

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