تدبير المشاريع
كيف تحرّر دفتر التحملات لمشروع برمجي أو موقع ويب
دفتر التحملات البرمجي الجيد يصف الحاجة لا الحل: من هم المستخدمون، وما الذي ينبغي أن يتمكنوا من فعله، ومتى تُعدّ وظيفة ما منجزة، وما القيود المحيطة بالمشروع (الأمن، والاستضافة، واللغات، والميزانية، والآجال). ويتوزّع على ثمانية أبواب، من الأهداف المهنية إلى ملكية الشيفرة والصيانة. وإذا أُحسن تحريره، صار مرجعًا مشتركًا بين الزبون ومقدّم الخدمة، ثم امتد أثناء المشروع في شكل قائمة مهام رشيقة (backlog).
باختصار
- دفتر التحملات يحمي الطرفين معًا: يحدّد ما هو منتظر، وما سيُسلَّم، وكيف سيُتحقَّق منه.
- صِف الحاجيات والنتائج المنتظرة، لا شاشات أو تقنيات مفروضة دون مبرّر.
- ينبغي أن تكون لكل وظيفة أولوية ومعايير قبول قابلة للتحقق.
- المتطلبات غير الوظيفية (الأمن، والأداء، والعربية من اليمين إلى اليسار، والاستضافة، والمعطيات الشخصية) لا تقل وزنًا عن الوظائف نفسها.
- الإطار الثابت والقائمة الحية يكمّل أحدهما الآخر: الأول يحدّد الأهداف والميزانية والقواعد، والثاني يتكفّل بالتفاصيل.
ما الغاية من دفتر التحملات في مشروع ويب؟
يحوّل دفتر التحملات حاجةً مهنية إلى انتظارات واضحة يفهمها فريق التطوير. وبالنسبة إلى الإدارة العامة أو مديرية نظم المعلومات، فهو الأداة التي تتيح مقارنة العروض، وتقدير ميزانية واقعية، وقيادة المشروع دون سوء فهم.
فهو يحمي الزبون: فمن دون وثيقة مرجعية، يصعب إثبات أن وظيفة ما ناقصة أو أن تسليمًا ما غير مطابق. ويحمي أيضًا مقدّم الخدمة: فالنطاق المكتوب يحدّ من الطلبات التي تُضاف دون أن تُقدَّر كلفتها.
وحين تصبح الوثيقة جاهزة، يفصّل دليلنا حول اختيار وكالة تطوير في الدار البيضاء الأسئلة التي ينبغي طرحها على المرشحين.
ما الهيكلة المناسبة لتحرير دفتر تحملات برمجي؟
إليك تصميمًا نموذجيًا يُكيَّف حسب حجم المشروع. نبدأ بالـ«لماذا» قبل الـ«ماذا»، وبالـ«ماذا» قبل الـ«كيف».
- السياق والأهداف: الوضع الحالي، والمشكلة المطلوب حلّها، والمؤشرات المهنية التي ستتابعها المقاولة بنفسها للحكم على النتيجة (مدة معالجة ملف، وأخطاء الإدخال، والمهام التي ما زالت تُنجز يدويًا).
- المستخدمون وشخصياتهم النموذجية (personas): من سيستعمل الأداة (الزبناء، والمندوبون التجاريون، والمصالح الإدارية الداخلية، والمديرون)، وعلى أي جهاز، وبأي لغة.
- النطاق الوظيفي: الحاجيات معبَّرًا عنها في شكل قصص مستخدم (user stories)، لكل منها معايير قبولها وأولويتها.
- المتطلبات غير الوظيفية: الأداء، والأمن، وإمكانية الولوج، والاستضافة، واللغات.
- التكاملات: نظام تخطيط موارد المقاولة (ERP)، ونظام تدبير العلاقة مع الزبناء (CRM)، والبريد، وبوابة الأداء الإلكتروني، والمصادقة الموحّدة (SSO)، وواجهات برمجة التطبيقات (API) لدى الشركاء.
- المعطيات والترحيل: المعطيات الحالية الواجب استرجاعها، وجودتها، ومدد الاحتفاظ بها، والمعطيات الشخصية المعنية.
- القيود والميزانية والجدول الزمني: نطاق تقريبي للميزانية، وأجل ملزم أو مرغوب فيه، والقيود التنظيمية أو الداخلية.
- المُخرَجات والملكية والصيانة: ما الذي يُسلَّم، ولمن تعود ملكية الشيفرة والملكية الفكرية، وكيف ستتم صيانة البرنامج.
بضع صفحات محكمة البناء خير من وثيقة ضخمة لا يعيد أحد قراءتها. وأرفِق في الملاحق النماذج الأولية للشاشات ولقطات من النظام الحالي.
كيف تصف الوظائف: قصص المستخدم ومعايير القبول
الصيغة الأكثر نجاعة هي قصة المستخدم: «بصفتي [مستخدمًا]، أريد [إجراءً] من أجل [فائدة]». فهي تفرض توضيح من صاحب الحاجة ولماذا.
وترافق كل قصة معاييرُ قبول: شروط قابلة للتحقق تسمح بالقول، دون جدال، إن كانت الوظيفة منجزة. مثلًا، في حالة طلب عطلة:
- يرى الأجير رصيده قبل تأكيد طلبه؛
- يتلقى المسؤول المباشر إشعارًا ويمكنه القبول أو الرفض مع تعليق؛
- يُمنع الطلب الذي يتداخل مع فترة سبق قبولها، مع رسالة صريحة توضّح السبب.
أضف أولوية لكل قصة، مثلًا بطريقة MoSCoW (Must, Should, Could, Won't: ضروري، مهم، مرغوب فيه، مستبعد من هذه النسخة). فهي التي ستسمح بالتحكيم إذا ضاقت الميزانية، وبتحديد نسخة أولى قابلة للاستعمال فعلًا.
المتطلبات غير الوظيفية: الأمن والأداء واللغات والاستضافة
كثيرًا ما تُنسى هذه المتطلبات، ويكون تداركها لاحقًا مكلفًا. صِف المستوى المنتظر، لا تقنية بعينها.
- الأداء: عدد المستخدمين المتزامنين المتوقع، وزمن الاستجابة المقبول على الشاشات الحرجة، والاستعمال عبر شبكة الهاتف المحمول.
- الأمن: الأدوار والصلاحيات، والمصادقة، وتسجيل العمليات الحساسة، والنسخ الاحتياطي والاسترجاع. واسأل مقدّم الخدمة أيضًا كيف يحمي معطياتك من جهته؛ فشهادة ISO/IEC 27001 مؤشر على ذلك، كما يوضّح مقالنا حول أمن المعطيات لدى مقدّم الخدمة.
- المعطيات الشخصية: في المغرب، تخضع معالجتها للقانون 09-08 المتعلق بحماية الأشخاص الذاتيين تجاه معالجة المعطيات ذات الطابع الشخصي. والإجراءات لدى اللجنة الوطنية لمراقبة حماية المعطيات ذات الطابع الشخصي (CNDP) تقع على عاتق المسؤول عن المعالجة، أي المقاولة الزبونة من حيث المبدأ؛ فحدّد ما يجب على مقدّم الخدمة تقديمه لإعدادها (الغايات، وفئات المعطيات، والتدابير الأمنية).
- إمكانية الولوج: التباين بين الألوان، والتنقل بلوحة المفاتيح، والتوافق مع قارئات الشاشة؛ ويوفّر مرجع WCAG الصادر عن W3C لغة مشتركة لتحديد المستوى المنتظر.
- الاستضافة: سحابة أو خوادم داخلية، وموقع تخزين المعطيات إذا كان مفروضًا (فنقل المعطيات الشخصية خارج المغرب يؤطّره هو الآخر القانون 09-08)، وبيئتا الاختبار والإنتاج.
- اللغات: الفرنسية والعربية والإنجليزية، بل والأمازيغية أيضًا. فالعربية تفرض واجهة من اليمين إلى اليسار (RTL): تخطيط معكوس، وخطوط ملائمة، وحقول تمزج بين العربية والأرقام. إذا خُطّط لها منذ البداية فهي خيار تصميمي؛ وإذا أُضيفت في آخر المشروع فهي ورش قائم بذاته.
التكاملات والمعطيات والترحيل: الجزء الذي يُستهان به
نادرًا ما يعمل برنامج مهني بمعزل عن غيره. فلكل نظام يجب ربطه، حدّد ما الذي ينبغي أن يتبادله، وفي أي اتجاه، وبأي وتيرة، ومن هو المخاطَب التقني المسؤول عنه، وهل توجد وثائق لواجهة برمجته (API) وبيئة للاختبار. فتكامل لا يتجاوب مزوّده قد يعطّل مشروعًا بأكمله: ومن الأفضل معرفة ذلك قبل التوقيع.
واسترجاع المعطيات يستحق العناية نفسها. اذكر المصادر (ملفات Excel، أو تطبيق قديم، أو قاعدة معطيات قائمة)، وقدّر جودتها بصدق (تكرارات، وحقول فارغة، وصيغ غير متناسقة)، وحدّد من سيتكفّل بتنقيتها. وخطّط على الأقل لترحيل تجريبي على بيئة الاختبار قبل الانتقال الفعلي، ولحلّ يتيح التراجع إذا فشل.
الميزانية والآجال والمُخرَجات وملكية الشيفرة
تتردد مقاولات كثيرة في الإفصاح عن ميزانيتها. ومع ذلك، فإن نطاقًا تقريبيًا للميزانية يسمح لمقدّمي الخدمات باقتراح حلّ ملائم بدل عروض يستحيل مقارنتها. وميّز أيضًا بين الأجل الملزم والتاريخ المرغوب فيه.
وينبغي أن يرفع باب المُخرَجات كل لبس:
- تسليم الشيفرة المصدرية في مستودع تملك المقاولة صلاحيات الولوج إليه؛
- الملكية الفكرية للشيفرة المطوَّرة لحسابك، وشروط استعمال المكوّنات المعاد استخدامها أو مفتوحة المصدر؛ ولا تفترض أن أداء كلفة التطوير يكفي لتصبح مالكًا له، بل اطلب تدوين التنازل عن الحقوق كتابةً؛
- التوثيق التقني، والولوج إلى حسابات الاستضافة وأسماء النطاقات باسم المقاولة؛
- شروط الصيانة: التصحيحات، والتطويرات، وآجال التدخل، وقابلية الاسترجاع (réversibilité) إذا غيّرت مقدّم الخدمة.
هذه البنود من صميم العقد: اعرضها على مختص قانوني بدل الاعتماد على نموذج عام.
دفتر تحملات ثابت أم قائمة مهام رشيقة: كيف تجمع بينهما؟
دفتر التحملات «الجزافي» الذي يجمّد النطاق كله يطمئن مصلحة المشتريات، لكنه يفترض أن جميع الحاجيات معروفة مسبقًا، وهو أمر نادر الحدوث. وفي المقابل، فإن قائمة مهام (backlog) بلا إطار مكتوب تترك الزبون دون ضمانة على الميزانية. والتوليفة التي تنجح هي:
- تثبيت ما لا ينبغي أن يتغير في الوثيقة: الأهداف، والمستخدمون، والمتطلبات غير الوظيفية، والميزانية، والآجال، والمُخرَجات، والملكية؛
- التعبير عن النطاق الوظيفي بقصص مستخدم مرتّبة حسب الأولوية، تصبح هي القائمة الأولية للمهام؛
- تخصيص مرحلة استكشاف لتدقيق القصص ذات الأولوية؛
- المصادقة عند كل دورة على بيئة الاختبار، والتحكيم في كل طلب جديد بتعويض قصة أقل أولوية.
وهكذا تعمل Codevista Innovations في مشاريعها التطويرية: مرحلة استكشاف وتصميم (UX/UI)، ثم دورات عمل (sprints) مدة كل منها أسبوعان، مع تسليمات منتظمة على بيئة staging للمصادقة. وإذا كنت مترددًا في الطريقة التي تُبقي بها هذه القائمة حيّة، فإن مقارنتنا Scrum أم Kanban تساعدك على الاختيار.
ومن جهة الزبون، يجب على الشخص الذي يقود المشروع أن يضبط النطاق والمخاطر والأطراف المعنية: وهي بالضبط مجالات يغطيها تكوين PMP®، الذي يُعِدّ لشهادة PMI.
الأخطاء الشائعة في دفتر تحملات تطبيق
- وصف حلّ بدل حاجة: «زر Excel في أعلى اليمين» بدل «يجب أن تتمكن الموارد البشرية من استغلال السجل التاريخي في أدواتها». وهكذا لا يعود بإمكان مقدّم الخدمة اقتراح ما هو أفضل.
- غياب ترتيب الأولويات: حين يكون كل شيء ضروريًا، لا يعود شيء ضروريًا، ويتحوّل أول تحكيم في الميزانية إلى نزاع.
- إغفال معايير القبول: يتحوّل الاختبار والتسلّم إلى جدال حول التأويل.
- التحرير بشكل منفرد: وثيقة تكتبها مديرية نظم المعلومات دون المصالح المهنية، أو العكس، تُغفل جزءًا من القيود.
- التوقف عند الإطلاق في الإنتاج: إذا لم تُحدَّد الاستضافة والصيانة وقابلية الاسترجاع بوضوح وكتابةً، سرعان ما يتحوّل البرنامج المسلَّم إلى تبعية مفروضة.
هل تريد نظرة خارجية على دفتر تحملاتك أو تأطير مشروع SaaS مصمَّم حسب الطلب في المستقبل؟ يمكن لفريق Codevista Innovations في الدار البيضاء مناقشة ذلك معك: تواصل معنا.
أسئلة شائعة
ما الفرق بين دفتر التحملات الوظيفي ودفتر التحملات التقني؟
يصف دفتر التحملات الوظيفي ما يجب أن يتيحه البرنامج، ولأي مستخدمين، وبأي معايير للمصادقة. أما دفتر التحملات التقني فيصف كيفية الإنجاز: البنية، والتقنيات، ونموذج المعطيات، والاستضافة. يحرّر الزبون الأول، بينما يُعدّ مقدّم الخدمة الثاني في الغالب، ويُصادَق عليه مع مديرية نظم المعلومات.
كم ينبغي أن يكون عدد صفحات دفتر التحملات لتطبيق ويب؟
لا يوجد طول مثالي: فأداة داخلية بسيطة تكفيها بضع صفحات، ومنصة متعددة التكاملات تتطلب أكثر. والمعيار الصحيح هو قابلية التحقق: يجب أن تكون كل وظيفة منتظرة قابلة للتعرّف، ومرتّبة حسب الأولوية، ومقرونة بمعايير قبول. وثيقة قصيرة تقرؤها المصالح المهنية خير من وثيقة طويلة يتجاهلها الجميع.
هل ينبغي ذكر الميزانية في دفتر التحملات؟
نعم، ولو في شكل نطاق تقريبي. فمن دون أي إشارة، يقدّر مقدّمو الخدمات عروضهم بطرق متباينة جدًا، فتصبح المقترحات غير قابلة للمقارنة. ويتيح النطاق التقريبي لكل طرف أن يقترح ما هو واقعي، وأن يطرح تقسيم المشروع إلى نسخ متتالية. وحدّد أيضًا إن كانت الميزانية تشمل الصيانة والاستضافة بعد الإطلاق في الإنتاج.
هل يتوافق دفتر التحملات مع منهجية Scrum؟
نعم، بشرط ألا يُجمَّد كل شيء. فالوثيقة تحدّد الأهداف، والمستخدمين، والمتطلبات غير الوظيفية، والميزانية، والمُخرَجات، وملكية الشيفرة. أما النطاق الوظيفي، المعبَّر عنه بقصص مستخدم مرتّبة حسب الأولوية، فيصبح الـProduct Backlog الأولي، الذي يرتّبه الـProduct Owner ويدقّقه الفريق من sprint إلى آخر. ويُحكَّم في كل طلب جديد مقارنةً بالقصص القائمة، مما يُبقي الميزانية تحت السيطرة.