اشتباهات در مستندسازی
بسیاری از مستندات عموماً غیر مفید و یا اغلب اصلاً وجود ندارند. نبود اطلاعات باعث رخداد بیشتر اشکالات در استفاده از یک سیستم و در نتیجه اجبار کاربران در مراجعه به افراد غیر خبره و گردش اطلاعات غلط می‌گردد. در این قسمت نواقص و اشکالات موجود در فرایند مستندسازی و چرایی بروز آنها بررسی می‌شود.
زمانی که از هیچ راهی به موفقیت نرسیدید، به مستندات مراجعه کنید
سیاری از مواقع، کاربران به علت عدم مراجعه به مستندات و مطالعه آن با بی‌احترامی مورد سرزنش قرار می‌گیرند در حالی که به سختی می‌توان فقط آنان را مقصر معرفی کرد. به جز در موارد نادر و استثنایی، مستنداتی اگر وجود داشته باشد اغلب بی‌کیفیت، ناکامل و بد-سازماندهی شده هستند.
کاهش کیفیت مستندات باعث روی‌گردانی کاربران از آن می‌شود. عدم مراجعه کاربران به مستندات موجب عدم تولید و نگهداری آن توسط شرکت‌ها می‌شود؛ اگر کسی به آن مراجعه نمی‌کند، چرا زحمت تولید آن را متحمل شوند؟ نتیجه‌ی محتوم این چرخه‌ی استدلالی، کنار گذاشتن کامل مستندسازی است، در حالی که مستندسازی مهم است و لازم است با جدیت بیشتری به آن پرداخته شود.
چنین آشفتگی‌ای را می‌توان در بازار بازی‌های کامپیوتری که با بی‌شرمی کامل بدون راهنمای استفاده فروخته می‌شوند مشاهده کرد، زمانی که مستندات در قالب جداگانه تحت عنوان راهنمای استراتژی شامل نمودارها، جداول و سایر اطلاعات اساسی به‌صورت جداگانه به فروش می‌رسند. پشتوانه‌ی این وضعیت احتمالاً الزامات اقتصادی و منافع ناشی از "فروش جداگانه" می‌باشد. صرف‌نظر از این جنبه‌ی منفعت طلبی، نرم‌افزاری کاراتر خواهد بود که دارای مستندات بهتری باشد.
موضوع خیلی ساده است، نیازی به مستندسازی ندارد!
یکی از مهلک‌ترین نگرش‌ها در صنعت نرم‌افزار، اعتقاد به این مطلب است که برنامه‌ای که خوب طراحی یا نوشته شده باشد نیازی به مستدسازی ندارد؛ البته که چنین اندیشه‌ای مضحک و خنده‌دار است. اولین کامپیوترهای مکینتاش به همراه یک کتاب کلفت و ضخیم عرضه می‌شدند.
در این زمانه شاید بتوان کتابی را که در مورد نحوه استفاده از موشواره یا ماوس نوشته شده است به مسخره گرفت؛ اما باید توجه داشت که کاربران ابتدایی نه تنها در مورد چگونگی استفاده از ماوس، بلکه در مورد کاربرد کلیدهای میانبر و سایر تکنیک‌های قابل استفاده آموزش قبلی ندیده بودند. کاربری که راهنمای استفاده از مکینتاش را خوانده بود قادر به استفاده کامل از یک کامپیوتر مکینتاش بود. با توجه به حجم عظیم پشتیبانی مکینتاش می‌توان گفت که چنان وضعیتی حالا دیگر وجود ندارد.
دو جنبه‌ی این مشکل عبارت است از:
- فنآوری اطلاعات خیلی پیچیده‌تر شده است
- به مستندسازی توجه کمتری شده است
بعضی مستندات خیلی خوب طراحی می‌شوند مثل نمودارها و دستورالعمل‌های اپل در زمینه کارت‌های حافظه و ارتقاء آن که نمونه مشابه ندارند. امروزه خیلی کم مستندات چگونگی استفاده را می‌بینیم.
این وضعیت وقتی در موضوع نرم‌افزارهای کاربردی هم اتفاق می‌افتد به پیامدهای خیلی خیلی بدتری ختم می‌گردد. این که فکر کنیم تمامی کاربران می‌دانند چگونه از ماوس استفاده کنند یا می‌توانند تصور درستی از چگونگی استفاده از آن داشته باشند (نه این که مثل یک میکروفون از آن برای فرمان به کامپیوتر استفاده کنند) قابل قبول است. برنامه‌های کاربردی بیشتر اوقات دارای حجم عظیمی از دانش، قابلیت‌ها و موضوعات جدید اعلام نشده هستند. هر برنامه‌ای نوع جدیدی از کارها را انجام می‌دهد بنابراین لازم است کاربر را به طریقی از این توانایی‌ها آگاه کرد.
برنامه‌های تبلیغاتی‌ای هست که به این صورت بیان می‌شوند: " به سادگی: یک دو سه ". اولین قدم همیشه ساده است و احتمالاً قبلاً انجام داده‌اید. گام دوم هم معمولاً تقریباً ساده است. قدم سوم هم ... هی. ساخت فیلم امپراطور روم به سادگی یک 1-2-3 است:
- تولد امپراطور یک جایی در رم
- تصمیم به ساخت یک امپراطوری جدید
- انتخاب تعدادی هوادار متعصب و جان‌سپار از بین مردم قوی یا پولدار که تعدادی سرباز برای تشکیل هسته ارتش شکست ناپذیرتان استخدام خواهند کرد و سپس بنیان یک امپراطوری عظیم با اقتصادی پیشرفته که هیچ کس نتواند تصور و جرأت جنگ با سپاهیان شما را در سر بپروراند.
کار به این بزرگی با همین سه قدم انجام می‌شود، پس نسبتاً باید ساده باشد. دیدن عبارت " مطابق دستورالعمل اقدام شود " یا "follow the prompts" حتی در یک کار کوچک هم آدم را مستأصل می‌کند!
راهنمای بر خط بهتر است
راهنمای بر خط (Online Help) می‌تواند بالقوه بهتر از مستندسازی باشد، اما نیست زیرا که اول به این دلیل بهتر به نظر می‌رسد که لازم نیست حتماً همزمان با خود محصول تولید شود و تولیدکننده یکی دو هفته فرصت بیشتر برای تکمیل آن در اختیار دارد. دوم این که بیشتر راهنماهای بر خط به علت نبود سازماندهی و یا سازماندهی بد و ضعیف کلاً قابل استفاده نیستند.
به‌عنوان مثال با بررسی راهنمای بر خط اپل نمی‌توان چیزی از آن یاد گرفت مگر این که واقعاً قصد انجام کار مورد نظرتان را داشته داشته باشد به این صورت که امکان مطالعه مراحل بعدی کار را ندارید مگر این که مراحل قبلی را گام به گام انجام داده باشید.
این نمونه‌ای از یک نوع سازماندهی خیلی بد است؛ فرآیندی را تصور کنید که در مراحل ابتدایی آن یک سری اعمال غیر قابل بازگشت انجام داده‌اید و حالا امکان تکمیل آن را ندارید و یا به دلیل تأثیرات جانبی یک عمل انجام آن قابل قبول نیست. فکر کنید اگر در گام سوم یک دیسک را فرمت کنید و در گام پنجم از شما خواسته شود همان دیسک را در درایو قرار دهید در حالی که کپی آن را هم در اختیار ندارید در چه وضعیتی گرفتار می‌شوید!
دوست دارم بگویم: " کار سختیه بدونیم اونا چی فکر می‌کردند "، اما متأسفانه این طور نیست. این موضوع مشخص است که آنها سیستم راهنمایی‌ای می‌خواسته‌اند که دست کاربران را بگیرد و در تمام مراحل کار آنها را گام به گام همراهی کند و اجازه ندهد مرتکب خطایی گردند.
چنین چیزی امکان پذیر نیست؛ حتی اگر کاملاً مطمئن باشید که کاربر گام‌های بعدی را هم حتماً انجام خواهد داد چه تضمینی هست که مراحل قبلی را درست انجام داده باشد؟ اگر نتوان گام‌های بعدی یک فرایند را دید تا بفهمیم دقیقاً چکار می‌کند مشکل بتوان تصور کرد که کاربران هیچ وقت در انجام فرایند اشتباه نکنند.
زمانی در یک تیم پشتیبانی فنی کار می‌کردم شخصی تماس گرفت، وی می‌خواست هارد دیسکی که از داده‌های مهم کاملا پر شده بود را در یک سرور جدید نصب کند. این کاربر دستورالعمل‌های گفته شده در دفترچه راهنما درباره افزودن یک هارد جدید را گام به گام انجام داده بود. او وقتی با تیم پشتیبان تماس گرفت که درست لحظاتی قبل از آن، دیسک را فرمت کرده بود. در نسخه‌های بعدی مستندات بین اضافه کردن یک هارد دارای داده و یک هارد نو فرمت نشده تمایز قائل شدیم، عمیقاً آرزو کردم ایکاش این کار را قبلاً انجام داده بودیم. این مشکل با وجود مستندات نوشته‌شده روی کاغذ اتفاق افتاده بود اما در اصل کار تغییری ایجاد نمی‌کند و پیام آن مشخص و واضح است: بهتر است کاربر قبل از شروع به اجرای یک فرایند،امکان مطالعه و بررسی و درک کلی آن را داشته باشد.
راهنماهای برخط خوبی هم وجود دارد. استفاده از راهنمای برخطی که از تمامی امتیازات و ویژگی‌های یک رسانه استفاده می‌کند لذت‌بخش است. در این زمینه می‌توان از مستندات Sun Java API نام برد. از طرف دیگر این مستندات به‌صورت فشرده با حجم 40 مگابایت قابل دانلود است. این حجم عظیم از این راهنمای برخط موفق اشاره به یک مشکل اساسی دارد: اغلب راهنماهای برخط، مستندات قابل ارجاع کاملی نیستند بلکه آمیزه‌ای پرسش-و-پاسخ-مانند از موضوعات و شامل موارد مشترک و بیشتر-مطرح‌شده هستند.
تأمین استفاده کاربر از شاخص‌ها
شاخص‌گذاری هنر فراموش شده‌ایست. ایده‌ی شاخص‌گذاری این است که فهرستی از تمام کلمات و موضوعات مورد جستجو را ارائه و شما را به متن کامل آن موضوع هدایت کند. در اغلب مستندسازی‌های کامپیوتری مدرن، هر مضمون مورد نظری با جستجوی تنها یک کلمه از آن پیدا می‌شود. این کاری زیبا و ساده است اما دقیقاً عکس آن چیزی است که یک شاخص باید انجام دهد.
اگر من لغات بکار رفته در یک موضوع را بدانم احتمالاً دیگر نیازی به شاخص‌ها نخواهم داشت. از شاخص موقعی استفاده می‌کنند که نمی‌دانند شما از چه کلماتی برای نامگذاری استفاده کرده‌اید (موضوع مورد نظر را چه نامیده‌اید)، اما می‌توانم آن را با کلمات مورد نظر خودم توصیف کنم. این کلمات هم باید در شاخص وجود داشته باشند.
می‌خواهید شاخص خوبی ایجاد کنید؟ از دیگران بخواهید در متون نوشته شده شما جستجو کنند اما از ایشان بخواهید قبل از نگاه به شاخص‌ها، کلماتی را که در ذهن دارند روی کاغذ بنویسند. حال مطمئن شوید تمام آن کلمات در شاخص شما وجود دارند. به این ترتیب تعجب خواهید کرد که چه کلماتی را از قلم انداخته بودید.
نبود یک شاخص خوب می‌تواند حتی کامل‌ترین مستندسازی‌ها را زیر سؤال ببرد. صرفاً ارائه‌ی یک پاسخ به کاربر کافی نیست، او باید بتواند خودش جواب را پیدا کند.
نکته پایانی
مستندسازی مهم است، کار پرهزینه‌ای هم هست اما احتمالاً هزینه‌ی آن از راه‌اندازی تیم‌های پشتیبانی فنی که به‌عنوان جایگزین آن مطرح می‌شوند کمتر است. نمی‌توان گفت تمامی مستندسازی‌ها ضعیف است، مستندسازی‌های بسیار خوبی را هم می‌توانید ببینید. با این وجود شرکت‌های زیادی حتی برای خوب نوشتن هم از خود تلاش و انگیزه‌ای نشان نمی‌دهند.
کار عملی: یکی از برنامه‌هایی که زیاد استفاده می‌کنید را بررسی کنید. آیا مستندسازی شده است؟ سعی کنید جنبه‌های مختلف آن را بررسی کنید. (Peter Seebach, 2003)
منابع و مراجع
[1] Peter Seebach, Freelance. 2003. The cranky user: The importance of documentation, Discover what's missing in today's documentation efforts, and why it's gone. IBM Development. [Online] IBM, November 14, 2003.