Беручи тему з усунення несправностей DITA для спіну - Scriptorium
Цей гостьовий допис від Карлоса Евіа, доктора філософії, директора з професійного та технічного письма в Virginia Tech.
Тема усунення несправностей DITA є однією з “нових” функцій у версії 1.3 стандарту. Однак усунення несправностей існує у світі DITA вже близько восьми років.
В архіві плагінів SourceForge для відкритого набору інструментів DITA досі міститься спеціалізація з усунення несправностей, випущена в жовтні 2007 року. Тема усунення несправностей 2007 року звучала як візит до лікаря з тегами, такими як tsSymptoms, tsCauses, tsDiagnose і tsResolve (tsTake2Aspirins був занадто довгим), Я вважаю).
Лише в липні 2014 р. Технічний комітет з прийняття DITA оголосив тему усунення несправностей як новий, офіційний тип вмісту в стандарті. Потім комітет опублікував остаточну версію технічного довідника з використанням DITA 1.3 Troubleshooting, автор Боб Томас. У доповіді представлено обґрунтування теми усунення несправностей, а також подано детальні, точні приклади та шаблони, зосереджені на структурі пар причин та засобів, що заповнюють тему.
Приблизно в той час мене запросили керувати консультаційним проектом для клієнта, якому потрібен онлайн-посібник із процесів, пов’язаних з виробництвом картону (а не їх фактичним бізнесом; лише приклад для цієї публікації). Клієнт хотів отримати веб-інформацію "як це зробити" для операторів, відповідальних за процеси гофрування та різання картону (а не про фактичні процеси, які ми задокументували). Коли я збирав команду викладачів та студентів з технічного спілкування та інформатики, під час ранньої зустрічі клієнт виявив, що основна увага в посібнику повинна бути зосереджена на усуненні несправностей. Це подряпало мій свербіж за те, що я розглянув тему з усунення несправностей.
Через сім місяців процесу, коли ми завершуємо проект, тут я ділюсь деякими уроками, отриманими з мого досвіду, з темою усунення несправностей.
Проведіть аналіз першопричини
Аналіз завдань, збір та аналіз застарілої документації та інтерв’ю з експертами з предметів. Традиційна зброя для технічного спілкування, мабуть, неефективна для отримання інформації про усунення несправностей. Шукаючи пари причин і засобів, команда (на чолі з персоналом клієнта) провела аналіз першопричини. У 3-му виданні своєї книги «Аналіз корінних причин» Latino & Latino визначили це, включивши чотири різні визначення! Для четвертого видання (яке включає 3-й Latino у списку співавторів) вони спрощують визначення аналізу корінних причин як «встановлення логічно повних, обґрунтованих фактичними даними, тісно пов’язаних ланцюгів факторів від найменш прийнятних наслідків до найглибші суттєві основні причини »(с. 15).
Конкретним інструментом причин і наслідків, який ми використали для цього проекту з усунення несправностей, був сеанс із п’ятьма проблемами, за допомогою якого можна “поставити під сумнів кожну виявлену причину, чи є це симптомом, причиною нижчого рівня чи першопричиною” та “продовжити пошук справжніх першопричин навіть після того, як встановлено, що можлива причина була знайдена »(Andersen & Fagerhaug; 2000, с. 117). У цих п’яти випадках брали участь керівники, оператори з різним рівнем досвіду та персонал з відділу кадрів клієнта. Врешті-решт, у нас була серія таблиць, що документують умови, надаючи тип пар причин і засобів, зазначених у технічному документі DITA Adoption TC.
Розставити пріоритети щодо умов та рішень
Тривалий сеанс аналізу корінних причин з наглядачами, користувачами та менеджерами може бути занадто вичерпним для керівництва з усунення несправностей, спрямованого на аудиторію механічних операторів. Ніколи не забувайте про запланованих користувачів постачання та їх унікальні потреби. Під час експерименту з п’ятьма причинами ми виявили деякі стани, що мали понад 15 можливих пар причин і засобів. Усі вони були цікаві та стосувались деяких аспектів виробництва картону. Однак деякі траплялися принаймні раз на тиждень, а інші були майже міськими легендами. Багато їх рішень залучали начальників змін або техніків. Ми відфільтрували результати на основі а) реальних потреб аудиторії в масштабі проекту та б) частоти на виробничому майданчику.