كيف تدير النطاق وتتجنب زحف النطاق؟

Question

Accepted Answer

**النطاق** هو مجموعة العمل المتفق عليها التي سيقدمها المشروع. **زحف النطاق** هو التوسع التدريجي غير المتحكم فيه لذلك النطاق — التدفق المستمر من "الإضافات البسيطة" التي تفجر الجدول الزمني بصمت. إدارة النطاق تعني التحكم في *التغيير*، وليس رفضه.

## حدد النطاق بوضوح مسبقاً

```text
✓ Document what's IN scope
✓ Document what's explicitly OUT of scope (the underused half)
✓ Define "done" / acceptance criteria
✓ Get stakeholders to agree before work starts
```

الحد المكتوب والمتفق عليه هو ما يسمح لك لاحقاً بالقول "هذا تغيير" بأدلة.

## تعامل مع التغييرات بشكل مقصود

التغييرات ليست سيئة — التغييرات غير المتحكم فيها هي السيئة. عندما يصل طلب جديد، مرره عبر بوابة بسيطة:

```text
1. Is it really needed now, or is it a "nice to have"?
2. What's the impact on timeline / cost / other work?
3. Make the trade-off VISIBLE → "yes, but it pushes the date / drops X"
4. Get the stakeholder to decide with full information
```

الحركة الرئيسية: لا تمتص العمل الإضافي بصمت أبداً. اجعل كل إضافة مقايضة واعية يمتلكها أصحاب المصلحة.

## مثال عملي

في منتصف المشروع، يطلب صاحب مصلحة "أيضاً دعم الرفع الجماعي — يجب أن يكون سريعاً." بدلاً من حشره، تجيب: "يمكننا، لكنه يضيف حوالي أسبوع. هل نحرك التاريخ، أم نضع ميزة التحليلات للإصدار القادم؟" الآن قرارهم، مع وضوح التكلفة.

## فخ شائع

الموافقة على كل طلب لكونك مفيداً، ثم تفويت الموعد النهائي. يبدو الفريق وكأنه فشل، بينما هو في الواقع استوعب بصمت عملاً إضافياً.

## لماذا يهم الأمر

زحف النطاق هو السبب الأكثر شيوعاً لتأخر المشاريع — ليس لأن أي تغيير واحد كبير، بل لأن العشرات تتراكم بصمت.

إدارة النطاق تحافظ على المشروع صادقاً: التغيير جيد، لكن تكلفته دائماً موضحة وتملكها من يريده.