У чому полягає бізнес-цінність Technical Writers/Technical Communicators

Привіт! Мене звати Оксана Слюсарова, я працюю Technical Communicator у компанії SoftServe.

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

Більш того, навіть Project Manager та найближчі члени команди можуть бути не в курсі, яка ж користь від техрайтера. Коли я доєдналася до свого першого проєкту у цій ролі, то довелося підготувати мініпрезентацію і розказати, що це за «фантастичні звірі — техрайтери» (саме так і називалася моя презентація).

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

Ця стаття буде корисна для Project Managers, Product Owners, Talent Success Leads та інших спеціалістів, які ухвалюють рішення щодо залучення кадрів.

Read in English

Що техрайтери роблять

Ці спеціалісти створюють чітку, точну документацію, підлаштовуючи її під потреби певної аудиторії. Одразу уточню, що документація — це не тільки текст і скриншоти. У статті цей термін містить будь-які допоміжні матеріали, навіть діаграми, one-pagers, гіфки та відео (про це ще йтиметься далі).

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

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

Що техрайтер може зробити для вас

У вас на проєкті досі немає техрайтера? Або ж є, але ви не використовуєте його потенціал на повну?

Річ у тім, що обов’язки та можливості спеціаліста дуже відрізняються залежно від компанії та проєкту. Тому ця позиція навіть називатись може по-різному, наприклад: Technical Communicator, Technical Illustrator, Technical Content Developer, Information Designer тощо (до речі, моя нинішня позиція в компанії називається Senior Technical Communicator).

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

Наведу приклад своєї колежанки: вона робила відеоінструкції для промислової аплікації. З давніх-давен інженери в корпорації Озкорп складали to-do списки для механіків, електриків та інших працівників. Хоча всі ці люди — технічні, але аплікація була достатньо складною, і було важко розібратись з тими перехресними to-do списками та дотичними додатковими інструкціями. Усім доводилось витрачати купу часу на пошук інформації та внутрішню комунікацію: переписку, дзвінки, особисті зустрічі для з’ясування подробиць. Тож завданням техрайтерки було створити таку серію відеоінструкцій, які б пояснювали все максимально просто та коротко, й економили дорогоцінний час на промисловому виробництві. І це вдалося.

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

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

Зокрема, Райтер, Техрайтер може бути вам корисний у виконанні таких завдань.

Для кінцевих користувачів:

  • Створювати різноманітні посібники користувача (user guides) та покрокові інструкції. Техрайтер створює матеріали, які допомагають людям отримати позитивний досвід від користування продуктом. До того ж деяким людям просто не подобається розмовляти телефоном зі службою техпідтримки (що може стати додатковою проблемою через інший часовий пояс або мовний бар’єр). Саме тому добре, коли є вичерпна письмова селфдопомога. До прикладу, я — одна з тих людей, хто спочатку дивиться інструкцію, а потім уже згідно з нею збирають поличку для взуття з Ikea. (А не збираю поличку, матюкаюсь, що не вдається, а потім дивлюся інструкцію).
  • Створювати release notes. Мабуть, на release notes можна швидше за все побачити бізнес цінність, бо цей невеличкий документ можна відносно швидко зробити, а користі — цілий вагон. Release notes інформують користувачів про вдосконалення продукту, зацікавлюють їх скористатись новим функціоналом, а також демонструють вашу відданість безперервному вдосконаленню. Наразі я веду документацію декількох американських продуктів, і для моїх Product Owners release notes — це пріоритет номер один (разом із створенням нової допоміжної документації). І тільки потім ідуть апдейти документації і все решта.
  • Створювати newsfeed, newsletter, what’s new. Вони мають схоже з release notes призначення та цінність, але у них трохи інший формат і канали розповсюдження.
  • Створювати виринайки (pop-up нотифікації) у продукті, що анонсують нові / оновлені фічі або попереджають про системні збої. У ролі end users ми найчастіше бачимо такі виринайки, коли оновлюються наші мобільні застосунки. Але вони трапляються і в десктопних, і у вебпродуктах також. Між іншим, у себе на проєкті, разом із публікацією release notes, я запускаю і такі сповіщення-виринайки.
  • Пояснювати складне програмне забезпечення користувачам. Належна допоміжна документація просто необхідна, якщо продукт складний, вузькоспеціалізований або незвичний (має неочікувану поведінку).
  • Структурувати контент у логічну, візуально привабливу та читабельну форму. Наприклад, у таблиці, глосарії, інфографіку, зображення. З власного досвіду помітила, що половина роботи техрайтера припадає саме на структурування та переформатування інформації. Досить часто завдання звучить приблизно так: із цього моноліту тексту на 40 сторінок зробити щось читабільніше. І тоді я починаю аналізувати текст, виокремлювати блоки, якусь інформацію залишаю у вигляді тексту, а іншу перетворюю на діаграми та таблиці. Іншим прикладом тут може слугувати створення глосарію та knowledge base. Техрайтер може перетворити хаос розрізнених файлів невідомої версійності на структурований каталог. У чому цінність? Швидкість роботи значно підвищується коли інформація доступна, а опис процесів — уніфікований. Також стандартизація може знизити витрати на оновлення, підтримку та подальшу міграцію документації.

Для внутрішньої команди:

  • Створювати внутрішні онбординг-матеріали. Демо відео, селфтренінги, посібник для новачка — усі ці матеріали значно прискорюють швидкість адаптації на проєкті. Я знаю один випадок, коли до команди доєднався новий бізнес-аналітик. Онбординг-матеріалів не було зовсім, а старожили, які добре знають продукт, — у відпустці (одночасно із Product Owner). І розбирайся у тому продукті сам. Це додатковий стрес, нам таке не треба, правда ж?
  • Звільняти інших членів команди від документування. У кожного — свої недоліки. У технічних експертів та SME просто немає часу писати. А Product Owner не має придумувати release notes (бачила і таке) — у нього є купа іншої важливої роботи. До того ж людина, яка читає документацію, не володіє тією ж глибиною знань, як людина, що її написала. Тому «письменник» повинен ретельно адаптувати інформацію під свою цільову аудиторію. Варто зазначити, що тестувальникам однаково доведеться самим створювати test cases, а бізнес-аналітикам — use cases діаграми. Це суто їхня сфера документації. Хоча техрайтер і тут стане в пригоді, перевіряючи, вичитуючи їхню документацію на граматичні, логічні, стилістичні помилки.
  • Переглядати та редагувати внутрішню документацію, створену PM, BA, DevOps та іншими членами команди, щоб забезпечити точність, ясність, єдність стилю. Прикладами в цьому випадку можуть слугувати посібники з налаштування та план аварійного відновлення (так званий Disaster Recovery Plan).
    І не забувайте, що техрайтер може не тільки перевірити текст, а й оформити його згідно з гарненьким шаблоном з титульною сторінкою, логотипом, вирівнюванням і т. д. (Тож буде не тільки правильно, а ще й гарно). З досвіду деліверних проєктів скажу, що задачі з внутрішньої документації часто падають у беклог техрайтера, бо документація для кінцевих користувачів та інша зовнішня документація є більш пріоритетними. Але буває і таке, що техрайтера спеціально наймають, щоб навести лад у внутрішній документації.
  • Вести changelog продукту. (І ні, changelog — це не те саме, що release notes).
  • Допомагати із зовнішньою документацією, як-от case study, специфікації, презентації на pre-sale, документація для аудиту, сертифікатів відповідності та інше. Мої колежанки-техрайтерки розповідали багато смішних (і не дуже) історій, як вони робили редизайн слайдів та рятували PowerPoint презентацій для pre-sale. Будь-яка компанія хоче вразити своїх потенційних клієнтів, зробити їм пропозицію, від якої не зможуть відмовитись. А погана презентація тільки завадить справити потрібне враження. Тож краще або покликати на допомогу техрайтерів чи дизайнерів, або обійтись взагалі без презентації.
  • Створювати візуальний контент, зокрема how-to-відео, гіфки, діаграми — як для внутрішніх, так і для зовнішніх потреб.
  • Допомагати з локалізацією та перекладом. (Так, техрайтери роблять навіть це).
  • Зберігати документацію. Техрайтери також виступають бібліотекарами, я б навіть сказала хранителями, документуючи важливу інформацію та зберігаючи її для повторного використання. Ніколи не думаєш, наскільки функція зберігання корисна, допоки з проєкту не піде або техрайтер-бібліотекар, або людина, яка пропрацювала на проєкті десять років і знала всі нюанси. Втрата критичної інформації накопиченої роками — це проблема. І, боюся, досить поширена. Моя колежанка колись працювала на проєкті, де скоротили досвідченого backend-розробника. Він був разом з командою із самого початку, з перших рядочків коду, і з перших милиць у коді. Виявилося, що він був єдиною людиною, що знала чому шість років тому було поставлено ті милиці та чому без них код не працює.

Для продукту:

  • Працювати над API-специфікацією, необхідною для інтеграції з власними системами та сторонніми програмами.
  • Аналізувати отриманий практичний досвід роботи з продуктом та пропонувати UI/UX-вдосконалення. Гарний UI/UX — це як гарний сервіс — його не помічаєш, коли все в порядку. А от коли щось іде не так, то це одразу відчувається.
  • Писати тексти для програм (мікрокопі), а саме: підказки, що спливають, назви кнопок, текст в error- і success-повідомленнях тощо. Короткий та вичерпний мікрокопі-текст полегшує користування продуктом та підвищує рівень задоволеності користувачів. Розробники не завжди можуть самі чітко і зрозуміло написати мікрокопі-текст (але і не мусять, бо це не їхня робота).
  • Сприяти розробці безбар’єрного та інклюзивного програмного забезпечення. Команда продукту повинна піклуватися про кінцевих користувачів і враховувати людей з інвалідністю. Не треба недооцінювати кількість таких людей. Насправді мовиться не лише про інвалідність (наприклад, відсутність кінцівки), а й про тимчасові стани (перелом руки) та ситуативні стани (мати загойдує немовля і тримає телефон однією рукою). Тому, фактично, усі люди потребують інклюзивності в продуктах. От прям усі — і ми з вами теж.
  • Забезпечувати уніфікацію та відповідність документації нормативним стандартам (ISO, SOC). Тут без зайвих коментарів. Для програмних продуктів, які мають відповідати жорстким стандартам та вимогам, це необхідно.
  • Робити внесок у брендинг, voice and tone, look and feel від вашого продукту. Це неймовірно важливо для всіх (але особливо — для великих) компаній, які дбають про свій бренд, репутацію і впізнаваність на ринку. (Ви точно не переплутаєте мобільні застосунки ПриватБанк і Монобанк — це два абсолютно різних бренди).

Досить вражаючий перелік можливостей техрайтера, чи не так?

І справді, досвідчений техрайтер — це трішечки дизайнер, бізнес-аналітик, тестувальник — усе в одному флаконі. Це було найбільшим (приємним) сюрпризом для мене, коли я тільки прийшла у цю професію.

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

Вам точно потрібен техрайтер, якщо...

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

  • Продукт спеціалізується на інтеграції з іншими програмами, а тому не обійтись без API-документації. Як ми вже знаємо, ні в кого іншого немає часу на створення API-документації. Тож техрайтер поспішає на допомогу.
  • Програмне забезпечення є складним, вузькоспеціалізованим або незвичним. Комусь-то треба навчити юзерів користуватись вашим продуктом.
  • Ваша компанія — велика, або у вас є портфоліо продуктів. Єдність стилю, послідовність і стандартизація важливі для брендингу та репутації вашої компанії. І це надважливо, коли вам потрібно бути узгодженим у всій документації для кількох відділів або кількох продуктів. Колись ми із моїм лідом витратили цілих три тижні, щоб стандартизувати шаблони для release notes та changelog, зустрітись окремо з кожним Product Owner по кожному продукту, та прийти нарешті до єдиного стандарту для портфоліо наших продуктів. (Проєкт був один, але ми паралельно підтримували чотири продукти).
  • Дизайн та UX продукту недопрацьовані. Юзери змушені виконувати дії, які не є інтуїтивно зрозумілими. У них виникають проблеми й вони шукають відповіді. Це дуже розповсюджене явище. Навіть одна недопрацьована дрібничка в етапі здійснення оплати або введення адреси доставлення, і все — людина нічого не купить у вас на платформі та піде до конкурента. Тут у кожного з нас, як у клієнта, знайдеться декілька прикладів.
  • Технічна підтримка 24/7 у вас уже є, але це не допомагає. Техрайтери забезпечують користувачів чіткими письмовими інструкціями, щоб ті могли швидко знайти потрібну інформацію. Це сприяє зменшенню кількості дзвінків на лінії технічної підтримки та, відповідно, ваших витрат на персонал. (Водночас вам не потрібен великий штат техпідтримки, коли продукт є юзер-френдлі. Значить... Хʼюстон, у вас проблема з попереднім пунктом).
  • Бракує автоматизації. Користувачі змушені робити додаткові дії, які програма мала б виконувати за них автоматично. Тож щоб зменшити стрес користувачів і пояснити їм, які додаткові кроки треба робити, не обійтись без допоміжної документації.

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

Що ви можете зробити для техрайтера

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

  • Зробіть фахівця частиною команди. Хороший техрайтер досить незалежний, самодостатній і може розкопати інформацію сам. Але команда для того і є, щоб працювати разом. Я часто приходжу до розробників і тестувальників, уточнюю в них деталі з Jira-тікетів. А розклад бізнес-аналітика та Product Owner закріплено в мене в календарі, бо вони роблять фінальне ревʼю документації перед публікацією. Ми всі — частина команди, частина корабля. І розраховуємо на підтримку і взаємну користь.
  • Залучіть техрайтера до критичних мітингів, обговорень та новин про продукт. Наприклад, відвідування демо мітингів дуже допомагає мені у майбутньому створенні release notes. А коли я знаю, що планується міграція з однієї тули в іншу, то можу почати готуватись заздалегідь і уникнути подвійної роботи.
  • Залучіть його до дизайну продукту. Відчуваючи «біль» кінцевого користувача та знаючи його досвід, спеціаліст може запропонувати багато ідей щодо покращення UI/UX. Ви можете продати продукт, але не зможете утримати юзерів, якщо продукт їм не подобається. Виправляти похибки на етапі проєктування — завжди дешевше. Отже, що раніше ви запросите техрайтера до проєкту, то краще. В ідеалі — на самому початку, на етапі розробки продукту. Максимальний результат ви отримаєте, якщо техрайтер буде працювати разом із UI/UX-дизайнерами, командами Customer Success і Customer Support. Про таку колаборацію я поки що тільки мрію, але нам разом з бізнес-аналітиком декілька разів вдавалося переконати Product Owner змінити назви кнопок та розташування панелей. Після цього користувачі перестали плутатись у послідовності дії.
  • Дозвольте збирати та опрацьовувати фідбек. Користувачам подобається, коли їхні коментарі та побажання враховують (взагалі-то, будь-якій людині подобається відчувати себе важливою). Тож дозвольте працівникам (техрайтерам разом з командами Customer Success та Customer Support) виділяти час на це та експериментувати з різними опитуваннями, відгуками та збором статистики. Кінцеві цілі тут досить очевидні: зібрати інформацію про проблемні місця продукту та, таким способом, покращити допоміжну документацію і загалом UI/UX продукту.

Найголовніше — це позитивний досвід користувачів. Який, своєю чергою, сприяє лояльності аудиторії, виділяє вас серед конкурентів і запускає сарафанне радіо для залучення нових потенційних користувачів.

Отже...

Мені здається, це початок прекрасної дружби — вашої і техрайтера.

Тепер ви знаєте про бізнес-цінність техрайтера на софтвер-проєкті та можете ухвалювати більш зважені рішення.

Належне документування економить час і зусилля всієї команди. І, звісно ж, вичерпна документація економить гроші, скорочуючи витрати на Customer Support (для протоколу: я не стверджую, що Customer Support зовсім не потрібні).

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

Ось чому хороша документація — це турбота про користувачів та бізнес.

P.S. Ця стаття присвячується всім Technical Writers мого улюбленого міста Харкова. Хай прибуде з нами сила! Харків — незламний!

👍ПодобаєтьсяСподобалось13
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую за статтю! Мені вона цікава, бо я маю навички, необхідні для роботи техрайтером, але не маю достатнього досвіду, щоб бути успішним кандидатом. Я бачу, що Softserve проводив курс для техрайтерів, але ще в 2021 році. Чи плануюється проведення такого курсу в 2024? Чи є в Україні курси/сертифікації/стажування для entry-level спеціалістів? Більшість сертифікацій вже для мідлів. Я вже рік досліджую цю професію, але крім I’d rather be writing нічого для джунів не знайшла. Яким чином потрапляють на позицію техрайтера молоді спеціалісти? Буду вдячна за рекомендації.

Дякую, Ольга. Рада, що стаття сподобалась. Так, дійсно, кілька років поспіль SoftServe проводив безкоштовні курси для студентів українських вишів. Наразі, такого курсу немає, але ймовірно будуть ще в майбутньому. Але є і гарна новина: в цю професію можна увійти і без курсів/сертифікацій (хоча з ними, звісно, простіше). Треба знайти підходящу вакансію і відправити резюме. Якщо у Вас хороша англійська і є потрібні навички або суміжний досвід (працювали перекладачем, викладачем, копірайтером, тощо) — то шанси стати Intern або Trainee техрайтером досить великі. : )

Будь-який суміжний досвід може стати в пригоді: створення відео, one-pagers, волонтерські проекти по перекладу. Іноді щастить знайти проект, під який підходите саме ви. Умовно, людина добре знає біологію та географію, а тут як раз проект пов’язаний із відстежуванням міграції тварин.

У попередній нашій статті на DOU є розділ про «З чого почати свій професійний шлях в технічній комунікації» dou.ua/forums/topic/35039. Там є опис базових навичок та перелік інструментів, знання яких стане великим плюсом для початківців. (Особливу увагу зверніть на Microsoft Writing Style Guide.)

А за нашими вакансіями можна слідкувати на офіційному сайті career.softserveinc.com/...​n-technical-communication

Тут яка справа — для внутрішньої комунікації команді тех райтер не потрібен. А для комунікації з клієнтами найкраще коли тексти пише-править нейтів спікер.

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

Дякую, Олегу. Повністю погоджуюсь. Документування — це окремий вид діяльності, де є свої правила, норми, стандарти. Саме тому існує окрема професія техрайтер. : )

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

Якщо не важливо — то і тех райтер не потрібен.

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

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

Із кумедного: нейтів спікери можуть і самі не знати усіх правил граматики рідної мови (якщо спеціально їх не вивчали).

Повторюсь — нейтів спікер тех райтер набагато краще ніж той тех райтер для кого мова іноземна.

Так, а ще техрайтер з досвідом у вашій сфері набагато краще ніж техрайтер без досвіду у вашій сфері, і ще багато самоочевидних «порад».

Підписатись на коментарі