طلب صغير
كنا نشتغل على خاصية محددة، والنطاق واضح، والفريق متفق على المطلوب.
بعد أسبوع جاء طلب:
بما إنكم شغالين عليها، أضيفوا معها خيار التصدير.
قلنا نشوفه.
بعدها جاء طلب ثاني:
دامكم فاتحين الصفحة، خلّوا المستخدم يقدر يعدّل البيانات.
وبعده:
طيب ليش ما نضيف إشعارًا تلقائيًا بعد الحفظ؟
وبعد فترة، الخاصية الصغيرة صارت مشروعًا كاملًا.
وهذي هي مشكلة توسع النطاق أو الـScope Creep. ما يجيك فجأة بطلب ضخم، غالبًا يبدأ بجملة بريئة:
دامكم شغالين عليها…
كل طلب لوحده يبدو منطقيًا، لكن لما تجمعها، تتغير مدة التنفيذ، والتكلفة، والمخاطر، وحتى الهدف الأساسي.
مو معناته نرفض كل تعديل يظهر أثناء العمل. أحيانًا الفريق يكتشف احتياجًا مهمًا فعلًا، وتجاهله يكون قرارًا سيئًا.
لكن كل إضافة تحتاج قرارًا واعيًا:
- هل هي ضرورية لإطلاق الخاصية؟
- هل تمنع المستخدم من إكمال المهمة؟
- هل نقدر نطلق بدونها؟
- وش أثرها على الموعد؟
- وش الشيء اللي بنؤجله مقابل إضافتها؟
المشكلة مو في إضافة الطلب الجديد، المشكلة في إضافته وكأنه مجاني.
كل شيء له تكلفة، حتى لو بدا بسيطًا.
صرنا نستخدم أسلوبًا واضحًا: أي إضافة جديدة أثناء التنفيذ إما تدخل بدل عنصر موجود، أو تؤجل للمرحلة التالية، أو تغيّر الموعد بشكل معلن.
بهذا الشكل يعرف الجميع أن النطاق قرار، مو قائمة مفتوحة.
خلاصة اليوم:
أخطر جملة في المشروع: «بس أضيفوا هذي معها».
لأن المنتج ما يتأخر عادة بسبب قرار واحد كبير، يتأخر بسبب عشر إضافات صغيرة محد حسب حسابها.
إطلاق 
أضف تعليق