Про міграцію бази знань. Розповідає технічна письменниця

Вітаю! Мене звати Ольга Мельничук, і я очолюю напрям Technical Communication у компанії SoftServe. Сьогодні я хочу з вами поділитися історією бази знань, яку ми нещодавно перенесли з Atlassian Confluence на Microsoft SharePoint.

Упродовж шести місяців ми готували контент до міграції, підчищали та оновлювали його, вивчали можливості SharePoint, опановували нові принципи роботи. Тож сьогодні я готова поділитися нашою історією, і сподіваюся, вона буде корисною для тих, хто планує таку міграцію контенту.

Read in English

Як усе починалося

Я була однією з перших технічних письменниць, які долучилися до створення цієї бази знань. Спочатку вона була зовсім «сирою» та містила всього кілька розділів, а з плином часу, і особливо з використанням додатків, макросів та плагінів, розросталася та розквітала. Спершу лише кілька авторів долучалися до створення нового матеріалу, та поступово їх ставало дедалі більше: кількість вимірювалася вже не одиницями, а десятками.

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

Однак роки роботи не могли не вплинути на задуманий ідеальний стан, тож коли постала потреба міграції до нового середовища, ми усвідомили: попереду грандіозні зміни.

Міграція 1-до-1 чи повне оновлення

Робота з базою знань нагадує мені процес організації гардероба. Спершу полиці нашої шафи порожні, тож ми наповнюємо їх одягом і створюємо повсякденні образи. Щоб залишатися в тренді, додаємо нові елементи, зберігаючи гармонію між старим та новим. Коли деякі речі вже набридли чи вийшли з моди, але нам ще шкода з ними прощатися, ми кладемо їх на найвіддаленішу полицю і часто-густо забуваємо про них на кілька років.

Хіба не схоже на історію з контентом? Ми створюємо структуру бази знань, пишемо статті, надаючи їм однакового вигляду та звучання. Ми експериментуємо з новими техніками письма, використовуємо додатки для кращого подання інформації. Іноді ми не видаляємо застарілі напрацювання, а зберігаємо їх про всяк випадок, поміщаючи в теку з обмеженим доступом, про яку потім рідко згадуємо.

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

Тому, коли постає питання міграції бази знань, розгляньмо її як чудову можливість зробити повне оновлення замість простого перенесення інформації як вона є.

Майбутнє з SharePoint

Щоб підготуватися до міграції, важливо порівняти поточний та новий інструменти, оцінити їх переваги, проаналізувати ризики та пропрацювати можливі обмеження. Для нас новою платформою бази знань став Microsoft 365 SharePoint. Оскільки ми активно користуємося іншими інструментами Microsoft, об’єднання всього в межах однієї екосистеми здалося нам більш ніж доцільним.

До міграції ми використовували SharePoint суто для зберігання та поширення файлів у межах команди. Однак ми ніколи не розглядали його як потенційну домівку нашої бази знань, інтранету чи будь-чого більшого, ніж простого файлового сховища.

Як це зазвичай трапляється із впровадженням нового інструменту, ми були дещо скептичними. Ми провели багато порівнянь, помічали численні обмеження і відкладали саму ідею міграції настільки, наскільки це було можливо. Та пройшовши типові стадії — заперечення, злість, компроміс, депресія — ми, нарешті, прийняли неминуче.

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

1. Дослідіть новий інструмент. Перегляньте офіційний вебсайт — у нашому випадку це SharePoint Help & learning — та інші ресурси (відео на YouTube, навчальні матеріали на Udemy або інших платформах, блоги тощо).
2. Дізнайтеся, який вигляд може мати ваша платформа. Наприклад, SharePoint look book демонструє різноманітні зразки вебсайтів/інтранетів/баз знань, розроблених для різних цілей, що є цінним джерелом натхнення.

SharePoint look book

3. Поцікавтеся досвідом подібних міграцій; досягнення та «граблі» інших можуть стати у пригоді.
4. Поговоріть з вашою ІТ-командою про необхідні та бажані функції, аби обрати оптимальний варіант. Перевірте, що передбачає стандартний пакет і які можливі до нього розширення.
5. Зверніться до представників продукту. Вони допоможуть налаштувати новий компонент у вашому середовищі, що особливо цінно, коли цей компонент комплексний.
6. Налаштуйте тестове середовище. Це завжди гарна ідея ретельно протестувати продукт перед переходом до публічного робочого середовища.

Повірте, глибоке розуміння можливого майбутнього стану робить всю трансформацію набагато цікавішою.

Підготовка контенту для плавної міграції

Гарний результат — це далеко не випадковість. Ключем до успіху є ретельна підготовка. Ось деякі аспекти, на яких слід зосередитися, якщо ви плануєте подібну міграцію контенту.

Аудит контенту

Аби уникнути зайвого «багажу», перегляньте всі застарілі та видалені сторінки, а також ті, які мають обмежений доступ, аби до SharePoint мігрувала лише необхідна інформація. Проведення аудиту в добре знайомому середовищі (у нашому випадку — Confluence) спрощує цей процес. Обов’язково перегляньте наступне:

• Приховані сторінки. Виявіть будь-які сторінки або розділи, назви яких містять слова «архів», «застаріле» тощо. Там можуть знаходитися невидалені матеріали, які приховані від користувачів, але все ще доступні в системі. Також перейдіть до Space tools > Permissions > Restricted Pages, де адміністратор Confluence може виявити сторінки з обмеженим доступом.
• Видалені (але все ще відновлювані) сторінки. Будь-яку видалену сторінку можна відновити, тож перегляньте кошик (Space tools > Content Tools > Trash) і натисніть Purge All, щоб назавжди видалити весь непотріб.
• Порожні сторінки. Перегляньте ваш контент на наявність порожніх сторінок, які навряд чи знадобляться вам у новому середовищі. Крім того, перейдіть до Space tools > Content Tools > Undefined Pages, де адміністратор Confluence може виявити фантомні сторінки, на які посилаються всередині Confluence.
• Нестандартні макроси. Деякі Confluence макроси, такі як children display, table of contents, excerpt include, чи aui-icon, можуть не мігрувати на SharePoint. Крім того, будь-які стилізації та налаштування, зроблені за допомогою HTML і CSS, скоріш за все не відтворяться на SharePoint належним чином. У контексті міграції краще дотримуватися правила «що простіше — то краще». Інформація з простим форматуванням зазвичай краще мігрує між платформами.

Аудит дозволів та обмежень

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

• Дозволи на рівні сайту. Дозволи використовуються для надання доступу до всього Confluence сайту — там слід надавати вашим відвідувачам максимальні можливості. За необхідності, обмежуйте доступ лише на рівні окремих сторінок. У Confluence перейдіть до Space tools > Permissions та переконайтеся, що дозволи відповідають вашим потребам. Рекомендую надавати дозволи групам, а не окремим користувачам поодинці. Також проводьте регулярну чистку, видаляючи неактивних користувачів та групи користувачів.
  Дозволи на рівні Confluence сайту

• Обмеження дій на рівні сторінок вимагають обережного застосування, враховуючи вплив загальних дозволів на рівні сайту. Рекомендую створити таблицю з основними розділами вашого Confluence: у ній вкажіть глобальні дозволи на рівні сайту та обмеження на рівні сторінок. Аналіз загальної картини може допомогти виявити можливі конфлікти між ними.

Обмеження на рівні Confluence сторінок

Оскільки на SharePoint не існує концепції розділів та підсторінок, обмеження треба встановлювати окремо для кожної сторінки. Доцільним рішенням може бути розділити вашу базу знань на два або три окремі сайти. Так ви зможете краще керувати дозволами на рівні сайту та забезпечити, що доступ надається або обмежується на необхідному рівні.

Аудит структури сайту

На відміну від ієрархії сторінок в Confluence, що дозволяє створювати розділи з підсторінками, всі сторінки в SharePoint зберігаються в одному репозиторії та мають однакові «права». Після міграції всі зв’язки між сторінками, тобто їх приналежність до розділів, буде втрачено. Крім того, SharePoint не генерує автоматичне навігаційне дерево — все доведеться налаштовувати вручну. Тож рекомендую переглянути ваше дерево навігації в Confluence та внести всі необхідні поправки, щоб забезпечити його успішне відтворення в SharePoint.

Автоматизація

Обов’язково розгляньте інструменти, що спрощують завдання міграції контенту. Такі інструменти можуть бути частиною комплексних рішень або пропонуватися як додатки: вони допоможуть спростити процес міграції та заощадять вам час для важливіших справ.

У нашому шляху міграції ми випробували кілька таких інструментів і виявили, що WikiTraccs найкраще закриває наші потреби. Він не лише прискорює міграцію з Confluence до SharePoint, але також перетворює макроси, посилання та зображення з Confluence на їхні еквіваленти в SharePoint.

Міграція як вона є

Після двох місяців підготовки, ми нарешті були готові розпочати міграцію. Всього за кілька годин WikiTraccs зробив свою роботу і переніс нашу базу знань на комунікаційний сайт SharePoint. Попри те, що контент переїхав на нове місце, було занадто рано відкривати його на широку аудиторію.

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

• Завелика кількість ресурсів сайту (site assets). Оскільки ми не переглядали всі прикріплення (attachments) перед міграцією, постала потреба провести додаткове очищення.
• Тимчасове дерево навігації, яке створив інструмент WikiTraccs, відтворило структуру нашого Confluence сайту, відтак показало ще кілька раніше недоступних сторінок на Confluence.

Автогенероване дерево навігації, скриншот з wikipakk

• Деякі сторінки виявилися пошкодженими, з порожніми розділами або фрагментами коду. Оскільки ми широко використовували макроси в Confluence, це спричинило проблеми з правильним відображенням або неповною міграцією деякої інформації.
• Ми помітили різні кольори тексту, такі як синій та зелений, поряд із типовим чорним. Причина цих варіацій кольорів залишилася для нас загадкою.
• Наша система тегів в Confluence потребувала перегляду та повної перебудови під час процесу міграції.
• Всі зображення було мігровано, однак вони стали відображалися з додатковими відступами чи неправильним розташуванням.

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

Після міграції

Настав час налаштувати сайт SharePoint так, щоб він відповідав нашим потребам. Ми вирішили не реплікувати наші звички з Confluence, а натомість максимально скористатися вбудованими можливостями та налаштуваннями SharePoint.

Ієрархія сторінок та дерево навігації

Значна відмінність між Confluence та SharePoint полягає в підході до структурування інформації. Confluence використовує ієрархічну структуру зі сторінками та підсторінками, які автоматично відображаються в дереві навігації. У SharePoint же існує один-єдиний репозиторій для сторінок, бібліотек документів, списків та ресурсів сайту. Дерево навігації в SharePoint за замовчуванням містить декілька стандартних посилань, та його можна легко налаштувати.

Навігаційне дерево, створене WikiTraccs, чудово відпрацювало протягом перших днів після міграції, допомагаючи нам встановити приналежність сторінки до того чи іншого розділу. Однак з погляду довгострокової перспективи, вбудоване трирівневе мегаменю в SharePoint все ж більш гнучке: воно може містити як внутрішні, так і зовнішні посилання. І хоча обмеження SharePoint навігації лише трьома рівнями — порівняно з необмеженими рівнями в Confluence — спершу досить розчаровує, це вчергове підкреслює важливість належної інформаційної архітектури.

Приклад мегаменю в SharePoint

Вигляд контенту

Коли мова йде про створення візуально привабливого сайту, SharePoint пропонує ряд налаштувань.

• Шаблон сайту SharePoint. Ми обрали шаблон Department, оскільки вигляд та структура його початкової сторінки максимально відповідали нашому баченню. Додаткові сторінки, що пропонувалися в комплекті з шаблоном, служили чудовим джерелом натхнення.
• Тема. SharePoint не вирізняється різноманіттям палітри кольорів, тож ми просто обрали один із запропонованих варіантів, який найкраще відповідав нашому бренду та візуальній ідентичності.
• Шапка сайту та нижній колонтитул. Ми завантажили наш логотип та обрали розширений макет для шапки сайту. У нижньому колонтитулі ми додали корисні посилання, авторські права та контактні дані.
• Шаблони сторінок. Ми створили кілька шаблонів, які можна використовувати як основу для нових сторінок. Ці шаблони включають такі основні елементи як колористика секцій, форматування списків, таблиць, а також правила оформлення, яких слід дотримуватися. Таким чином, ми забезпечили стандартизований вигляд для нашого контенту.

Секції та вебчастинки

SharePoint пропонує такі структурні елементи сторінки, як секції та вебчастинки, які дозволяють ефективно організовувати та презентувати інформацію.

Згортні секції (collapsible sections) в SharePoint особливо корисні для довгих сторінок. Вони дозволяють користувачам розгортати та згортати секції контенту, у такий спосіб покращуючи читабельність та полегшуючи навігацію. Ще одна функція, яка мені дуже подобається, — це можливість встановлення кольору фону для групування конкретних елементів на сторінці. Це допомагає створювати візуальну відмінність та наголошувати на важливій інформації.

Різноманітність «будівельних блоків» SharePoint, так званих вебчастинок (web parts), стає в пригоді, коли мова йде про презентацію контенту. Hero, Quick links, People, YouTube, Divider — це лише кілька з тих, які ми часто використовуємо. Ці вебчастинки дозволяють нам представити контент у різних форматах, залучати користувачів інтерактивними елементами, виділяти ключову інформацію та створювати візуально привабливі макети.

Контроль доступу

SharePoint надає можливість детально пропрацювати контроль доступу на рівні сайту, а також визначити ролі користувачів та обмежувати їх доступ до конкретного вмісту — сторінок чи файлів. Однак, через відсутність ієрархічної структури сторінок в SharePoint, встановлення обмежень доступу до конкретних розділів бази знань може бути складним завданням.

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

Співпраця

Confluence пропонує досить багато функцій для співпраці, таких як вподобайки, коментарі та згадки, що допомагає залучати співавторів до створення контенту. У порівнянні, SharePoint має обмежені можливості в цьому плані. Хоча SharePoint дозволяє коментувати сторінки та позначати людей у коментарях, в ньому відсутній вбудований механізм коментування, який є надзвичайно корисним під час перегляду контенту або опрацювання конкретної теми, згаданої на сторінці. Ми розглянемо можливі шляхи виправлення цієї проблеми у майбутніх ітераціях — мають же бути додатки для покращення можливостей співпраці? Принаймні, я сподіваюся, що такі існують😊

Висновки

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

В цілому, у мене змішані враження від SharePoint. З одного боку, він пропонує широкий спектр функціональностей та викликає захоплення. З іншого боку, він обмежує можливості для співпраці чи повторного використання вмісту, що є важливим для роботи технічного письменника. Подивимося, як все розвиватиметься, адже це лише початок.

А ви вже працювали з SharePoint як платформою для бази знань?