Не делать работу дважды

30 сентября на конференции DevOps Live прозвучал доклад «Активация обмена знаниями» об обмене опытом и том, как бороться с двойной работой. Под катом — доклад в текстовом виде, обогащённый некоторыми деталями, и видео с докладом.

Почему мы вообще говорим об обмене знаниями?

Разберём ситуацию, которая, возможно, знакома вам. В некой команде Мария сталкивается с непростой задачей. Мария — ответственный и дотошный человек, она разбирается в новой для себя (и для большинства сотрудников в команде) темой и обретает новые знания:

И, то ли она слишком устала, то ли не придала значение сделанному исследованию — знания свои она толком не распространила. И вот, через несколько дней Виссарион принимается за свою задачу:

И, конечно же, ему пришлось всё изучать с нуля. К Марии он не сходил, наставничества и подсказок не получил, а во многом так и не разобрался, ограничившись гуглением и копированием кусков со StackOverflow.

Обмен знаниями — он вот об этом. О том, что мы помногу раз изобретаем колесо и неразумно тратим концентрацию и время:

• Два раза думаем одно и то же;

• Два раза делаем одно и то же.

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

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

• Два раза думаем одно и то же;

• Два раза делаем одно и то же;

• Выстраиваем дублирующие процессы.

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

Надо ли что-то активировать?

Следующий вопрос, которым мы можем задаться: а надо ли что-то менять? Ведь может быть, что описанная ситуация — неизбежна, её надо понять и простить, потому что:

• Не дорого ли? Может быть улучшение ситуации будет для нас слишком дорогим, и игра не стоит свеч?

• Не станет ли хуже? Или может быть мы попытаемся увеличить интенсивность обмена знаниями, и из-за этого нам станет хуже?

• А разве его нет? Ну и, в конце-концов, кто сказал, что у нас нет обмена знаниями? Может у нас и так всё отлично?

Разберём каждый из вопросов подробнее.

Давайте познакомимся с ещё одним персонажем нашей команды. Это Коля. Он очень сильный технарь, с огромным опытом. Коля работает в компании практически с основания и на очень хорошем счету у руководства. И Коля страшно не любит прерывания, а также все встречи и разговоры, которые ему не сразу понятны:

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

А разве обмена знаниями ещё нет?

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

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

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

Похоже, что-то идёт не так, если:

• Сотрудникам некогда делиться открытиями.

• У них нет навыков писать и выступать.

• Нет навыков структурирования опыта.

• Когда у людей есть вопросы, но сомнение, что этот вопрос можно задать.

• Глючит софт для коммуникации и обмена знаниями.

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

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

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

Мы будем рассматривать обмен знаниями как процесс из условных 6 шагов и разберёмся с подводными камнями.

6 шагов обмена знаниями

Вернёмся к нашей героине Марии. Она узнала много новых понятий и загрузила это себе в голову. В какой-то момент у неё всё это сложилось в голове, и она поняла картинку целиком — со всеми взаимосвязями и понятиями. И в этот момент она (сознательно или нет) принимает важное для нас решение: стоит ли делиться полученным опытом? Является ли он чем-то интересным для коллег, или всё это банально и уже не новость?

Допустим, Мария решает, что надо поделиться. Тогда перед ней встаёт большой и сложный выбор:

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

Допустим, Мария хорошо знает, какой канал коммуникации выбрать и даже ориентируется внутри этого канала коммуникации (т.е. может выбрать правильный канал в слаке, правильный репозиторий спейс и страницу в Confluence и т.п.). Тогда перед Марией возникает огромная проблема: как оформить свои знания, как их упаковать в какой-то формат?

Это вообще огромная проблема для многих технарей: как упаковать, оформить свои мысли в виде текста или даже сформулировать в виде связного, понятного стороннему человеку, рассказа. Формулировка своих мыслей вообще сложная задача, а для специалиста, сфокусированного на своей профессии и своих задачах — тем более. Очень часто именно эта задача является фатальной в обмене знаниями, и есть способы её сильно упростить. Но поговорим об этом позже.

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

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

Окей, допустим Мария умеет выбрать правильных людей (хотя будем объективны — это нетривиальная задача, и у Марии должен быть очень широкий кругозор, чтобы принимать решение самостоятельно!). Но процесс обмена знаниями на этом не заканчивается, ведь спустя некоторое время Виссариону приходит его задача:

И в этот момент должна произойти магия: Виссарион должен суметь вспомнить, что кто-то что-то полезное рассказывал про хранилища. А в идеале — восстановить в памяти конкретного человека или место хранения записей. Кстати, в значительной мере именно из-за этой проблемы проваливаются попытки внедрения Wiki во многих командах разработки. Итак, что сделать, чтобы люди могли вспомнить о нужных знаниях в нужный момент?

Почему мы вообще заговорили об этих шагах?

Дело в кривой сложности. Если она слишком сильно задрана вверх, вы не сможете запустить обмен знаниями, как ни старайтесь. Какими карами ни грозите, какие плюшки ни обещайте, никто не дойдёт до конца процесса:

В этом докладе мы разберём первые три шага в обмене знаниями. Те, кому интересен комплексный подход, могут обратиться к автору в личку.

Шаг 1. Принятие решения: надо ли делиться знаниями?

Кейс 1.1: «Я что-то потыкала, и оно заработало»

Почему Мария может считать, что она толком не разобралась?

• Возможно в компании нет культуры исследования. Все работают «как на галере» или «как на конвейере». Изменение подобной культуры — отдельная, сложная тема, выходящая за рамки этого повествования.

• Возможно Мария не умеет обобщать опыт — «видеть лес за деревьями». Как выясняется, умение обобщать опыт — это глубинный навык. И бывают прекрасные, умнейшие люди, не обладающие этим навыком. Их нужно или учить, или не строить на их счёт слишком больших ожиданий.

• Возможно, дело в рассинхронизации ожиданий: чем стоит делиться, а чем — нет. И это большая сложная тема, в которую лучше погрузиться отдельно.

Рассинхронизация ожиданий важна тем, что она тесно связана с вопросом экспертизы. У разных людей уровень экспертизы разный. А значит мы можем стать свидетелем примерно такой ситуации между новичком и экспертом:

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

Соглашение о важности обмена знаниями нужно проговаривать в начале мероприятий/обсуждений, и, возможно, отдельно — со значимыми людьми и экспертами. Чтобы люди общались и синхронизировали свои представления, их полезно вовлекать в обсуждение, какие знания оказались полезными. Сделать такое в Slack-коммуникациях поможет, например, https://karmabot.chat/

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

Кейс 1.2: «Я ничего серьёзного не узнала, это всё мелочи»

Почему Мария может обесценивать полученные знания?

• Из-за рассинхронизации ожиданий. Её мы разбирали ранее.

• Из-за неумения обобщать опыт. Аналогично.

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

Кейс 1.3: «Это всё никому не нужно!»

Явная агрессия и сопротивление? Возможно это призраки прошлого, некоего агрессивного эксперта-Коли.

Преодолеть страхи сотрудникам поможет дружественная обстановка и соглашения о важности обмена знаниями.

А может быть дело не в прошлом, а в банальной лени. Чтобы побороть её, полезно встроить обмен знаниями в Definition Of Done задач. То есть задача не должна быть закрыта, пока не написана дока/не рассказано, о каких-то важных моментах/не донесена информация до пользователей. Важно: мы говорим «задача не закрыта», а не «запрещён выкат на продакшн». Разумеется, процесс обмена знаниями не имеет право влиять на время доставки кода до продакшна. Однако, пока задача не закрыта, мы не имеем права брать новую.

Конечно, внедрение WIP-лимитов, Definition of Done и прочих соглашений — трудоёмкий процесс. Полезно, когда есть выделенный человек, менеджер знаний, который может провести эти изменения.

Кейс 1.4: В этот раз действительно нет смысла делиться знаниями

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

Шаг 2. Как понять, куда шарить?

Каналов коммуникации множество. А какие они бывают по своей сути, есть ли там какие-то закономерности, которые нужно учитывать, выстраивая обмен знаниями?

• Бывают ленты. Яркий пример — лента Facebook. Она бесконечна, и старые посты никто и никогда не перечитывает — и это нормально. Люди подписываются на нужные им источники информации и составляют свой личный фид.

• Бывают хранилища. Вот эти все Jira, Confluence, Git с markdown, Google Drive и прочие. Их особенность в том, что вы сами организуете структуру хранения данных. И в итоге для стороннего человека всё реально очень сложно.

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

• Бывают люди. Непосредственная коммуникация голосом, при всех её минусах (мощное прерывание, крайняя медлительность и необходимость повторять это снова и снова для новых людей), обладает одним ОГРОМНЫМ плюсом. Только непосредственная коммуникация даёт мгновенную и очень глубокую обратную связь.

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

Шаг 3. Упаковка знаний

Для разных каналов коммуникации знания нужно упаковывать по-разному. Вот, например, мессенджеры. Их особенность в том, что во множестве сообщений, крайне маленький объём действительно важной информации. Выловить эти крупицы золота в море руды — крайне нетривиальная задача:

И это действительно большая проблема, для которой я не знаю нормального решения. Единственный способ исправлять ситуацию — подать коллегам пример правильного поведения и надеяться, что они переймут практики. Например:

• Написания резюме к обсуждениям: комментариев к ссылкам, афтермитингов, выжимку к тредам с вопросом. Причём резюме — это не обязательно именно текст, некоторые мессенджеры позволяют проставить emoji/отметки на сообщениях, содержащих что-то ценное.

• Кстати, я тут должен разрекламировать ребят из https://onebar.io/ — они пытаются решить эту проблему с помощью NLP и уже добились интересных результатов.

• Писать слова-синонимы для поискового движка. Ни один поисковик не знает вашего сленга ("куб", "кубик", "kubernetes"), а многие системы даже с русской морфологией плохо дружат. А значит, поисковому движку надо помочь, прописав синонимичный ряд отдельным сообщением в стиле интернета 90-х ("Заходит как-то SEOшник в бар, ресторан, купить алкогольные напитки, клубы, лучшие бары в Москве, заказать банкет в ресторане")

• Писать дайджесты. Очень хорошая практика — раз в пару недель/месяц писать обзор интересных постов/обсуждений, которые были за это время. Круто экономит время и позволяет выживать в потоке множества подписок.

Как быть с обилием мессенджеров? Конечно, делить по каналам. Каналы можно дробить сколько угодно (по темам, по уровню прерываний — нужна ли немедленная реакция на пост или нет, по обязательности прочтения и т.п.). Ведь люди составляют свой личный фид, пусть они имеют возможность выбирать!

Но кроме мессенджеров есть ещё вики/трекеры — сложные, запутанные штуки, которые для новичков выглядят вот так:

То есть страшно даже не то, что это лабиринт, а то, что новичок даже представить себе не может, насколько он запутан. А значит — нужно онбордить. Учить ориентироваться, обучать процессам, частью которых является фиксация знаний, учить вносить изменения и дополнять. И крайне важно уменьшать сложность работы с вашим хранилищем знаний, то есть:

• Использовать шаблоны. Заполнить несколько полей гораздо проще, чем с нуля писать рассказ в трёх частях с неожиданной развязкой. Создать шаблон сложно, но ещё сложнее — внедрить этот шаблон. Неправильно разработанные шаблоны заполняются кое-как и саботируются, а в корне этого — непонимание, либо плохая связь шаблона с реальностью вокруг.

• Использовать парное программирование. Садиться и оформлять мысли вместе и попутно учить необходимым навыкам.

• Обратиться к техническим писателям, если они у вас есть. Эти замечательные люди, если перестать их воспринимать как "писателей отчётности", могут здорово прокачать команду и разработчиков.

А ещё есть корпоративные блоги и конференции. Их множество, ориентированных на разную аудиторию.

И это самый простой путь, так как существует целая индустрия:

• Аутсорс, который может подготовить оформить выступление или статью, или вовсе сделать что-то за вас.

• Доклады о том, как правильно писать, выступать и выстраивать процессы вокруг этого.

• Учебники всех видов и размеров.

Вы можете просто обменять деньги на результат, и это восхитительно.

Шаги 4-6 

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

Видео доклада:

Полезные ссылки:

• Интересен комплексный подход? Давайте пообщаемся.

• Выстраиваешь процессы, связанные с обменом знаниями? Добро пожаловать в Прагматичный Гайд.

• Больше восхитительных историй? Телеграм-канал автора.

Автор: Цупко Игорь

Источник