«نضيف خطوة اعتماد ثانية، الموضوع مجرد زر». قد يبدو الطلب صغيرًا على الشاشة، لكنه يغيّر من يستطيع إكمال المعاملة وما يحدث للطلبات المنتظرة والتقارير والإشعارات. حين تسأل عن تكلفة تعديل نطاق مشروع برمجي، تحتاج تفسيرًا لما سيتغير قبل أن تقرر هل السعر والموعد مناسبان.
ابدأ من النسخة المعتمدة للنطاق، ثم سجل الفرق المطلوب وسبب ظهوره. لا تجعل النقاش محاكمة سريعة للعميل أو المنفذ: أحيانًا ينكشف نقص في الفهم، وأحيانًا تتغير الحاجة فعلًا. ورقة التغيير تساعد على فصل الحالتين وعلى مقارنة بدائل تحقق الغرض نفسه بأعباء مختلفة.
أول سؤال: ما المرجع الذي نقارن به؟
أرفق رقم المتطلب أو سيناريو القبول أو الرسم المعتمد، وحدد نسخته وتاريخه. عبارة «اتفقنا عليه في الاجتماع» يصعب فحصها إذا كان كل طرف يتذكر نتيجة مختلفة. انقل الوصف السابق والجديد بجوار بعضهما، وأضف حالة عملية تبين الفرق دون بيانات عملاء حقيقية.
إذا كان السلوك الحالي يخالف شرط قبول مكتوبًا، فسجل المخالفة والدليل. وإذا كان الشرط نفسه غامضًا، فسجل التفسير المطلوب. أما إضافة دور أو مسار لم يكن في المرجع فتحتاج بيان أثر واضح. هذه أوصاف للمراجعة، وليست حكمًا آليًا بمن يدفع؛ ذلك يرجع إلى الاتفاق الفعلي وما يقره الطرفان.
مثال افتراضي: اعتماد مصروف فرع
تستخدم شركة صيانة بوابة يرفع فيها مدير الفرع طلب مصروف ويعتمده المسؤول المالي. بعد عرض النسخة التجريبية، تطلب الشركة موافقة مدير المنطقة قبل المالية. المثال تعليمي ولا يصف مشروعًا نفذته نكست ويف. المطلوب ليس إضافة زر فقط: من ينوب عن المدير الغائب، وهل تنتقل الطلبات القديمة إلى المسار الجديد؟
يمكن مقارنة تنفيذ المسار للجميع، أو قصره على فئة مصروف محددة، أو تأجيله مع إجراء يدوي موثق لفترة معلومة. لا تفترض أن البديل اليدوي صالح تلقائيًا؛ راجع من يتابعه وأثره على الرقابة وحجم العمل، ثم اكتب سبب قبول البديل أو رفضه.
ورقة أثر تستخدمها في جلسة المراجعة
| البند | ما يُكتب قبل الموافقة | دليل يغلق السؤال |
|---|---|---|
| حد التغيير | خطوة الاعتماد والفئات التي تمر بها، وما يبقى خارجها. | فرق موضح على المسار السابق. |
| البيانات والحالات | مصير الطلب المفتوح، والرفض، وإعادة الإرسال، والبديل عند الغياب. | حالات تجريبية بنتائج متوقعة. |
| السعر | أعمال التحليل والبناء والاختبار وأي مصروف متكرر، مع الافتراضات. | عرض تغيير مفصل وآلية اعتماده. |
| الموعد والقبول | التسليم الذي يتأثر، ومدخلات العميل، ومن يراجع النتيجة. | خطة محدثة وشروط قبول للتغيير. |
هذا نموذج تحريري، لا قائمة خدمات مشمولة في كل عقد. اترك خانة «غير محسوم» أمام ما يحتاج فحصًا، مع مسؤول وخطوة تالية. الرقم الدقيق المبني على مدخل مجهول لا يصبح تقديرًا موثوقًا لمجرد كتابته داخل جدول.
اسأل عن المجهود الإضافي ومكانه في الجدول
اطلب شرح الأعمال التي أنشأها الطلب: تعديل صلاحية، وترحيل حالة، وتحديث رسالة، واختبار مسار قديم مثلًا. ثم اسأل هل يحل هذا العمل محل بند مؤجل أم يضاف إلى الالتزام الحالي. حذف وظيفة لتثبيت الموعد قرار في النطاق يجب تسجيله، وليس وسيلة لإخفاء أثر التغيير.
توضح إرشادات Atlassian أن تقييم التغيير يسبق اعتماده ويشمل الأثر على الموارد والتكلفة والمدة. ويتيح دليل Scrum إعادة مناقشة النطاق مع التعلم دون الإضرار بهدف الدورة أو خفض الجودة. نستفيد من هذين المبدأين؛ لا يثبت أي منهما أن تعديلك مجاني أو أن تقدير الشركة صحيح دون تفسير.
لا تغلق الطلب عند وصول الفاتورة
بعد القرار، احفظ نسخة معتمدة تبين البديل المختار والسعر أو طريقة الحساب والموعد والمسؤول. عند التسليم جرّب الطلب الجديد، ثم حالة قديمة يفترض ألا تتأثر، وراجع البيانات الناتجة. إذا بقي استثناء، سجله باسم واضح بدل اعتماد التغيير اعتمادًا عامًا يخفي العمل المتبقي.
إن كان الخلاف في أصل المتطلبات، ارجع إلى دليل وصف المتطلبات. وللمقارنة قبل التعاقد، توجد ورقة فروق عروض البرمجة. أما نقاش التعديل مع فريق تطوير الأنظمة المخصصة في نكست ويف فيبدأ بمرجع سابق وفرق قابل للفحص، لا باسم وظيفة جديد وحده.
المصادر وحدود الاستخدام
فُتح دليل التحكم بالتغيير ودليل Scrum في 4 نوفمبر 2026. المثال والورقة إعداد تحريري، دون تسعير سوق أو تفسير ملزم للعقود. أُعد المحتوى بمساعدة الذكاء الاصطناعي مع مراجعة المعنى والمراجع.
