Template 1: Full Delivery — Apex Project Management

🎯

متى نختار هذا النموذج؟

المعايير التي تحدد استخدام نموذج Full Delivery

يُستخدم هذا النموذج عندما يكون المشروع جديد من الصفر — العميل وافق على العرض الفني والمالي، والمشروع يحتاج المرور بكل المراحل:

تحليل متطلبات تصميم واجهات تطوير برمجي فحص واختبار نشر وتسليم

💡

هذا هو النموذج الأكثر استخداماً في الشركة — يناسب غالبية المشاريع الصغيرة إلى المتوسطة مثل مشروع PM ROP. إذا كان المشروع يتبع منهجية Waterfall ويمر بكل المراحل، فهذا هو النموذج الصحيح.

🏗️

هيكل المشروع على ClickUp

Space واحد = مشروع واحد — بداخله 5 Folders و 10 Lists

🗂️

Space: اسم المشروع

مثال: "PM ROP Project"

📋

📋 Folder: Planning

List 1: Product Backlog • List 2: Docs & Assets

🎨

🎨 Folder: Design

List 3: UI/UX Tasks • List 4: Design Review

💻

💻 Folder: Development

List 5: Dev Tasks • List 6: Bug Reports

🧪

🧪 Folder: QA

List 7: Test Cases • List 8: Test Runs

🚀

🚀 Folder: Delivery

List 9: Deployment • List 10: Client Feedback

📋

📋 Folder: Planning

التخطيط وتوثيق المتطلبات والمستندات

① List 1: Product Backlog

كل الـ User Stories للمشروع. الـ BA تكتبها هنا وتبقى كمرجع حتى بعد تحويلها لمهام تطوير.

الحالات (Statuses):

Draft← Refined← Approved← Moved to Dev← Deferred

Draft

يغيّرها: BA

الـ BA كتبت الـ User Story لكنها لم تكتمل بعد — تحتاج تفصيل أو مراجعة

Refined

يغيّرها: BA

مكتملة ومفصّلة — جاهزة لمراجعة Team Lead

Approved

يغيّرها: Team Lead

Team Lead وافق عليها — جاهزة للتحويل لمهام تطوير

Moved to Dev

يغيّرها: Team Lead

تم تحويلها لمهام فعلية في Dev Tasks — الـ User Story تبقى هنا كمرجع

Deferred

يغيّرها: Team Lead

مؤجلة لمرحلة لاحقة — ليست ملغاة، فقط ليست ضمن النطاق الحالي

الأعمدة (Fields):

العمود	النوع	مطلوب	الشرح
Task Name	نص	✓	صيغة: "As a [user] I want [X] so that [Y]" — مثال: "كمدير أريد عرض تقرير الأداء حتى أتابع إنتاجية الفريق"
Assignee	شخص	✓	الـ BA المسؤولة عن كتابة هذه الـ User Story
Priority	قائمة	✓	Urgent / High / Normal / Low — يحدد ترتيب التنفيذ
Module	Label	✓	اسم الموديول — مثل: Auth, Dashboard, Reports, Maps, Users
Complexity	قائمة	✓	Simple / Medium / Complex — يساعد في التخطيط وتقدير الجهد

② List 2: Docs & Assets

كل وثائق المشروع الفنية والتشغيلية — SRS، محاضر الاجتماعات، Wireframes، أي ملف مرجعي.

الحالات (Statuses):

Draft← In Review← Approved← Updated

Draft

يغيّرها: الكاتب

الوثيقة قيد الكتابة — لم تُرسل للمراجعة بعد

In Review

يغيّرها: الكاتب

الوثيقة جاهزة — Team Lead يراجعها

Approved

يغيّرها: Team Lead

الوثيقة معتمدة — يمكن الاعتماد عليها

Updated

يغيّرها: الكاتب

تم تحديث الوثيقة بنسخة جديدة بعد أن كانت معتمدة

الأعمدة (Fields):

العمود	النوع	مطلوب	الشرح
Task Name	نص	✓	اسم الوثيقة — مثال: "SRS v1.0" أو "Meeting Notes — 25 Apr"
Assignee	شخص	✓	من كتب هذه الوثيقة
Doc Type	قائمة	✓	SRS / Meeting Notes / Wireframe / Other
Attachments	مرفق	✓	الملف نفسه — PDF, Word, صور
Version	نص قصير	—	رقم النسخة — مثل v1.0, v1.1, v2.0

🎨

🎨 Folder: Design

تصميم الواجهات ومراجعتها مع الفريق والعميل

③ List 3: UI/UX Tasks

كل شاشة أو Component = Task مستقلة. المصمم يعمل هنا ويسلّم التصميم. عند الانتهاء، يغيّر الحالة إلى Ready for Review وينتقل التصميم للمراجعة في Design Review.

الحالات (Statuses):

To Do← In Progress← Pending← Blocked← Ready for Review← Done

To Do

يغيّرها: Team Lead

مهمة جاهزة للعمل — المصمم يعرف إنها بانتظاره

In Progress

يغيّرها: المصمم

المصمم بدأ العمل فعلياً على التصميم

Pending

يغيّرها: المصمم

توقف مؤقت — بريك، نهاية دوام، مهمة طارئة

Blocked

يغيّرها: المصمم

عالق — ينتظر معلومة أو قرار أو شغل من شخص آخر

Ready for Review

يغيّرها: المصمم

التصميم جاهز — ينتظر مراجعة Team Lead

Done

يغيّرها: Team Lead

التصميم معتمد نهائياً — جاهز للتطوير

الأعمدة (Fields):

العمود	النوع	مطلوب	الشرح
Task Name	نص	✓	اسم الشاشة أو الـ Component — مثال: "Login Page" أو "Dashboard Header"
Assignee	شخص	✓	المصمم المسؤول
Due Date	تاريخ	✓	تاريخ التسليم المتوقع
Time Estimate	رقم (ساعات)	✓	تقدير المصمم — حد أقصى 3 ساعات. لو أكثر يقسم لـ Subtasks
Priority	قائمة	✓	Urgent / High / Normal / Low
Module	Label	✓	نفس موديولات الـ Product Backlog
Design Link	URL	✓	رابط Figma للتصميم
Screen Type	قائمة	—	Page / Modal / Component / Icon Set
Linked User Story	Relationship	✓	ربط مع الـ User Story المقابلة في Product Backlog

④ List 4: Design Review

مراجعة التصميمات الكاملة — يتم إرسال كل التصميمات دفعة واحدة للعميل وليس شاشة بشاشة. المراجعة الداخلية أولاً ثم العميل.

الحالات (Statuses):

Pending Review← Internal Approved← Sent to Client← Revision Requested← Final Approved

Pending Review

يغيّرها: المصمم

التصميمات وصلت من المصمم — تنتظر مراجعة Team Lead الداخلية

Internal Approved

يغيّرها: Team Lead

Team Lead راجع ووافق داخلياً — جاهزة للإرسال للعميل

Sent to Client

يغيّرها: Team Lead

التصميمات أُرسلت للعميل كاملة — ننتظر رده

Revision Requested

يغيّرها: Team Lead

العميل طلب تعديلات — يُحدد في Feedback Notes ماذا يجب تعديله

Final Approved

يغيّرها: Team Lead

انتهت كل التعديلات والموافقة نهائية — يبدأ التطوير

الأعمدة (Fields):

العمود	النوع	مطلوب	الشرح
Task Name	نص	✓	اسم مجموعة التصميمات — مثال: "Design Review — Module Auth" أو اسم الشاشة
Assignee	شخص	✓	المسؤول عن متابعة المراجعة (غالباً Team Lead)
Design Link	URL	✓	رابط Figma
Linked Design Task	Relationship	✓	ربط مع الـ Task في UI/UX Tasks
Feedback Source	قائمة	✓	Internal / Client — مصدر الملاحظة
Feedback Notes	نص طويل	✓	تفاصيل الملاحظة — ماذا يجب تعديله بالضبط
Time Estimate	رقم (ساعات)	✓	تقدير وقت التعديل المطلوب
Due Date	تاريخ	✓	متى يجب الانتهاء من المراجعة/التعديل
Priority	قائمة	✓	Urgent / High / Normal / Low

💻

💻 Folder: Development

المهام البرمجية وتتبع الأخطاء

⑤ List 5: Dev Tasks

المهام البرمجية الفعلية. كل Task تخرج من User Story معتمدة. لا يوجد حالة Rejected هنا — إذا وجد الـ QA مشكلة، يفتح Task جديدة في Bug Reports ويربطها بالمهمة الأصلية.

الحالات (Statuses):

To Do← In Progress← Pending← Blocked← Ready for Testing← In QA← Done

To Do

يغيّرها: Team Lead

مهمة معتمدة وجاهزة للعمل. المبرمج يجب أن يضع Time Estimate قبل بدء العمل

In Progress

يغيّرها: المبرمج

المبرمج يعمل عليها حالياً. يتم تحديث الحالة لحظة بدء العمل — ليس في آخر اليوم

Pending

يغيّرها: المبرمج

توقف مؤقت بسبب: بريك، نهاية دوام، مهمة طارئة من الإدارة. الوقت في هذه الحالة لا يُحسب كعمل فعلي

Blocked

يغيّرها: المبرمج

عالق — ينتظر معلومة، أو عمل من موظف آخر، أو قرار. يجب كتابة سبب العرقلة في التعليقات فوراً

Ready for Testing

يغيّرها: المبرمج

المبرمج أنهى العمل — المهمة جاهزة ليفحصها الـ QA

In QA

يغيّرها: QA

الـ QA بدأ الفحص فعلياً بناءً على الـ Test Cases

Done

يغيّرها: QA

الفحص اكتمل بنجاح — لا توجد أخطاء. إذا وُجدت أخطاء، يفتح الـ QA task في Bug Reports بدلاً من رفض هذه المهمة

✅

لماذا لا يوجد Rejected؟ لأننا نفصل بين "إنجاز المهمة" و"جودة المهمة". المبرمج أنهى المهمة فعلاً (Done). لو فيها bug، هذا خطأ مستقل بدورة حياته الخاصة في Bug Reports. هذا يعطينا مقياسين منفصلين: عدد المهام المنجزة (إنتاجية) وعدد الـ Bugs لكل مبرمج (جودة).

الأعمدة (Fields):

العمود	النوع	مطلوب	الشرح
Task Name	نص	✓	اسم واضح ومحدد — مثال: "API — إنشاء endpoint تسجيل الدخول"
Task ID	نص قصير	✓	معرّف فريد للمهمة — يستخدمه المبرمج في كل Commit على GitLab لربط الكود بالمهمة. مثال: "DEV-042"
Assignee	شخص	✓	المبرمج المسؤول
Due Date	تاريخ	✓	يُحدد بناءً على الـ Time Estimate
Time Estimate	رقم (دقائق)	✓	تقدير المبرمج — حد أقصى 40 دقيقة. أكثر = يجب تقسيمها لـ Subtasks
Priority	قائمة	✓	Urgent / High / Normal / Low
Module	Label	✓	نفس موديولات المشروع
Dev Type	قائمة	✓	Frontend / Backend / Full Stack / API / Database
Linked User Story	Relationship	✓	ربط مع الـ User Story الأصلية في Product Backlog
Linked Test Case	Relationship	—	ربط مع الـ Test Case المقابل في QA

🔗

ربط GitLab بـ ClickUp: المبرمج يجب أن يضع الـ Task ID في كل Commit message على GitLab — مثال: DEV-042: fix login validation. هذا يمكّننا من تتبع كل تعديل في الكود ومعرفة أي مهمة مرتبط بها.

⑥ List 6: Bug Reports

الـ QA يفتح الأخطاء هنا مربوطة بالمهمة الأصلية في Dev Tasks. كل Bug له دورة حياة مستقلة تماماً عن المهمة الأصلية.

الحالات (Statuses):

Open← In Progress← Pending← Fixed← Verified← Closed← Reopened

Open

يغيّرها: QA

الـ QA اكتشف Bug وسجّله — بانتظار المبرمج

In Progress

يغيّرها: المبرمج

المبرمج بدأ إصلاح الخطأ

Pending

يغيّرها: المبرمج

توقف مؤقت

Fixed

يغيّرها: المبرمج

المبرمج أصلح الخطأ — جاهز لإعادة الفحص

Verified

يغيّرها: QA

الـ QA تحقق — الخطأ تم إصلاحه فعلاً

Closed

يغيّرها: QA

مغلق نهائياً

Reopened

يغيّرها: QA

الخطأ عاد بعد الإصلاح — يحتاج معالجة مرة أخرى

الأعمدة (Fields):

العمود	النوع	مطلوب	الشرح
Task Name	نص	✓	وصف واضح للخطأ — مثال: "زر الحفظ لا يعمل في صفحة التعديل"
Assignee	شخص	✓	المبرمج المسؤول عن الإصلاح
Due Date	تاريخ	✓	موعد الإصلاح المتوقع
Time Estimate	رقم (دقائق)	✓	تقدير وقت الإصلاح — حد أقصى 40 دقيقة
Priority	قائمة	✓	Urgent / High / Normal / Low
Severity	قائمة	✓	Critical: النظام لا يعمل. Major: وظيفة أساسية معطلة. Minor: خطأ صغير لا يمنع الاستخدام. Cosmetic: مظهري فقط
Module	Label	✓	الموديول الذي يحتوي على الخطأ
Linked Dev Task	Relationship	✓	ربط مع المهمة الأصلية التي خرج منها الخطأ
Found By	شخص	✓	من اكتشف الخطأ — QA، عميل، أو مبرمج آخر
Steps to Reproduce	نص طويل	✓	خطوات إعادة إنتاج الخطأ بالتفصيل
Expected vs Actual	نص طويل	✓	المتوقع: يحفظ البيانات ويظهر رسالة نجاح. الفعلي: لا يحصل شيء عند الضغط
Attachments	مرفق	✓	Screenshot أو Video يثبت الخطأ

🧪

🧪 Folder: QA

سيناريوهات الفحص وتنفيذ الاختبارات

🔑

نقطة مهمة: الـ QA يفحص بناءً على الـ Test Cases وليس على الـ User Stories مباشرة. الـ BA تكتب "ماذا نريد" (User Story)، والـ QA يكتب "كيف نتحقق" (Test Cases بسيناريوهات مفصلة تشمل Edge Cases و Negative Scenarios). الفحص الفعلي يتم على الـ Test Cases.

⑦ List 7: Test Cases

سيناريوهات الفحص لكل Module. هذه وثيقة مرجعية ثابتة — تُكتب مرة واحدة وتُستخدم في كل Test Run.

الحالات:

Draft← Ready← Needs Update

Draft

يغيّرها: QA

السيناريو قيد الكتابة

Ready

يغيّرها: QA

مكتمل وجاهز للاستخدام

Needs Update

يغيّرها: QA / Team Lead

يحتاج تحديث — تغيّرت المتطلبات

الأعمدة:

العمود	النوع	مطلوب	الشرح
Task Name	نص	✓	مثال: "TC-001: تسجيل دخول بإيميل صحيح"
Assignee	شخص	✓	الـ QA
Module	Label	✓	الموديول المرتبط
Linked User Story	Relationship	✓	ربط مع الـ User Story
Preconditions	نص	✓	الشروط المسبقة
Test Steps	نص طويل	✓	خطوات الفحص بالتفصيل
Expected Result	نص	✓	النتيجة المتوقعة
Test Type	قائمة	✓	Functional / UI / Performance / Security / Regression
Priority	قائمة	✓	Urgent / High / Normal / Low

⑧ List 8: Test Runs

تنفيذ الفحص الفعلي. كل Run = تطبيق مجموعة Test Cases على Build معين.

الحالات:

Planned← In Progress← Pass← Fail← Blocked

الأعمدة:

العمود	النوع	مطلوب	الشرح
Task Name	نص	✓	مثال: "Test Run — Auth Module — Build v2.1"
Assignee	شخص	✓	الـ QA المسؤول
Due Date	تاريخ	✓	متى يجب إنهاء الفحص
Linked Test Cases	Relationship	✓	أي Test Cases تم تطبيقها
Linked Dev Tasks	Relationship	—	المهام البرمجية التي يفحصها هذا الـ Run
Actual Result	نص طويل	✓	النتيجة الفعلية للفحص
Build/Version	نص	✓	رقم الـ Build أو الـ Commit
Attachments	مرفق	—	إثبات — Screenshots أو Videos

🚀

🚀 Folder: Delivery

النشر والتسليم وملاحظات العميل

⑨ List 9: Deployment

مهام النشر على السيرفر — سواء إصدار كامل أو تحديث أو إصلاح سريع.

الحالات:

To Do← In Progress← Deployed to Staging← Deployed to Production← Verified← Done

الأعمدة:

العمود	النوع	مطلوب	الشرح
Task Name	نص	✓	مثال: "Deploy v2.1 — Auth + Dashboard modules"
Assignee	شخص	✓	المسؤول عن النشر
Due Date	تاريخ	✓	موعد النشر المخطط
Deploy Type	قائمة	✓	Full Release / Hotfix / Update
Environment	قائمة	✓	Staging / Production
Linked Dev Tasks	Relationship	—	المهام الداخلة في هذا الـ Deployment
Checklist	Checklist	✓	خطوات ما قبل النشر — Backup, Tests, Config check
Rollback Plan	نص	—	خطة التراجع في حال حدوث مشكلة

⑩ List 10: Client Feedback

ملاحظات العميل بعد التسليم أو بعد كل Demo.

الحالات:

New← Reviewed← Converted to Task← Won't Fix← Done

الأعمدة:

العمود	النوع	مطلوب	الشرح
Task Name	نص	✓	ملخص الملاحظة
Feedback Source	قائمة	✓	Client / Internal
Reported By	نص	✓	اسم الشخص من جهة العميل
Attachments	مرفق	—	Screenshots أو ملفات
Linked Task	Relationship	—	ربط مع المهمة إذا تم التحويل
Priority	قائمة	✓	Urgent / High / Normal / Low

⚡

آلية العمل خطوة بخطوة

كيف يسير المشروع من البداية للتسليم

إنشاء المشروع

Team Lead ينشئ Space جديد باسم المشروع ويطبّق نموذج Full Delivery — يتم إنشاء الـ 5 Folders و الـ 10 Lists تلقائياً

Team Lead

كتابة الـ User Stories

الـ BA تكتب كل الـ User Stories في Product Backlog. تبدأ بحالة Draft ثم Refined عندما تكتمل

BA (يمنى)

اعتماد الـ Stories وبدء التصميم

Team Lead يراجع ويوافق (Approved). المصمم يبدأ تصميم الشاشات — كل شاشة Task في UI/UX Tasks مع ربطها بالـ User Story

Team Lead + المصمم

مراجعة التصميم

المصمم يسلّم (Ready for Review) → تذهب للمراجعة في Design Review. مراجعة داخلية أولاً (Internal Approved) → ثم تُرسل كل التصميمات دفعة واحدة للعميل (Sent to Client). العميل يوافق (Final Approved) أو يطلب تعديل (Revision Requested)

Team Lead + العميل

تحويل الـ Stories لمهام تطوير

بعد موافقة التصميم، Team Lead يفتح Dev Tasks لكل Story مع Task ID فريد ويوزعها على المبرمجين. الـ User Story تتحول لـ "Moved to Dev"

Team Lead

التطوير + الـ Time Estimation

المبرمج يشوف مهامه بحالة To Do → يحط Time Estimate (حد أقصى 40 دقيقة، أكثر يقسم لـ Subtasks) → يبدأ العمل ويحدّث الحالة أولاً بأول. في كل Commit على GitLab يضع الـ Task ID

المبرمج

كتابة الـ Test Cases

بالتوازي مع التطوير، الـ QA يكتب Test Cases بناءً على الـ User Stories في QA Folder

الفحص

المبرمج يحط Ready for Testing → الـ QA يحطها In QA ويفحص بناءً على الـ Test Cases. لو كل شيء تمام → Done. لو فيه مشكلة → يفتح Bug في Bug Reports مربوط بالمهمة

إصلاح الأخطاء

المبرمج يصلح الـ Bugs (Open → In Progress → Fixed). الـ QA يتحقق (Verified → Closed). لو رجع الخطأ → Reopened

المبرمج + QA

النشر والتسليم

لما كل شيء Done والـ Bugs مغلقة → مهمة Deployment → Staging أولاً → فحص → Production → التحقق مع العميل → Done

Team Lead + المبرمج

📌

القواعد الأساسية

قواعد يجب على كل أعضاء الفريق الالتزام بها

⏱️ قاعدة الـ Time Estimate

كل مهمة يجب أن يضع لها الموظف المسؤول Time Estimate قبل بدء العمل.
• المبرمجون: حد أقصى 40 دقيقة لكل مهمة. أكثر = يجب تقسيمها لـ Subtasks.
• المصممون: حد أقصى 3 ساعات لكل مهمة. أكثر = يجب تقسيمها لـ Subtasks.

🔄 قاعدة تحديث الحالات

الموظف يغيّر حالة المهمة لحظة حدوث التغيير — ليس في آخر اليوم. هذا ضروري لقياس الوقت الفعلي بدقة. بدأت؟ In Progress فوراً. وقفت؟ Pending فوراً. رجعت؟ In Progress فوراً. خلصت؟ Ready for Testing فوراً.

🚫 قاعدة لا Rejected في Dev Tasks

الـ QA لا يرفض المهمة الأصلية. بدلاً من ذلك، يفتح Task جديدة في Bug Reports مربوطة بالمهمة الأصلية. المهمة الأصلية تبقى Done. هذا يفصل بين مقياس الإنتاجية (عدد المهام المنجزة) ومقياس الجودة (عدد الأخطاء لكل مبرمج).

🔗 قاعدة الربط والـ Task ID

كل Dev Task لها Task ID فريد (مثل DEV-042). المبرمج يضع هذا الـ ID في كل Commit على GitLab. كل Dev Task يجب ربطها بالـ User Story. كل Bug يجب ربطه بالـ Dev Task. كل Design Task يجب ربطها بالـ User Story. هذا يخلق خريطة كاملة للتتبع.

📝 قاعدة الـ Blocked

عندما يحط الموظف مهمة بحالة Blocked، يجب كتابة سبب العرقلة في التعليقات فوراً مع ذكر من ينتظره أو ما المعلومة الناقصة. مهمة Blocked بدون تعليق = مخالفة.

🧪 قاعدة الفحص

الـ QA يفحص بناءً على Test Cases وليس User Stories مباشرة. الـ BA تكتب "ماذا نريد"، والـ QA يكتب "كيف نتحقق" بسيناريوهات تفصيلية تشمل Edge Cases و Negative Scenarios.