Привет, Хабр!

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

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

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

Кому? Зачем?

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

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

Wiki выполняет несколько функций: 

• сокращает время обучения новых сотрудников;

• повышает квалификацию персонала;

• поддерживает квалификацию на должном уровне;

• создает стандарты качества работы;

• сокращает время на решение задач за счет регламентов и шаблонов.

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

Типичные «болезни роста» wiki

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

• несколько документов по одной теме или ситуации могли лежать в разных разделах и называться по-разному;

• название документа не всегда отражало его суть;

• поиск по базе знаний работал недостаточно хорошо;

• не было системы тегов, чтобы быстро искать необходимое;

• визуальное оформление чаще всего мешало ориентироваться в базе;

• некоторые данные дублировались, и поэтому было сложно определить актуальную версию.

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

Выделили проблемы

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

• пользователи не знают, что контент wiki можно кастомизировать под себя, а отдельные статьи добавлять в избранное;

• пользователям удобнее искать информацию через поиск, а не через меню;

• пользователям не хватает контента базы для решения их повседневных задач.

Провели опрос сотрудников

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

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

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

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

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

• по частоте использования базы;

• по регулярности использования;

• по тому, в каких ситуациях коллеги ей пользуются;

• по тому, какие задачи они с помощью нее решают.

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

Создали бэклог доработок

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

• статью о том, как адаптировать базу знаний для своих задач;

• roadmap для новых сотрудников;

• информацию по компетенциям сотрудников;

• обучающие материалы.

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

Переработали структуру wiki

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

• часть разделов  wiki касалась всех сотрудников, а часть — только конкретных отделов;

• какие-то разделы были нужны один-два раза в год или реже, а какие-то — несколько раз в неделю;

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

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

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

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

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

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

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

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

Почти готово, что дальше?

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

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

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

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

Внедрили доработки

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

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

Что мы получили в итоге

• доля тех, кто заходит в базу знаний несколько раз в неделю, выросла с 22% до 40% — это значит, что база знаний стала полезнее для решения повседневных задач;

• доля тех, кто не мог найти необходимую информацию, снизилась с 19% до 10%;

• доля тех, кто оценил удобство базы знаний как «удобно» и «очень удобно», выросла с 53% до 84%.

Заключение

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

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

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

1. продумайте структуру базы: она должна быть прозрачной и интуитивно понятной;

2. не перебарщивайте с контентом: его должно быть легко осмыслить и разобрать;

3. интересуйтесь мнением новых сотрудников о базе — у них самый свежий взгляд;

4. не бойтесь вкладывать ресурсы в улучшение базы знаний — они окупятся;

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