Як я створив відділ технічної документації в державній IT-компанії

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Вітаю! Мене звати Роман Пасіков і я очолюю відділ технічної документації в державній IT-компанії. До цього я 6 років працював технічним письменником в компанії SoftServe.

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

Контекст та виявлення потреби

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

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

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

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

Відділ технічної документації

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

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

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

Коли я говорю про відділ технічної документації, маю на увазі внутрішню організацію, яка на постійній основі займається і відповідає за такі задачі:

• Управління стандартами технічного письма в компанії.
• Налаштування процесів, пов’язаних з технічною документацією.
• Підтримка та координація проєктів, які мають в команді технічних письменників.
• Моніторинг і звітність щодо продуктивності та цінності роботи технічних письменників.
• Організація та регулярне оновлення портфоліо.
• Управління ризиками, що стосуються документації.
• Забезпечення якості технічної документації на проєктах.
• Комунікація та співпраця з питань технічної документації.

З чого все починалося

Уявіть собі компанію, яка з’явилась кілька місяців тому, вже має десятки різноманітних продуктів та сотні технічних спеціалістів, і ще ніхто централізовано не несе відповідальності за технічну документацію. Саме в такому середовищі мені довелося працювати.

Після прочитання відповідних статей і розмірковувань, я склав план запуску відділу, розділив його на етапи й на кожному етапі визначив цілі та ключові результати. У моєму випадку наступний (дещо спрощений) підхід видався цілком прийнятним.

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

Я все ж намагався взяти якомога більше з початкового плану, але водночас мені довелося бути дуже гнучким.

Розуміння потреби

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

• Дослідив, які типи документів потрібні.
• Провів аудит, щоб виявити прогалини та слабкі місця в наявній документації.
• Зібрав зворотний зв’язок від зацікавлених сторін (внутрішніх команд, кінцевих користувачів, служби підтримки клієнтів).
• Оцінив технологічні та операційні фактори (інструменти, інфраструктуру, інтеграцію з командами розробки).

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

Проєктування рішення

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

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

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

• Консалтинг проєктів щодо документації. Експерт відділу аналізує потреби проєкту та надає свої рекомендації щодо типу, структури, формату, стилю та інших аспектів документації, яка найкраще підійде для продукту. Кажучи простими словами — як на практиці наш відділ може допомогти проєкту.
• Розробка технічної документації. В рамках цього сервісу технічний письменник залучається на проєкт і допомагає проєктній команді створити чітку й структуровану технічно-експлуатаційну документацію, яка покриватиме потреби цільової аудиторії продукту. Тут я планував залучати на пріоритетні проєкти тих спеціалістів, яких хотів найняти найближчим часом.
• Оцінка і перевірка стану технічної документації. Тут експерт відділу аналізує вже наявну проєктну документацію і перевіряє її на відповідність потребам та меті продукту. Як результат оцінки експерт має надати рекомендації щодо покращення документації, а також допомогти визначити пріоритети та оцінити обсяг потрібних робіт.
• Детальне редагування і форматування документів. Експерт відділу перевіряє і редагує будь-які документи, щоб забезпечити точність, чіткість подачі інформації та відповідність конкретному шаблону або стандартам (маю на увазі ДСТУ, ГОСТ та різні нормативно-правові акти).

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

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

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

Запуск роботи відділу

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

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

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

Побудова команди

Поки я намагався самостійно впоратися з короткостроковими запитами, розпочав процес співбесід та найму перших технічних письменників. На той момент у мене ще не було ретельно продуманого плану онбордингу для новачків, і спочатку він складався лише з кількох зустрічей, де я приблизно пояснював ситуацію з документацією на проєктах, типи документів, які ми повинні створювати, нашу інфраструктуру для співпраці, а також рекомендував читати Microsoft Writing Style Guide, поради дизайн-системи державних сайтів України та статті про основні правила створення документації для кінцевих користувачів. Наприклад, Документація, орієнтована на користувача. Як створити цікавий і доступний контент.

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

Інтеграція з іншими відділами

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

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

Голосуйте в Премії DOU 2025!

Я також розумів, що буде все більше проєктів, які потребуватимуть документації, і, як варіант (через брак професійних технічних письменників), мені доведеться пропонувати залучити когось із проєктних команд, хто вміє добре писати. На собі в таких випадках я залишав би ті самі навчання, настанови й перевірку. Таким чином я залучав проєктних менеджерів, бізнес-аналітиків та розробників до написання документації під моїм наглядом і з моєю допомогою. Відмічу, що з цієї невеликої вибірки людей найкращими технічними письменниками виявилися бізнес-аналітики 😊

Ми всі розуміли, що документи не могли бути ідеальними, але й вимога на цьому етапі зрілості проєктів полягала в тому, щоб вони були «достатньо хорошими». Очевидною цінністю наших документів було те, що команді підтримки стало набагато легше обробляти запити від кінцевих користувачів. Пізніше нам навіть вдалося створити досить хороші системи допомоги (help systems) для декількох проєктів.

На цьому етапі ми могли запропонувати лише два типи форматів — PDF-посібники та Markdown-посібники, які були інтегровані в продукти, імітуючи контекстну чутливість (context sensitivity). Такі обмеження здебільшого обумовлювались підвищеними вимогами до кібербезпеки та специфікою інформації в документах. На початковому етапі ми не могли розглядати використання певних програм для створення документації й виключали навіть теоретичні можливості витікання інформації у вільний доступ.

Розробка стандартів документації

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

Звісно, ми прагнули до того, щоб наша документація була узгодженою та сприймалася як ніби її створював один професіонал. Просте й очевидне розв’язання цієї задачі — мати шаблон із заздалегідь визначеним форматуванням та посібник зі стилю письма (style guide), в якому були б описані основні правила та рекомендації. Зазвичай я покладався на Microsoft Writing Style Guide. Це досить хороший ресурс, і більшість технічних письменників довіряють правилам Microsoft. Оскільки наша документація була українською мовою, ми не могли повністю покладатися на нього і мали знайти альтернативу. Тут ми зазнали невдачі. Виявилося, що в Україні немає надійного посібника зі стилю письма для користувацької документації.

Паралельно з перевіркою документів, автором яких були нетехнічні письменники, я працював над створенням стандартів документації для нашої компанії. Оскільки я раніше читав і досліджував посібники Microsoft, Apple, Google, Atlassian, на основі найкращих порад від кожного зробив посібник для нашої компанії. Приправив це все правилами граматики української мови та порадами з власного досвіду та здорового глузду. Усі рекомендації були логічно структуровані та адаптовані до нашої аудиторії.

У підсумку ми отримали документ на ~20 сторінок, який легко сприймається і містить основні правила, що охоплюють 99% ситуацій, з якими стикалася наша команда. Складніші випадки ми досліджували окремо і користувались порадами друзів-філологів.

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

Цей посібник зі стилю письма зробив навчання нових технічних письменників набагато ефективнішим і дозволив мені вивільнити більше часу для інших завдань. Як результат, помилок стало менше, і я зміг почати групувати письменників в пари для взаємної перевірки. Це також допомогло забезпечити узгодженість (consistency) і якість усіх документів, що стало наступним ключовим елементом ефективності нашого відділу.

Забезпечення узгодженості та якості документів

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

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

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

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

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

Це все по кроках і стадіях становлення відділу технічної документації, але є ще декілька важливих моментів які, на мою думку, варто завжди мати на увазі.

Постійне вдосконалення

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

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

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

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

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

Масштабування ініціативи

Зі збільшенням кількості запитів попит на документацію, а відповідно й на наші послуги, продовжував зростати. Ми отримали «зелене світло» для масштабування ініціативи. На цьому етапі наші процеси були достатньо зрілими, і ми були готові до зростання.

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

• Чіткі цілі для відділу. Ми знали, що саме повинні досягти, і мали досить чітке уявлення про нашу місію.
• Знання цінності нашої роботи. Ми чітко розуміли, яку роботу виконуємо і яку цінність приносимо як для внутрішніх команд, так і для кінцевих користувачів.
• Розуміння, де шукати таланти. У нас був чіткий план щодо того, де шукати нових технічних письменників для команди.
• Процеси співбесід та адаптації. Ми знали, як проводити співбесіди і як ефективно інтегрувати нових людей в команду.
• Грамотне навантаження на людей. У нас була стратегія комунікації для пошуку нових проєктів для технічних письменників, чиї поточні проєкти наближались до завершення.
• Налагоджене робоче середовище та процеси. У нас вже були встановлені процеси та стандарти для створення документації.
• Бажання розвиватися. Команда мала ентузіазм та готовність до подальшого розвитку та вдосконалення.

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

Підсумок

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

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

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