المقارنة والاختيار: مصفوفة القرار
كيف تقارن بين الخيارات بطريقة شفافة، وتصل إلى قرار مبرّر يمكن الدفاع عنه وتوثيقه؟ ⏱ نحو 40 دقيقة.
- تقارن الخيارات بالمزايا والعيوب المرتبطة بالمشروع.
- تبني مصفوفة قرار موزونة وتحسب المجموع الموزون.
- تتجنب أخطاء الانحياز في الأوزان والدرجات.
- توثّق القرار في سجل
ADRبسياقه وبدائله ونتائجه.
١من قائمة الخيارات إلى قرار
في الدرس السابق جمعنا الخيارات ومعايير الاختيار. الآن نحتاج طريقة منظمة وشفافة نصل بها إلى قرار نستطيع الدفاع عنه أمام العميل والفريق، ونعود إليه بعد سنة لنفهم لماذا اخترنا ما اخترنا. ثلاث أدوات بالترتيب: المزايا والعيوب، ثم مصفوفة القرار الموزونة، ثم سجل القرار.
٢المزايا والعيوب
نبدأ بأبسط مقارنة لخيارات الخادم الثلاثة المرشحة لنظام «دورات»، مع ربط كل نقطة بالمشروع نفسه لا بالإطار عمومًا:
| الخيار | مزايا لهذا المشروع | عيوب لهذا المشروع |
|---|---|---|
| Laravel | الفريق يعرف PHP، ومصادقة وصلاحيات جاهزة، واستضافة رخيصة | يحتاج تنظيمًا جيدًا إن كبر المشروع |
| Django | لوحة إدارة جاهزة توفر وقت شاشات الموظفين، وأمان افتراضي قوي | الفريق يحتاج تعلم Python، واستضافته أقل انتشارًا |
| Express | لغة واحدة مع React، وخفيف وسريع | المصادقة والصلاحيات ولوحة الإدارة تُبنى يدويًّا |
٣مصفوفة القرار الموزونة
نعطي كل معيار وزنًا حسب أهميته للمشروع (المجموع 100%)، ثم نعطي كل خيار درجة من 1 إلى 5 في كل معيار. المجموع الموزون = Σ (الوزن × الدرجة).
| المعيار | الوزن | Laravel | Django | Express |
|---|---|---|---|---|
| مهارات الفريق | 30% | 5 | 2 | 3 |
| ملاءمة المتطلبات | 25% | 4 | 4 | 3 |
| التكلفة | 20% | 5 | 3 | 4 |
| الأمان | 15% | 4 | 5 | 3 |
| سرعة البناء | 10% | 4 | 5 | 3 |
| المجموع الموزون | 100% | 4.50 | 3.45 | 3.20 |
جرّب: لو كان الفريق يعرف Python بدل PHP، غيّر درجات «مهارات الفريق» إلى 2 و5 و3، وشاهد النتيجة تنقلب. القرار الجيد يتغير حين تتغير المعطيات، وهذا ما يجعله مقنعًا.
| قاعدة | لماذا؟ |
|---|---|
| حدّد الأوزان قبل الدرجات | حتى لا تُعدَّل الأوزان لتفوز التقنية المفضلة |
| اجعل الأوزان من أولويات العميل | إن كانت الميزانية أهم ما عنده، فوزن التكلفة أعلى |
| اكتب سببًا لكل درجة متطرفة (1 أو 5) | يكشف الدرجات المبنية على الانطباع |
| إن تقارب خياران (فرق أقل من 0.3) | لا تعتمد على الرقم؛ اعرض الخيارين على العميل بمزاياهما |
٤سجل قرار المعمارية ADR
القرار يُنسى ويُعاد النقاش فيه كل شهر إن لم يُوثّق. سجل قرار المعمارية Architecture Decision Record مستند قصير جدًّا لكل قرار مهم، يدخل لاحقًا في مستند المواصفات التقنية:
- الحالة
- معتمد · 2026-10-28
- السياق
- نظام تسجيل بـ 300 مستخدم متزامن
(NFR-01)، وصلاحيات متعددة الأدوار(FR-07)، وفريق يعرف PHP و MySQL، وميزانية استضافة محدودة. - القرار
- نستخدم Laravel 11 مع MySQL، وصفحات Blade للوحة الإدارة.
- البدائل المدروسة
Django (3.45)وExpress (3.20)مقابلLaravel (4.50)في مصفوفة القرار.- النتائج
- إيجابية: بداية أسرع ومصادقة جاهزة. سلبية: إن تطلّب التطبيق الجوال اتصالًا فوريًّا كثيفًا فقد نحتاج خدمة Node صغيرة لاحقًا.
توقّع وتحقّق
خيار حصل على 5 في معيار وزنه 30% و2 في معيار وزنه 70%. مجموعه الموزون:
0.3×5 + 0.7×2 = 1.5 + 1.4 = 2.9متى تُحدَّد الأوزان؟
ما الذي يضيفه ADR على مصفوفة القرار؟
خياران مجموعاهما 3.9 و4.0. ما التصرف الأنسب؟
الخلاصة
- المزايا والعيوب بداية، لكنها لا تقول أي النقاط أهم.
- المصفوفة الموزونة: أوزان المعايير
(100%)× درجات الخيارات (1–5). - حدّد الأوزان قبل الدرجات ومن أولويات العميل.
ADR: الحالة، والسياق، والقرار، والبدائل، والنتائج.
تحدٍّ تصميمي: سجل قرار: قاعدة البيانات
متوسطاكتب سجل قرار ADR لاختيار قاعدة بيانات «دورات» بين MySQL و PostgreSQL و MongoDB. استعمل مصفوفة القرار في الدرس (يمكنك تعديلها) لتحصل على الأرقام.
- عنوان فيه ADR ورقم.
- سياق يذكر متطلبًا واحدًا على الأقل بمعرّفه.
- قرار واضح باسم قاعدة البيانات.
- بديلان مدروسان على الأقل، لكل منهما رقم من مصفوفة القرار.
- نتيجة إيجابية ونتيجة سلبية.
- العنوان فيه ADR ورقم
- السياق يذكر متطلبًا بمعرّفه
- القرار يسمّي قاعدة البيانات
- بديلان على الأقل
- لكل بديل رقم من المصفوفة
- نتيجة إيجابية
- نتيجة سلبية
💡 تلميح 1
💡 تلميح 2
نموذج واحد من إجابات كثيرة صحيحة.
- العنوان
- ADR-002: اختيار MySQL قاعدةً للبيانات
- السياق
- بيانات التسجيل والدفع مترابطة وتحتاج سلامة المعاملات
(FR-02)، والاستضافة المختارة تدعم MySQL افتراضيًّا، والفريق يعرفها. - القرار
- نستخدم MySQL 8 مع مفاتيح أجنبية ومعاملات لعمليات الدفع.
- البدائل المدروسة (كل بديل في سطر مع رقمه)
PostgreSQL (3.9): قوية لكن الفريق لم يستخدمها.MongoDB (2.4): لا تناسب البيانات المترابطة بعلاقات.- النتائج
- إيجابية: لا تكلفة تعلم، ودعم كامل في Laravel.
سلبية: بعض الاستعلامات التحليلية المتقدمة أسهل في PostgreSQL.