ضع بينك وبين الباص مستند! أهمية التوثيق في مساندة إدارة المنتج
سمعت عن حسبة الباص؟ هي حساب عدد أفراد فريقك اللى لو صدمهم باص سيضيع جزء كبير من معرفة المشروع\المنتج التقني لدرجة أنه يتوقف تماما أو يتأثر بشكل كبير. كلما قل هذا العدد، زادت مخاطر المشروع (يعني اذا يتوقف مشروعك اذا خسرت شخص واحد او اثنين، فأنت في خطر).
تجاوز معي سوداوية الفكرة حاليا ولنركز على المخاطرة التي تبرزها هذه الحسبة.
تحتوي المشاريع التقنية على كمية كبيرة من المعلومات. مثلا:
لماذا اختار الفريق قاعدة البيانات تلك مقابل الاخرى؟
أو لماذا قرر بناء هذا الجزء من المنتج بهذة الطريقة؟
ماهو الإجراء المتبع في حال توقف الربط بين خادم المشروع وخادم مزود خدمة رسائل الـ SMS؟
من في الفريق يتابع تزويد ذلك المتجر الإلكتروني الشهير بالبضاعة؟ وعلى أي إيميل تصل أوامر الشراء الجديدة؟
أغلب (إذا لم يكن كل) منهجيات إدارة المشاريع والمواد الأكاديمية تطلب من الفرق كتابة معلومات المشاريع، مثل الأمثلة السابقة، لكي يتم حفظها ومشاركتها بين أفراد الفريق ولكي يسهل الرجوع إليها عند الحاجة. لكن ستكتشف أن التوثيق (اى كتابة المعلومات) يحتل مرتبة منخفضة في إهتمامات معظم الفرق التقنية [1].
ما السبب؟
ينصب تركيز الفرق التقنية من مصممين ومبرمجين على البناء. بناء المنتج هو ما يسمح بإطلاقه للزبائن وبيعه. الإنتهاء من مشروع واستلام سعره هو ما ينعش خزانة الشركة ويسمح لها بدفع الرواتب ومواصلة العمل. ذلك المدير ذو خبرة قليلة في المشاريع التقنية يتوقع أن يرى خصائص جديدة مضافة للمنتج في أخر الشهر، وليس مجموعة من المستندات. وحين يصبح الوقت عاملا مهما سواء للتفاعل مع تغيرات السوق أو اقتراب موعد تسليم المشروع، ستجد أن التوثيق هو أول ما يرمي من الشباك وينصب كل جهد الفريق على البناء.
لأن التوثيق ليس له مردود واضح على بناء المنتج ولكن تكلفته واضحة (الوقت والجهد)، يعتقد البعض أن التوثيق هو ترف خاص بالفرق التقنية الكبيرة، أو أنه كان مهماً في حقبة العمل بالطريقة القديمة (Waterfall) وقامت الطرق الجديدة (Agile methods) بالتقليل منه أو إلغاؤه. ولهذا تتجاهل الكثير من الفريق الصغيرة والمتوسطة وأحيانا الكبيرة التوثيق، وتصبح معلومات المشروع "في الراس مش في الكراس".
ما المشكلة؟
في الحياة المثالية، لا توجد مشكلة في ترك التوثيق، فجميع أعضاء الفريق سيبقون مع المنتج أو المشروع حتى نهايته. وأي معلومة تحتاجها في المشروع سيتذكرها أحد الأعضاء ذو الذاكرة الفولاذية حتى لو أستمر المشروع لـ 11 سنة وأكثر [2].
لكن في الحياة الواقعية، الفريق لا يبقى على حاله. ناس تمرض، ناس يتم نقلها لمشاريع جديدة، ناس تروح شركات منافسة، ناس تترك البلد لسبب أو لأخر، ناس يصدمها باص 🚌. أو بكل بساطة، ناس تنسى. ما ينتج عن كل هذا فقد المشروع لمعلومات قد تكون هامشية وقد تكون بالغة الأهمية (هنا تأتي حسبة الباص). في أحد المنتجات التي عملت عليها، أكاد أجزم ان إحدى الخصائص الصغيرة التى عملنا عليه لا يعرف الفريق الحالي عنها لانها كانت خاصية صغيرة خاصة بإدارة المنتج ويتم تفعيلها من قاعدة البيانات. ترك الفريق الأشخاص الذين عملوا عليها ولم يتم ذكرها في أي مستند. من سيجدها سيكون مبرمجا يقوم بإعادة كتابة برمجة المنتج وقد يكتشف برمجة الخاصية في أحد الملفات.
فقد المعلومات ليس المشكلة الوحيدة من ترك التوثيق. الوقت الذي يضيع في محاولة جلب معلومة والبحث عنها بين أعضاء الفريق يعتبر مهدراً. مشكلة أخرى تظهر حين محاولة زيادة عدد أعضاء الفريق، ويضطر عندها أعضاء الفريق القدامى الى نقل معلومات المشروع شفهيا الى الأعضاء الجدد بشكل متكرر مما يتسبب في إضاعة وقت كان بالإمكان صرفه في بناء المنتج. و قد تتكرر أخطاء سابقة أو تتغير إستراتيجية المنتج لنقص معلومات عُرفت سابقا ولم يقم بتوثيقها أحد وتم نسيانها.
ما الفائدة؟
إذا كان التوثيق ليس له مردود واضح على البناء، لماذا إذا نعطيه أي أهمية؟ دعني أذكر بعض الفوائد من الاهتمام بالتوثيق في بناء وإدارة المنتج.
وضع جميع معلومات المنتج والمشروع الهامة في مكان واحد يسهل الوصول اليه:
يسمح لجميع أعضاء الفريق بمعرفة التفاصيل المختلفة للمنتج دون الحاجة لإضاعة الوقت للبحث عن المعلومة أو المخاطرة بنسيانها.
يعطي الفريق التقني والفريق الإداري والأطراف المهتمة مصدرا واحدا للمعلومات يكون هو المرجع الأساسي في حال الإختلاف ويوحد جهود الجميع في إتجاه واحد يعرفه الكل.
يساعد أعضاء الفريق الجدد على إكتساب معرفة المشروع بسرعة دون الحاجة لإضاعة وقت الفريق لنقلها شفهيا (أو الكتابة بشكل عشوائي في الشات) في كل مرة يضاف عضو جديد للمشروع. كما يقلل من وقوع الأعضاء الجدد في أخطاء تنتج من عدم توفر المعلومات الكافية لهم.
يكشف المناطق الغامضة والغير مدروسة في تخطيط المشروع أو تصميم المنتج. إذا أن التوثيق يتطلب من الكاتب التفكير في المعلومات المذكورة وعلاقتها مع باقي معلومات المشروع، وبالتالي يُظهر المناطق التى تبدو فيه المعلومات ناقصة أو متضاربة. وإذا غفل الكاتب عن نواحي معينة في المشروع، من المتوقع أن يقوم أحد القراء (سواء الأعضاء الحاليين أو الأعضاء الجدد في الفريق) بالسؤال عنها وبالتالي يتم التفكير فيها و إضافتها لمستندات التوثيق.
يساهم توثيق معلومات سوق المنتج ومعلومات مستخدمي المشروع في إكتساب خبرة مفيدة في مجال المنتج، مما ينعكس على الحلول والأفكار التي يتم العمل بها في صناعة المنتج (ما يسمى بـ Subject Matter Expert أو خبير موضوعي)
يساعد توثيق المشروع في بناء المواد التسويقية للمشروع وبناء دليل المستخدم ونقل معلومات المشروع لفرق الصيانة أو الفرق التشغيلية، وأيضا ينقلها للفرق الخارجية في حالة الـ API أو في حالة المشاريع المفتوحة المصدر.
مع وجود فوائد أخرى، سأكتفي بهذا القدر.
إذا كان فريق مشروعي صغير أو شركتي صغيرة لا أحتاج الى التوثيق، صحيح؟
بالعكس! معامل الباص عندك عالي مقارنة بالفرق الكبيرة، أي أن خسارة أي فرد من فريقك تؤدي الى ضياع جزء كبير من المشروع. كما أنك سترغب في تكبير الفريق والشركة في حال نجاح مشروعك، وما توفره في عدم التوثيق ستخسره في تعليم و تعريف الأعضاء الجدد بتفاصيل مشروعك. وقد تقع في بعض الأخطاء التي كان بالإمكان تفاديها لو كان لدى فريقك معلومات جاهزة.
ما عندنا وقت للكتابة الآن! مشغولين عشان نطلق المنتج ونلحق نمسك السوق!
أتفهم ذلك. هنا أنت تاخذ مغامرة (محسوبة أو غير محسوبة) بصرف الوقت والجهد اللازمين للتوثيق في بناء المنتج. المغامرات جزء من عالم الأعمال والتجارة، ونتيجتها عادة هي ما تقرر إذا كانت "قيادة حكيمة وبعد نظر" أو "تهور وقلة خبرة". قد لا تكون نتيجتك دراماتيكية بهذا الشكل في الاتجاهين، وكل حالة لها ظروفها. فقط جاملني واصرف القليل من الوقت للتفكير في هذا القرار.
لكن ألم تلغي طرق الأجايل الحاجة الى التوثيق؟
يشير البعض إلى أن بيان الاجايل ينص على أن "البرمجيات الصالحة للإستخدام أكثر فائدة من التوثيق الشامل". قد يعطي هذا انطباعاً أنه من الأفضل صرف الوقت في بناء البرنامج أو المشروع بدلا من الكتابة والتوثيق. لكن ما يُغفل هنا أن "أكثر فائدة" لم يقصد به أن العنصر الأخر لا قيمة له، بل أنه عند المقارنة بين حالة "توثيق شامل وبرنامج غير صالح للإستخدام" وحالة "توثيق غير شامل وبرنامج صالح للإستخدام" فإن الحالة الثانية هي المرغوبة لأننا نريد البرنامج (أو المنتج) أكثر من التوثيق الشامل [3]. مهندس البرمجيات والكاتب سكوت أمبلر يشرح هذة النقطة بقوله "التوثيق الجيد مفيد لمساعدة الناس في فهم كيف بنى البرنامج وكيف يتم إستخدامه، لكن الهدف الرئيسي من التطوير هو بناء البرنامج وليس كتابة المستندات".
ما الفرق بين التوثيق الشامل والتوثيق الجيد؟
في عهد طريقة الشلال (Waterfall)، كان يتوقع أن يتم توثيق كل تفاصيل المشروع كمتطلبات المستخدمين والتصميم الدقيق المشروع قبل البدء بالبرمجة أو البناء. كل فقرة ضائعة أو معلومة خاطئة أو قابلة للتأويل في التوثيق كانت تؤدي الى خسائر كبيرة لاعتماد المراحل التالية في المشروع على هذا التوثيق. تؤدى محاولة توثيق كامل المشروع (توثيق شامل) الى إنشاء مستندات ضخمة من الصعب قراءتها أو تحديثها [4].
طرق الأجايل أخذت بالاعتبار كلفة التوثيق من جهد ووقت، واقتصرت التوثيق على المعلومات التى يتوقع لها عدم التغير بشكل كبير، مثل فكرة المشروع والمتطلبات الرئيسية للمستخدمين والشرح العام لتصميم المشروع بدون الدخول في التفاصيل والتي من المتوقع لها أن تتغير عندما يبدأ العمل على المشروع. الهدف من هذا تقليل تكلفة الكتابة، وجعل المستندات أسهل للقراءة، وتقليل الحاجة الى تحديث الكتابة مع التغييرات التي تحصل في المشروع، مع الإبقاء على منافع التوثيق من توحيد المعلومة لأعضاء الفريق والمرور بنظرة فاحصة على جميع أقسام المشروع الهامة.
هنالك المزيد من النصائح للحصول على توثيق جيد في المشاريع العاملة بطرق الأجايل، لكن سأتركها لمقالة أخرى لكي لا يطول الحديث هنا. أتمنى أن أرى المزيد من الأهتمام بالتوثيق في المشاريع التقنية في المستقبل. حتى ألقاك في مقالة جديدة، أتركك بحفظ الله (و أنظر الى اليسار واليمين قبل قطع الشارع، حتى لو كان الشارع بإتجاه واحد!)
الملاحظات
[1] ليس لدي بيانات لتأكيد أو نفي هذة النقطة. فقط الملاحظة أثناء عملي في عدة فرق وقراءة المقالات المتعلقة بالتوثيق.
[2] لعبة كملنا، المشروع الذي أعتز بالعمل فيه، أكملت 11 سنة وشهرين عند كتابة هذة السطور، ولا يزال العمل عليها مستمر.
[3] طبعاً إذا أمكن الحصول على برنامج صالح للإستخدام وتوثيق شامل، فهذا شيء عظيم. لكن لأن هذا الشيء نادر ومكلف، كان الحصول على البرنامج أكثر قيمة.
[4] توثيق مشروع التخرج الذي عملت عليه قبل 15 سنة تجاوز الـ 300 صفحة، ولو كتبته الأن لما تجاوز ال20 صفحة في أسوء تقدير.
المصادر
http://www.agilemodeling.com/essays/agileDocumentationBestPractices.htm