Лучшие друзья руководителей – база знаний и документация

В этой статье мы поговорим о том, почему документация важна для руководителя. Что происходит с сотрудниками вашего отдела, если у вас ее нет? Как это сказывается на работе отдела? Рассмотрим несколько конкретных ситуаций, где это особенно заметно. Попробуем примерно посчитать потерянное время, которое вы тратите на постоянные объяснения при отсутствии документации. В конце затронем тему базы знаний.

Проблемы отсутствия единого понимания процессов

Типичные проблемы, которые возникают, если у вас отсутствует документация по процессам:

• Не получаем ожидаемого результата,

• Отвечаем на одни и те же вопросы,

• Каждому новому сотруднику рассказываем, как все устроено,

• На вопросы о процессах отвечаем лично и не всегда одинаково,

• Отсутствующие сотрудники не получают информацию,

• Сотрудники ожидают ответов, работа стоит.

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

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

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

Последствия отсутствия ясных правил и приоритетов

Что происходит с отделом:

• У всех разное представление работы с процессами,

• Нет понимания, к какому результату должны прийти,

• Нет понимания важности и критичности процессов,

• Нет понимания, как действовать в различных ситуациях,

• Нет понимания, к кому и куда обращаться с вопросами,

• Нервозность, раздражение, потеря мотивации.

Если ваши сотрудники не понимают, какие процессы критичны и какие задачи нужно решать в первую очередь, они без вашего участия не смогут действовать самостоятельно. Пропишите для них приоритеты: объясните, что если приходит Мария Ивановна и просит о помощи – это первый приоритет, и нужно все отложить.

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

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

Правило: вопрос, заданный более двух раз, требует документации

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

Пример 1: отпуска, дежурства и отсутствие сотрудников

Первый пример – про отпуска, дежурства и отсутствие сотрудников. Это различные day off, выходные, болезни и другие случаи отсутствия.

Проблемы:

• Не знаем, кто из отдела сейчас вообще работает,

• Об отпуске или отсутствии сотрудника узнают в тот момент, когда им понадобился этот сотрудник,

• Не планируются работы, задачи могут простаивать,

• Пересечения отсутствий сотрудников.

Если у вас не описано, как и в каком виде все это должно фиксироваться, то вы не знаете, кто и когда из отдела работает. Да, если у вас команда из двух, трех, максимум четырех человек, это легко контролировать: если кто-то ушел, вы это сразу замечаете. Но если в отделе 10–20 человек, вы можете просто не заметить, что кто-то отсутствует – вы ведь постоянно находитесь в потоке других задач.

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

Что с этим делать? Напишите простую документацию – хотя бы шаблон, как все это должно фиксироваться. Это не единственный вариант, просто пример того, как может быть организовано.

Так как мы ведем это в Confluence, там удобно создать календарь и отмечать все прямо в нем.

Это может выглядеть, например, так: на 11–13 число видно, что Андрей все еще отдыхает, Ольга только начала отпуск, Виталий в это время дежурит, а Илья взял отгулы.

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

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

Пример 2: структура рабочего дня сотрудника

Далее перейдем к теме рабочего дня сотрудника. Проблемы:

• Сотрудники не знают, чем они вообще должны заниматься,

• Не имеют инструментов для решения проблем,

• Не знают, чего нельзя делать.

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

Если вы не даете инструментов для решения возникающих проблем, сотрудники просто сидят и ждут. Хорошо, если они придут и спросят, что делать, но многие этого не делают – просто ждут. Проходит время, вы приходите и спрашиваете: «Почему задача не готова?» А в ответ слышите: «У меня возникла проблема, я ждал», и начинаются разборки.

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

На разбор подобных ситуаций уходит минимум два часа в неделю, а пока все это происходит – работа стоит.

Несколько примеров:

• Сотруднику написали взять задачу в работу – он взял, но столкнулся с проблемой. Что делать? Писать вам? Ведущему специалисту? Поставить задачу на паузу? Непонятно.

• Или наоборот: сотрудник взял задачу, выполнил ее – а что дальше? Достаточно ли просто сменить статус задачи на «выполнено»? Может быть, он должен написать документацию, сообщить об этом кому-то или взаимодействовать с другими отделами? Если вы не прописали эти шаги, а просто объяснили их в первый день, через пару дней сотрудник об этом забудет, а вы будете ожидать, что он все помнит и выполняет.

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

Пример 3: часто возникающие вопросы

Проблемы:

• Есть вопросы, которые стабильно задаются несколько раз в неделю/месяц,

• Ответы на эти вопросы забываются или оседают в личных сообщениях,

• Если что-то изменилось, то эту информацию негде посмотреть,

• Непонятно, как коммуницировать с другими отделами,

• Нет понимания, как действовать при возникновении проблем,

• Проблемы или ошибки, с которыми ваш отдел постоянно сталкивается.

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

Главное не просто написать статью, добавить ее в базу знаний и надеяться, что сотрудники сами ее найдут и все поймут. Это нужно превратить в процесс. Вы можете создать статью, уведомить сотрудников о ее существовании и объяснить: если у них появляются повторяющиеся вопросы, они могут сами зайти, отредактировать статью и добавить свой вопрос. Ваша задача – периодически просматривать статью, проверять, появились ли новые вопросы, и добавлять ответы.

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

Простой шаблон: указать, для чего предназначена статья, и оформить список вопросов и ответов.

Организация базы знаний

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

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

Место хранения и авторство документации

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

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

Зачем все это нужно? Чтобы повысить прозрачность процессов и доступность информации. Чтобы все сотрудники понимали, как устроена работа, и имели одинаковое представление об одних и тех же вещах.

Как это сделать? В двух словах не объяснишь, поэтому разберем подробнее.

Формат и упрощение

Начнем с формата.

• Информация первична. Если сейчас ничего нет, просто зафиксируйте ее в любом виде.

• Не важно, в каком сервисе или формате вы это сделаете. Не тратьте время на сложное оформление, таблицы, стили и цвета – все это потом усложнит перенос документации в другие системы.

• Упрощайте стиль. Чем проще стиль, тем легче будет мигрировать с этими материалами куда угодно.

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

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

Актуализация документации

Большая проблема – это актуализация базы знаний и понимание, кто за нее отвечает. Информация, добавленная в заметку, быстро устаревает. Что с этим делать?

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

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

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

«Просто напиши текст»

Возникает вопрос: как мотивировать сотрудников писать документацию?

Людей нужно не принуждать, а снять барьер. Часто сотрудники говорят: «Мы не можем написать документацию, она получится некрасивой, непонятной, без оформления, без ссылок». На это я всегда отвечаю: «Все это не важно. Просто напишите поток мыслей – как есть». Потом подправить текст и оформить гораздо проще, чем писать все с нуля.

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

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

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

Вовлечение сотрудников в использование базы знаний

Как мотивировать сотрудников писать документацию и пользоваться базой знаний?

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

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

Чтобы сотрудников не приходилось заставлять, показывайте и объясняйте пользу, зачем все это нужно и кто будет пользоваться документацией. Когда люди понимают смысл своей работы, в чем польза для бизнеса и клиентов, они начинают делать это самостоятельно – без давления и напоминаний.

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

Проблемы поиска и структуры

Теперь немного о проблемах, с которыми мы сталкиваемся, и о том, как их решаем.

Проблемы:

• Сложная структура,

• Долгий путь до конечной информации,

• Незнание, что информация есть в базе знаний,

• Не все читают документацию.

Первые три пункта здесь, по сути, об одном и том же, но с разных сторон.

• Страница отдела

  • Инфраструктура

    • Самокат

      • Мониторинг

        • Графана

          • Описание алертов

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

Поэтому важно найти баланс между сложностью структуры, где все разложено по полочкам, и удобством использования. Сейчас мы решаем это так: на странице отдела делаем разбивку на ключевые блоки. У статей расставлены теги, и в эти блоки статьи автоматически подтягиваются по тегам. Ключевые и часто используемые материалы, которые сотрудникам могут понадобиться в работе, выведены прямо на главную страницу. Благодаря этому им не нужно делать множество кликов – они просто открывают страницу, просматривают нужный раздел и сразу получают необходимую информацию.

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

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

Главное – узнавайте напрямую, а не пытайтесь додумывать за людей. Если вы будете строить систему, исходя только из собственных предположений, она никогда не станет удобной для всех.

Заключение

И напоследок – небольшая итоговая заметка.

• Документация действительно очень важна. Если вы думаете, что напишете ее потом – не напишете. Когда она понадобится, времени уже не будет: появятся срочные задачи, бизнес завалит критичными делами, и вы отложите это снова.

• Не заморачивайтесь над оформлением – информация первична. Сначала зафиксируйте ее, а привести в порядок сможете позже.

• Сделайте свои процессы простыми и понятными для всех, показывайте примеры и формируйте единые правила.

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

• Не тратьте время на постоянные объяснения – пишите инструкции.

И напоследок немного цифр: только по трем рассмотренным примерам за год вы потратите минимум 208 часов. Это очень примерная и заниженная оценка. Если в отделе 5–7 человек – смело умножайте на два или три. И это только ваше время. Еще столько же потратят сотрудники, пока будут ждать ответы.

Поэтому пишите документацию и не тратьте впустую ни свое, ни чужое время.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.