طلبات التغيير

هذه الصفحة تملك هذه العملية. كل ما يطلبه العميل خارج النطاق الموقّع يمرّ من هنا — أثناء الـ build، وأثناء الـ UAT، وأثناء الـ warranty، وتحت الـ retainer.

flowchart TD
  IN["Request recorded at intake —<br/>PM during build, L1 after go-live.<br/>Never absorbed silently"] --> W{"Our defect against agreed<br/>acceptance criteria?"}
  W -- Yes --> FR["Not a change request — free rework:<br/>back to In Dev before go-live,<br/>warranty bug on the expedite lane after"]
  W -- No --> BA["BA writes it to the<br/>Definition of Ready standard"]
  BA --> SZ["Team Lead sizes it —<br/>a PERT range"]
  SZ --> IM["PM assembles the impact:<br/>cost · schedule · risk to<br/>committed milestones"]
  IM --> CE{"CEO approves —<br/>required when it changes cost"}
  CE -- No --> DF["Declined or deferred —<br/>logged, never deleted"]
  CE -- Yes --> CL{"Client approves<br/>in writing"}
  CL -- No --> DF
  CL -- Yes --> BK["Into the backlog,<br/>dates re-baselined"]

القواعد:

1. كل طلب يُسجَّل، بما فيه ما نرفضه. فالطلب الذي يُجاب عنه في رسالة محادثة ولا يُدوَّن هو بداية زحف النطاق.
2. لا يوجد فرع «صغير بما يكفي لنستوعبه». فالتغيير إمّا عيب عندنا — مجاني — وإمّا مُسعَّر. وجملة «سيكون أفضل لو…» هي طلب تغيير حتى داخل نافذة الـ warranty.
3. أعِد التقدير، ولا تعدّل. طلب التغيير يأخذ مدى PERT جديدًا، لا حسمًا من الأصل.
4. لا يبدأ عمل دون موافقة خطّية من العميل. وهذا بند في الـ SOW الموقّع، لا تفضيلًا داخليًا.
5. التغيير المعتمَد يُعيد ضبط التواريخ. وإذا تحرّك الجدول أبلغ الـ PM العميل — وهذه المحادثة لا تحدث أول مرة في الـ demo. انظر مَن يملك ماذا.
6. طلبات العميل تأتي عبر القناة المتّفق عليها — الـ PM أثناء الـ build، وL1 بعد الـ go-live — لا عبر رسالة خاصة لمطوّر. فالجواب في رسالة خاصة يصير التزامًا لم يُسعّره أحد. انظر نموذج الدعم.

مَن يقرّر ماذا: الـ BA يشير إلى أن الأمر خارج النطاق، والـ PM يقرّر أنه كذلك ويقترح التغيير، والـ CEO يعتمد كل ما يغيّر الكلفة، والـ عميل يوافق كتابةً قبل بدء العمل.

وموضع هذا في الارتباط كاملًا: انظر الصورة الكاملة (SDLC). وما الذي يُعدّ عيبًا لا تغييرًا: انظر حدّ الـ Warranty.