---
name: saas-prebuild-planning
description: Plan a SaaS product, workflow, or automation before implementation. Use for discovery, PRDs, scope, requirements, feasibility, build-vs-buy, delivery planning, stage gates, and build-readiness decisions. استخدمها لتخطيط ما قبل البناء، ولا تستخدمها لتنفيذ الكود أو لمراجعة أمنية منفردة.
---

# SaaS Prebuild Planning

## عقد التشغيل

- **استخدمها عندما:** توجد فرصة أو طلب يحتاج نطاقًا، PRD، MVP، قرار build/buy أو جاهزية بناء.
- **لا تستخدمها عندما:** المطلوب عصف مفتوح قبل تثبيت المشكلة، أو إصلاح برمجي محصور.
- **تستلم:** رهان فكرة مثبتًا أو طلبًا قائمًا، أدلة، قيود، وافتراضات.
- **تملك وتنتج:** نطاق، MVP، FR/NFR، سجل أدلة وافتراضات، قرار Lean/Governed، وبوابة BUILD READY.
- **لا تملك:** تصميم الواجهة التفصيلي، threat model، أو تنفيذ الكود.
- **بوابة الخروج:** قرار Go/No-Go أو Spike محدد، وملاك للقرارات والمخاطر.
- **التسليم التالي:** التجربة، المعمارية، AI، أو الأمن بحسب ما أظهره النطاق.

اتبع نموذج المسارات والملكية في `../../shared/references/operating-model.md`.

## المهمة

حوّل فكرة أو طلبًا غير مكتمل إلى **حزمة قرار وتنفيذ قابلة للتدقيق**. لا تنتج خطة جميلة لغويًا؛ أنتج خطة تكشف الجهل، تختبر الافتراضات، وتمنع بدء بناء غير مبرر.

## قواعد حاكمة

1. افصل دائمًا بين `FACT` و`ASSUMPTION` و`HYPOTHESIS` و`DECISION` و`UNKNOWN`.
2. لا تبدأ كتابة كود إنتاجي قبل بوابة `BUILD READY`، باستثناء Spike محدود لاختبار مخاطرة محددة.
3. لا تفترض أن SaaS هو الشكل الصحيح. قارن: لا بناء، عملية بشرية، Automation، Workflow، إضافة داخل نظام قائم، SaaS، أو Agentic system.
4. لا تستخدم «أفضل ممارسة» بلا ربط بسياق، قيد، تهديد، أو هدف قابل للقياس.
5. عند نقص المعلومات، استخرج ما يمكن من السياق ثم سجل افتراضات مرئية. اسأل فقط عن فجوة تغير القرار جذريًا ولا يمكن اختبارها بأقل تكلفة.
6. أي معلومة حالية عن سوق أو قانون أو خدمة أو نموذج أو سعر يجب التحقق منها من مصدر أولي؛ وإلا وسمها `UNVERIFIED`.
7. اجعل كل قرار كبير قابلًا للتتبع إلى مشكلة أو متطلب أو خطر.

## المدخلات المقبولة

- فكرة أولية أو وصف مشكلة.
- ملاحظات مقابلات أو شكاوى أو إجراءات حالية.
- مستودع قائم أو وثائق منتج.
- قيود ميزانية، وقت، فريق، تنظيم، بيانات أو تكاملات.
- طلب PRD أو خطة MVP أو Roadmap أو Build/Buy analysis.

## سير العمل

### 0. تصنيف المهمة

حدد:

- نوع النتيجة: SaaS / Workflow / Automation / Internal tool / Agentic feature / Unknown.
- المرحلة: فكرة / اكتشاف / ما قبل MVP / إعادة تصميم / توسع.
- أصحاب القرار والمستخدمون والمتأثرون.
- القرارات المطلوب اتخاذها الآن، والقرارات التي يمكن تأجيلها.
- القيود الصلبة مقابل التفضيلات.

أنشئ `planning/00-intake-and-classification.md`.

### 1. دفتر الأدلة والافتراضات

استخدم القالبين:

- `../../shared/templates/evidence-ledger.md`
- `../../shared/templates/assumption-register.md`

استخرج الادعاءات الضمنية، خصوصًا:

- من لديه المشكلة؟
- كم تتكرر؟
- ما تكلفة الوضع الحالي؟
- ما البدائل الحالية؟
- هل توجد صلاحية للوصول للبيانات والأنظمة؟
- هل توجد رغبة دفع أو قيمة تشغيلية قابلة للقياس؟

رتب `killer assumptions` حسب: أثر الخطأ × عدم اليقين × تكلفة التأخر.

### 2. تعريف المشكلة والنتيجة

اكتب Problem Frame يتضمن:

- actor + context + trigger + current behavior.
- الألم أو الهدر أو المخاطر، دون صياغة الحل داخل المشكلة.
- النتيجة المطلوبة ومقياس نجاح أولي.
- Non-goals لمنع تمدد النطاق.
- لماذا الآن؟ وما الذي يحدث إن لم نبن شيئًا؟

ارفض عبارات مثل «نريد منصة ذكية» ما لم تتحول إلى نتيجة تشغيلية قابلة للقياس.

### 3. تحليل العملية الحالية

ارسم `As-Is workflow`:

- المحفز، الخطوات، القرارات، الانتظار، إعادة العمل، handoffs، الأنظمة، البيانات، الاستثناءات.
- نقاط الفشل ومصادر الحقيقة المتعارضة.
- الخطوات الحتمية مقابل الخطوات التي تحتاج حكمًا أو تفسيرًا.
- الإجراءات الحساسة أو غير القابلة للعكس.

استخرج مواطن: الحذف، الدمج، التوحيد، الأتمتة، التفويض، أو الإبقاء البشري.

### 4. اختيار شكل الحل

قارن الخيارات التالية ولا تقفز إلى SaaS:

| الشكل | استخدمه عندما | علامة رفض |
|---|---|---|
| No-build/process fix | المشكلة ناتجة عن سياسة أو ملكية أو تدريب | التقنية لا تغير النتيجة |
| Automation | مهمة متكررة، قواعد واضحة، واجهة محدودة | استثناءات كثيرة وحكم بشري عميق |
| Workflow | تنسيق أشخاص وأنظمة وموافقات وحالات | القيمة مجرد إجراء فردي بسيط |
| SaaS | قيمة متكررة، مستخدمون/مستأجرون، تشغيل مستمر | طلب أحادي أو عميل وحيد بلا تكرار |
| Agentic | غموض، أدوات، خطوات متعددة، حاجة لاستدلال | مسار حتمي أسهل وأأمن وأرخص |

أنشئ مصفوفة قرار باستخدام `../../shared/templates/decision-matrix.md`.

### 5. تعريف المنتج والنطاق

أنشئ:

- Vision and outcome statement.
- Personas/roles وليس شخصيات تجميلية.
- Jobs-to-be-done أو user outcomes.
- User journeys والـ happy path ومسارات الخطأ.
- Functional requirements مرقمة `FR-###`.
- Non-functional requirements مرقمة `NFR-###` تشمل الأمن، الخصوصية، العزل، الأداء، التوفر، الاستعادة، المراقبة، الوصولية، التكلفة، وقابلية الصيانة.
- Out-of-scope list.
- Dependency and integration register.
- Data classification and residency questions.

كل متطلب يجب أن يملك Acceptance Criteria قابلة للاختبار.

### 6. تقسيم الإصدار

قسم النطاق إلى:

- `Walking skeleton`: تدفق طرفي صغير يثبت التكامل والتشغيل.
- `MVP`: أقل إصدار يختبر قيمة/مخاطرة محددة، لا أقل عدد شاشات.
- `MMP`: الحد الأدنى القابل للتسويق والتشغيل والدعم.
- Later bets: رهانات لا تدخل المسار الحرج.

استخدم Vertical slices لا طبقات تقنية منفصلة قدر الإمكان.

### 7. الجدوى والمخاطر

قيّم:

- Technical feasibility.
- Data availability and quality.
- Integration/API constraints.
- Security/privacy/compliance exposure.
- Operational ownership and support.
- Economic viability: build cost، run cost، support cost، gross margin pressure، model/API cost.
- Vendor lock-in and exit plan.
- Team capability and critical-person risk.

لكل مخاطرة عالية، اختر: إزالة، تقليل، نقل، قبول موثق، أو Spike.

### 8. خطة التنفيذ

أنشئ:

- Workstreams and owners.
- Dependency-aware milestone plan.
- Backlog مرتب بالنتيجة والمخاطر، لا بطول قائمة الميزات.
- Definition of Ready وDefinition of Done.
- Test strategy مبكر.
- Architecture/security/AI handoff requests.
- Release hypothesis، rollout، observability، rollback.

لا تعط تقديرات زائفة الدقة. استخدم نطاقات وثقة وافتراضات تقدير.

### 9. بوابة BUILD READY

استخدم `../../shared/templates/gate-review.md`.

لا تمنح `PASS` إلا عند توفر:

- مشكلة ونتيجة ومستخدمون محددون.
- أدلة كافية أو خطة اختبار قصيرة للـ killer assumptions.
- شكل حل مبرر مقارنة ببدائل أبسط.
- Scope وNon-goals واضحان.
- FR/NFR مع Acceptance Criteria.
- بيانات وتكاملات وقيود معروفة.
- مخاطر حرجة لها معالجة ومالك.
- خطة إصدار واختبار وتشغيل أولية.
- قرارات غير قابلة للعكس مؤجلة أو موثقة.

المخرجات الممكنة: `PASS`، `CONDITIONAL PASS`، `FAIL`، `DEFER`.

## المخرجات الإلزامية

```text
planning/
├── 00-intake-and-classification.md
├── 01-evidence-ledger.md
├── 02-assumption-register.md
├── 03-problem-and-outcomes.md
├── 04-as-is-workflow.md
├── 05-solution-form-decision.md
├── 06-prd.md
├── 07-requirements-traceability.md
├── 08-release-slices.md
├── 09-feasibility-and-risks.md
├── 10-delivery-plan.md
└── 11-build-readiness-gate.md
```

## تعريف النجاح

- يستطيع فريق مستقل فهم ما يبنيه ولماذا، وما لا يبنيه.
- يستطيع المراجع ربط كل عنصر نطاق بدليل ونتيجة ومتطلب واختبار.
- الافتراضات الخطرة مرئية وليست مخفية داخل نبرة واثقة.
- يوجد قرار صريح بعدم البناء عندما يكون ذلك أفضل.
- لا توجد معمارية أو تقنية مختارة فقط لأنها رائجة.

## التسليم للمهارات الأخرى

- للأفكار الضعيفة أو المتضاربة: `saas-idea-incubation`.
- لتجربة المستخدم والواجهات والتحويل: `saas-product-experience-engineering`.
- لمكون AI: `ai-capability-integration`.
- للتصميم البنيوي وتدفق البيانات: `saas-architecture-dataflow`.
- للأمن: `saas-security-engineering`.
- للتدقيق النهائي: `saas-audit-repair`.
- للتجميع والتسليم: `saas-project-handbook`.