ЦеНеБлог

Як написати поганий мануал

« Дерево замість XML | | Проблема термінології »

08 березня 2009

Як написати поганий мануал

Привіт усім! Нехай щастить вашому бізнесу!

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

  • Ваш бізнес загнувся, тому у вас нема зайвих грошей, щоб відривати людей від роботи і змушувати їх писати мануали.
  • Ви пишете мануал про те, в чому самі не розбираєтесь. У вас є лише щоденні п'ятихвилинні консультації з менеджером команди розробників, котрий, так само, як і ви, має диплом політолога.
  • У вас нема часу, щоб написати якісну інструкцію.
  • Вам лінь, облом, і взагалі, нащо воно треба? Лише для галочки.
  • Ваша програма містить безліч незадокументованих можливостей, які до того, як їх виявили тестери, вважались багами, і ще невідомо, скільки їх незадокументовано. Користувачам бажано не знати про них — нехай краще лають тупий мануал, ніж тупих розробників.
  • Ви хочете зіпсувати бізнес вашому начальству і перейти до конкурентів (або почати власний бізнес).
  • Вашому менеджеру не подобаються занадто технічні мануали, де нема ні слова про бізнес.
  • Ваша цільова аудиторія — офісні бізнесмени, що не відрізняють DVD-RW від підставки для кави. Єдине слово, яке вони зрозуміють у мануалі — БІЗНЕ$ (і вони будуть задоволені).
  • Ваш бізнес занадто успішно йде вгору, щоб на нього могли вплинути погані мануали
  • Придумайте щось своє, бажано про бізнес...

Причин, як бачите, вдосталь. Отже, декілька порад, як втілити в життя ваш ідеал:

  1. Запевніть користувача, що ваш програмний продукт є ідеальним рішенням для його бізнесу. Йому буде приємно дізнатися про це після того, як програма заглючила остаточно, і він вирішив вдатись до крайнього заходу — прочитати мануал.
  2. Детально опишіть усе, до чого можна дійти власним розумом, навіть не знаючи про існування вашого програмного продукту. Приклад: «Меню Файл використовується для дій з файлами. Файл — область диску, відведена для збереження даних (наприклад, ваших документів). Для зручності користувача файли на диску згруповані в папки. За допомогою даного меню ви можете зберегти файл у вибрану вами папку, відкрити збережений раніше документ,…»
  3. Обов'язково мають бути білі плями — змусьте користувача працювати головою, щоб він не отупів остаточно. Відсутність у вас зайвої кваліфікації автоматично сприятиме їх появі — в іншому разі, свідомо уникайте зайвої деталізації особливостей, важких для розуміння.
  4. Водночас, вам необхідно набрати певну кількість рядків. Лийте воду. Поговоріть про бізнес: «Функція fsysfoobar() виконує дії з системною областю пам'яті. В системній області пам'яті може міститись конфіденційна інформація, тому неправильний виклик даної функції становить небезпеку для вашого бізнесу. Будьте обережні, перед використанням перечитайте даний мануал!»
  5. Щоб не складалось враження, що мануал писали гуманітарії, додайте трохи технічних подробиць. Бажано в тій галузі, з якою ви погано розбираєтесь: це дозволить вам написати по-справжньому незрозумілий опис, який змусить користувачів відчути себе тупими ламерами. Якщо ж ви знаєте всю свою програму від А до Я, застосуйте аналогічний прийом: не діліться з користувачем усією необхідною інформацією, але обов'язково наведіть приклад «вищого пілотажу».
  6. Структуруйте матеріали якомога хаотичніше. «Всі тварини діляться на тих, що належать імператору, бальзамованих, приручених, молочних поросят, сирен, казкових, бродячих собак, тих, що бігають, як божевільні, незліченних, намальованих тонким пензлем з верблюжої шерсті, тих, що розбили вазу, схожих здалеку на мух.» Застосуйте це до можливостей роботи програми — і отримайте структуру мануалу-лабіранту, в якому користувач блукатиме роками, час від часу дивуючись новим можливостям програми.
  7. Самореклама. Її слід втикати в найнесподіваніших місцях, включаючи інструкції для роботи в аварійних ситуаціях. Зрозуміло, що ваша програма ідеальна, тому тему програмних збоїв обминайте, а висвітлюйте лише ті проблеми, що виникають у особливо тупих чайників. «Після команди «Заблокувати файлову систему назавжди» файли на диску перестали відкриватись — Відформатуйте диск. Заново встановіть foobar® — це оптимальне рішення для успішного ведення бізнесу.» Про саморекламу на початковій сторінці вже згадувалось.
  8. Переконвертуйте мануал у якийсь із хелпових форматів і дайте йому красиву назву: «Довідковий центр», «Тур по foobar®», «Офіс робота-консультанта». Самого робота-консультанта теж слід зробити у вигляді інтерактивної тривимірної моделі. Це, звичайно, не підвищить ефективність мануалу, зате підніме кілобайтність (користувачі люблять великі мануали, чи не так?)
    1. Засоби пошуку. Незалежно від запиту, в результатах пошуку мають з'являтися ще й ліві статті про ефективність бізнесу, базованого на вашій продукції.
    2. Не забудьте напартачити з кодуванням. Якщо половина тексту перетворюється на кракозяблики, квадратики, Ђ чи знаки питання, ви досягли успіху. Змусьте користувача придбати «робота-перекладача» для спілкування з вашим «роботом-консультатнтом».
    3. Захистіть мануал від крадіжки інформації: найкраще зробити його як самостійну програму, що виводить інформацію у вигляді графічного зображення. В поєднанні з попереднім пунктом це буде особливо весело.
  9. Ще раз. Кожна друга стаття мануалу має якимось чином зачіпати тему надзвичаної ефективності бізнесу з вашою продукцією. Якщо ви ще не досягли достатньої кількості самореклами, відредагуйте мануал іще раз — це допоможе вашому бізнесу. Вода про успішний бізнес підніме вашу кілобайтність. Або ж, якщо вам необхідно втиснутись у певні межі, пожертвуйте технічними інструкціями.
  10. Приклади практичного застосування програми. Зробіть їх якомога абстрактнішими, відірваними від практичних задач типового користувача. Якщо це мануал з асемблера — напишіть код для бухгалтерського обліку. Якщо об'єктноорієнтована мова програмування — маніпуляції з foo, bar та іншими абстракціями. Якщо прикладна програма — скріншоти з найменш використовуваними можливостями. Ну а те, з чим користувач має справу щодня, слід залишити без готових зразків: все одно користувач буде змушений до цього додуматись.

Р.Ѕ. Що б там не казали про погані мануали, є в них і позитивна сторона: вони змушують користувача мислити, експериментувати, привчають його ставити все під сумнів. Дотримуйтесь даного мануалу — підніміть інтелект користувача. А заодно зекономте свій час і сили.

Р.Р.Ѕ. Даний мануал не є ідеальним зразком описаного «поганого мануалу», оскільки він не висвітлює неоціненне значення ЦеНеБлогу для успішного ведення вашого бізнесу.

Автор: Python. Опубліковано 08 березня 2009 5:24
Змінено 15 травня 2009 14:34
Категорії: Зроби щось погане