База знаний wiki сохранит внутренние документы компании — как сделать ее удобной для пользования

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

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

Решением этой проблемы стали корпоративные базы знаний — wiki. И ей, например, активно пользуются в компании AGIMA.

AGIMA уже 15 лет занимается интеграцией digital-решений: мы помогаем огромному числу клиентов создавать удобные сайты, приложения, сервисы и прочие digital-продукты. Сейчас нас больше 200 человек, и еще столько же наших партнеров и подрядчиков, а за все годы работы мы успели посотрудничать с тысячами разных людей. Так что у компании богатая история и богатая корпоративная жизнь.

За 15 лет в компании накопилось достаточно внутренних документов, которые нельзя потерять: это регламенты, правила, чек-листы, стандарты и т.п. Хранить их в целости и сохранности нам, как и многим другим компаниям, помогает собственная база знаний — wiki.

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

Мы придерживаемся Data Driven-подхода, поэтому для наших заказчиков мы начинаем работы с анализа данных, а это значит, что и в этом случае мы поступили также — провели исследование среди 200 сотрудников. Вот какие проблемы мы нашли:

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

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

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

Чтобы разобраться, через Google Forms мы запустили опрос среди коллег. Важно было отправить ссылку на опрос конкретной группе, настроить уровни доступа и получить результаты проведенного опроса и в виде таблиц, и в виде графиков.

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

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

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

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

Уже на этапе опроса мы получили бэклог доработок, а также приоритизировали проблемы по частоте и критичности. Часть пунктов из бэклога можно было внедрить сразу, без дополнительных исследований. Так мы и сделали. Добавили:

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

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

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

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

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

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

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

Здесь столкнулись со второй сложностью: карточек было слишком много. Если бы мы делали по одной карточке на статью, то количество карточек, который каждый пользователь должен рассортировать, превышало бы 300 штук. Это слишком много. Чтобы снизить когнитивную нагрузку на пользователей, нам пришлось искусственно сократить количество карт для каждого сегмента до 100–120 штук.

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

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

Когда мы набрали необходимое количество ответов для каждого сегмента, перешли к обработке результатов. Около 15% карточек пользователи отнесли к одним и тем же категориям почти единогласно. Даже названия категориям дали почти одинаковые. Еще примерно 40% карточек чаще всего помещались в одну и ту же или две смежные категории: например, «Обучение» или «Полезные материалы». Довольно много карточек попало в папку «Не знаю, что это» или «Не пользуюсь».

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

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

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

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

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

Работа над wiki позволила нам не только экономить время и ресурсы, но и повысила лояльности коллег. А еще это был бесценный опыт: исследование «своих» дало нам возможность получить от пользователей гораздо более подробный фидбэк, чем обычно.

А в завершение дадим пять простых советов, как сделать базу знаний полезной и удобной: