На чем сделать базу знаний

Как сделать Базу знаний своими руками

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

10 показов
5.6K открытий

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

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

Так что нужно сделать, чтобы запустить Базу знаний? Мы подготовили список этапов, как это сделать своими руками. На самом деле, в этом нет ничего сложного, поэтому — вперед!

1. Ищем платформу для размещения материалов

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

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

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

2. Строим систему

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

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

Представим ситуацию, что у новичка первый рабочий день, и он хочет знать, когда ему ожидать зарплату. Соответственно, первым делом он войдет в папку «О компании», затем в раздел «HR», после этого «Бухгалтерия», а в конце откроет раздел «Порядок начисления и выплат заработной платы». Как вы видите, новичок начинает с глобальных вопросов: «Где я?» — «Кто должен рассказать про зарплату?» — «Когда я ее получу и сколько конкретно?». Таким образом, новичок идет от общего к частному, постепенно отсекая ненужные варианты.

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

Как создать базу знаний, чтобы она стала «интеллектуальным активом» компании

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

В сентябре 2020 года я выступила спикером IV-й конференции «Управление корпоративными знаниями», проходившей в рамках недели корпоративного обучения. Мой мастер-класс «Как создать корпоративную базу знаний, чтобы она стала «интеллектуальным активом» компании» заинтересовал собравшихся, и я решила сделать из материалов выступления статью. Буду рада если текст поможет вам в работе. Буду рада, если кто-то из вас захочет в комментариях обсудить этот пост.

Источник

Универсального сценария «Как создать базу знаний», который бы подходил всем и всегда, нет и быть не может. Обусловлено это как разными подходами к организации баз, так и разными IT-инструментами. А вот общие требования, своеобразный cookbook, – как раз предмет моей статьи.

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

Написать понятно для всех

Текст статьи из базы знаний должен быть понятен всем, кто будет её читать. Притом понятен с первого прочтения, ибо скорее всего второй раз её читать просто не будут. Статья не должна быть слишком длинной или чрезмерно короткой. Материал должен быть изложен так, чтобы трактовки его содержания были однозначными, и не нужно было переводить с «бухгалтерского» или «IT-шного» на «человеческий».

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

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

На первый взгляд, кажется, что достичь этого невозможно: если статья написана для «чайника», то погруженному в тему она будет избыточной, а если ориентироваться на профи, то «чайнику» потребуется «перевод». Как быть?

Есть много инструментов, помогающих решить проблемы. В Департаменте корпоративных систем ЛАНИТ мы используем три подхода.

1. Ревью от ведущего эксперта предметной области. Процесс направлен на повышение качества материалов базы знаний (далее БЗ). Суть в том, что эксперт проверяет корректность изложения материала, в том числе логичность и последовательность изложения.

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

3. Структурирование. Этот инструмент условно можно разделить на два типа воздействий:

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

Всегда актуально

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

По сути, knowledge manager должен иметь свою систему мониторинга, в которой будут свои триггеры и четко описанные алгоритмы реагирования.

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

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

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

Пример статусной модели:

Как не создать информационную «мусорку» вместо базы знаний

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

Например, заголовок «Шаблоны заявлений» вполне корректен, но сформулирован узко. Искать будет легче, если добавить в него ключевые слова и написать так: «Шаблоны заявлений: отпуск, отгул, удаленная работа, увольнение, перевод».

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

Статьи, собранные по принципу Lego из констант и переменных, снижают затраты на базу знаний

Есть правило, к которому мы пришли не сразу, но которое значительно экономит время на поддержание актуальности базы знаний. Это правило – никакого дублирования! Информация фиксируется один раз, далее используются ссылки на нее. Технически есть масса возможностей «вживлять» константы в нужные места по тексту статьи так, чтобы читатель даже не знал о том, что статья как конструктор состоит из частей.

Почему «не летит»

Даже самая актуальная база знаний, содержащая ответы на все востребованные вопросы, может «не взлететь», если найти нужную информацию сложно.

Решить проблему поиска можно структурированием и многоуровневой классификацией. Причём классификация должна быть не только на уровне разделов каталога БЗ, но и с метками по разным тематикам (например, если у нас база знаний службы поддержки пользователей, то по темам, личным кабинетам и т.д.). Каждый пользователь может отобрать перечень статей по заданным критериям, используя форму расширенного поиска.

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

Мобильность — наше всё

Для мобильности и в силу популярности Telegram дополнительно развиваем чат-бота.

Бот реализован в Telegram и доступен с любого устройства пользователя. Уровень доступа к информации через бот соответствует уровню доступа к сервисам компании. По запросу ответ можно получить в том числе из wiki.

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

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

Как создать базу знаний

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

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

Что такое база знаний

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

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

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

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

6 шагов к созданию базы знаний

Рассказываем, как создать базу знаний:

1. Проведите ревизию документов, которые у вас уже есть. Возможно что-то нужно переписать более простым и понятным языком, обновить и добавить информацию. Какие-то документы убрать совсем, так как описываемых процессов в компании уже нет. Приведите всё порядок и оцифруйте, если документы хранятся на бумажных носителях.

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

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

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

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

1. Проверяйте знания. Это отлично, когда вы создали актуальную, живую и структурированную Базу знаний с примерами и ссылками, но сотрудники могут просто не читать эти документы. Они будут знать, что в той папке лежат скрипты, а в этой инструкция о том, как давать скидки клиентам, но они не будут ими пользоваться. Поэтому, неотъемлемой частью Базы знаний является проверка этих знаний. Просто внедрите тестирование сотрудников. Человек изучил документ, а потом прошёл по нему тест, тем самым подтвердив, что он усвоил материал и готов им пользоваться.

Где создавать

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

1. Google Документы и специализированные сервисы

Вы можете начать создавать регламенты в Google Документах. Это не самый удобный для этого вариант, но так у всех сотрудников хотя бы будет онлайн доступ к Базе знаний.

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

При выборе инструмента для создании базы знаний обращайте внимание на наличие таких возможностей:

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

• создание мини-тестов с проверочными вопросами. И выбор типа проверочных вопросов: вопрос с единичным выбором, множественным выбором, альтернативный, открытый;

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

Рассказали, как создать базу знаний в компании любым удобным для вас способом. Начинайте действовать и вы увидите, как увеличится эффективность работы в вашей компании.

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

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

Привет! Меня зовут Таня Дудо, я менеджер продуктовых знаний в Selectel. В тексте расскажу, как решили создать внутреннюю базу знаний о продуктах и процессах для 800+ человек. Опишу, как к этому пришли, кропотливо выуживали важную доку из массива данных и придумали инновационное решение — гиперспейсы. Спойлер: легко и просто не было, мемы и уроки из опыта — внутри.

Важное перед стартом

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

С чем можно сравнить работу по созданию внутренней БЗ? Разбор статей похож на добычу полезных ископаемых. Выуживание важных материалов из огромного массива данных — на промывание песка в поисках золота. Категоризация и обязательные артефакты похожи на составление карты путешествия. Работа с фидбеком — на западню, в которую тебя заманили добрые существа, а потом решили прикончить. А в конце… впрочем, до конца нам еще предстоит дойти.

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

Почему мы решили, что нам нужна единая база знаний

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

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

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

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

В какой-то момент тема актуальности передачи внутренних знаний «заболела»‎ и у нас в Selectel. Мы компания, которая помогает другим бизнесам строить свою IT-инфраструктуру, создает и развивает технологические решения. Работаем 14 лет на рынке, объединили в своей панели управления 40+ продуктов. Поэтому знаем, как создавать подробную и классную документацию для клиентов, но вот внутреннюю вели не всегда с такой педантичностью.

Чем больше становилась команда, тем важнее было наладить процессы в передаче знаний. И если внутри продуктовых команд и продуктового департамента регулярные синхроны помогали поддерживать обмен знаниями на приемлемом уровне, то сервисные команды — вроде ИТО (инженерно-технического отдела), техподдержки и продаж — закапывались в обилии и разнородности документации и не всегда могли быстро найти ответы на свои вопросы. А это напрямую влияло на скорость решения задач.

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

Что было дальше

Мы начали с масштабного анализа того, что уже есть в Confluence.

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

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

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

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

Первый вариант

Сломать все то, что есть сейчас. Перелопатить всю документацию, создать типовую структуру пространств и принудительно загнать в нее старые статьи.

Плюсы решения: сразу получаем понятную базу документации для читателей.

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

Складывать доку так, как привыкли, легче, чем по-новому. Структура недостаточно гибкая и «обхоженная»‎. Ресурсозатратность всех участников: максимальная.

Второй вариант

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

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

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

Третий вариант

Ничего не трогать.

Что такое гиперспейсы и как они работают

Структура

Гиперспейсы — страницы в Confluence с макросом «Содержимое по меткам»‎. «Какая же это база знаний, если это простая страница с макросом?»‎, — спросите вы. Все дело в структуре: мы создали три верхнеуровневые страницы с названием сервисной команды, которой предназначается база знаний. Под этой верхнеуровневой страницей команды есть по одной странице на каждый продукт. А уже внутри страницы продукта есть колонки-разделы, в которые складываются статьи определенного типа (и именно здесь работает макрос).
Например, путь к инструкции «Автоматизированное удаление подсетей и VLAN»‎ для техподдержки будет выглядеть так: пространство «Гиперспейс»‎ → страница «Для саппорта»‎ → страница «Выделенные серверы»‎ → колонка «Управление подсетями»‎.

Почему такую архитектуру называли «гиперспейсами»‎? Потому что совершенно не важно, в каком пространстве изначально опубликована документация, в какой иерархии она находится и какие статьи лежат вокруг. Макрос находит ее и вытягивает на нужную страницу по меткам.

Макрос «Содержимое по меткам»‎ работает как поиск по базе данных. Он находит статьи с нужными тегами и выводит их на страницу согласно заданным параметрам. Можно настроить отображение по дате создания, изменения или алфавиту, сделать обратную сортировку. Также можно включить отображение названия родительского пространства — собственно, того пространства, в котором эта статья была изначально опубликована. Еще можно выбрать отображение всех тегов, которые присвоены конкретной статье. Мы последними двумя опциями не воспользовались — решили отключить названия родительских пространств и тегов для того, чтобы не перегружать страницу гиперспейса.

Теги

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

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

Для наглядности работы системы вернемся к примеру с к инструкцией «Автоматизированное удаление подсетей и VLAN»‎.

• Она предназначается техподдержке, значит, ставим тег «support»‎.
• Относится к продукту «Выделенные сервера»‎. Значит, ставим тег «dedicated»‎
• Должна находиться в разделе «Управление подсетями»‎, для которой нужен тег «network»‎.

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

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

Поиск релевантных данных

После того, как мы определили структуру гиперспейсов, началось самое веселое: пошли искать нужные статьи по всему Confluence. Охватить сразу три сервисные команды и 15+ продуктов было очень сложно, поэтому остановились на команде техподдержки (она решает проблемы клиентов 24/7). Стали собирать для них гиперспейсы по трем продуктам: выделенным серверам, облачной платформе и облачной платформе на базе VMware.

В Selectel популярные конфигурации становятся дешевле с каждой секундой

Арендуйте подходящий сервер или предложите свой вариант, если не нашли нужную сборку на сайте.

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

В итоге наш гиперспейс в конфлюенсе стал выглядеть так ↓

Этот этап был самым выматывающим, но и самым занятным одновременно.

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

По дороге нашли кучу побочных битых процессов. Например, выяснили, что у нас нет единых стандартов форматирования статей (кто-то оформлял «предупреждение»‎ капсом и красным шрифтом, кто-то макросом «предупреждение»‎) и быстренько провели обучение по макросам.

Сбор гиперспейса по продукту занял у нас две недели от момента «мы придумали разделы»‎ до момента «кажется, мы нашли все нужные статьи»‎.

Результаты

С момента старта исследований прошло три месяца. За это время мы запустили первые гиперспейсы для техподдержки по трем флагманским продуктам. Когда опубликовали изменения и привлекли команду на тест, получили «вау»‎ и кучу хвалебного фидбека. Но вот проверку временем гиперспейсы идеально не прошли. Выяснилось, что:

• не хватает важных статей про продукты → так появилась задача про сбор обязательных артефактов.

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

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

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