حدّ الـ Warranty

الخطّ بسيط: عيوبنا نحن هي warranty؛ والطلبات والتغييرات الجديدة billable. رسم هذا الخطّ بوضوح عند الاستقبال يحمي العلاقة والهامش معًا.

من الـ go-live إلى الدعم المدفوع

timeline
  title Warranty timeline
  Go-live : Warranty clock starts here
  Day 0 to 30 : 30-day bug-fix warranty : our defects fixed free
  Final payment : Handover of code and credentials : may fall inside or after the window
  After Day 30 : Paid support retainer : business-hours SLA

warranty مقابل billable

يكون warranty حين…	يكون billable حين…
ميزة مُسلَّمة لا تحقّق معايير القبول المتّفق عليها.	يريد العميل سلوكًا جديدًا غير موجود في الـ SOW الموقّع.
عيب في كودنا، خلال ٣٠ يومًا من الـ go-live.	تغيير على سلوك مقبول ويعمل أصلًا.
regression أدخلناه نحن.	تغييرات في environment أو طرف ثالث أو من جهة العميل خارج بنائنا.

تنبيه

الـ warranty يغطّي عيوبنا نحن، لا نطاقًا جديدًا. جملة «سيكون أفضل لو…» هي change request لا bug — وجِّهها كـ billable حتى داخل الـ ٣٠ يومًا.

خمسة أحداث، وليست حدثًا واحدًا

هذه الصفحة هي المكان الوحيد لرقم الـ ٣٠ يومًا ولقاعدة الـ handover؛ وكل ما عداها يربط إليها. والالتباس الذي يستحقّ القتل هو معاملة هذه الأحداث الخمسة كلحظة واحدة، وهي غالبًا ليست كذلك:

الحدث	ما هو	ماذا يُطلق
Go-live	النظام يخدم مستخدمين حقيقيين في الإنتاج	هنا يبدأ عدّاد الـ warranty لمدّة ٣٠ يومًا. ولا شيء آخر يبدؤه
القبول (Acceptance)	يوقّع العميل بأن النطاق المُسلَّم يحقّق معايير القبول	يُغلق الـ build، ويمكن إصدار الفاتورة الأخيرة
الدفعة الأخيرة	تُسدَّد الفاتورة الأخيرة	تُطلق الـ handover — ولا شيء غيرها
الـ Handover	انتقال الكود والـ credentials (صلاحية الـ repo، أسرار الـ Key Vault، مفاتيح الـ deployment) إلى العميل	ينهي سيطرتنا الحصرية. وهو لا يبدأ الـ warranty ولا يعيد تشغيله ولا يمدّده
نهاية الـ warranty	بعد ٣٠ يومًا من الـ go-live	دعم مدفوع تحت retainer، أو لا شيء

العدّاد يبدأ عند الـ go-live لا عند الـ handover، لأن هذا ما وقّعه العميل: الـ SOW يقول ٣٠ يومًا بعد الـ go-live. وإذا تأخّرت الدفعة الأخيرة — وهذا يحدث كثيرًا — تكون نافذة الـ warranty قد بدأت فعلًا، ولا تُمدَّد تعويضًا. هذه كلفة تجارية لفاتورة متأخّرة، وعلاجها التحصيل في وقته لا إعادة تعريف الكلمة بعد وقوعها.

وإن احتاج ارتباط بعينه فعلًا أن يبدأ العدّاد من الـ handover، فمكان ذلك الـ SOW الموقّع، وهو يعلو على هذه الصفحة. أمّا غير المقبول فهو أن يختلف التاريخان بصمت.

اذكر تاريخ نهاية الـ warranty صراحةً عند الـ go-live، وثبّته كتابةً. فالـ warranty الذي ينتهي بصمت يتحوّل إلى خلاف.

ولمعرفة موضع ذلك في التسلسل كاملًا، انظر الصورة الكاملة (SDLC).

كيف نُسجّل ونوجّه

flowchart LR
  Req["Incoming request"] --> Tri{"Our defect<br/>within 30 days?"}
  Tri -- Yes --> Bug["Bug — warranty<br/>expedite lane, free"]
  Tri -- No --> Bill["Change request<br/>billable, estimate + backlog"]

• عيب warranty ← bug work item، مسار expedite، بلا رسوم. انظر نموذج الدعم.
• تغيير billable ← change request؛ يُقدَّر ويُضاف إلى الـ backlog، ويُجدوَل تحت الـ retainer أو SOW جديد.

إغلاق الارتباط

هذه الصفحة تملك هذه العملية. الارتباط الذي لا يُغلق رسميًا يترك credentials حيّة، وبيئات حيّة، وتوقّع دعم مفتوحًا لا يتقاضى أحد عنه شيئًا.

flowchart TD
  F["Final payment received,<br/>handover complete"] --> RB["Runbook complete in the repo,<br/>L1 briefed"]
  RB --> WE["Warranty window ends —<br/>client told the date in advance"]
  WE --> RT{"Paid retainer?"}
  RT -- Signed --> OP["Retainer in force — we keep prod<br/>plus the dev · qa · uat ladder<br/>we ship changes through"]
  RT -- Declined --> RV["Revoke our prod access —<br/>the client owns it outright"]
  RV --> DC["Decommission dev · qa · uat"]
  DC --> AC["Revoke remaining access,<br/>both directions"]
  OP --> EA["Estimate vs. actual review —<br/>feeds the next quote"]
  AC --> EA
  EA --> CL["Closed"]

• أبلغ العميل بتاريخ نهاية الـ warranty قبل حلوله، مع بيان شكل الدعم بعده — retainer أو لا شيء.
• فكّك dev وqa وuat — فقط حين لا يوجد retainer. أمّا تحت الـ retainer فيبقى السلّم كاملًا: كل تغيير يُروَّج بمبدأ «ابنِ مرة واحدة» عبر dev ← qa ← uat ← prod. انظر الـ Pipelines والبيئات.
• الوصول يُلغى في الاتجاهين. الـ Team Lead يلغي وصول العميل إلى repos وبيئاتنا؛ والـ PM يغلق وصولنا إلى أنظمة العميل — وهو صفّ الـ PM في الأدوات والوصول؛ أمّا credentials الإنتاج والـ Key Vault فهي للـ CTO.
• الـ runbook يجب أن يكون مكتملًا لا مبدئيًا، وأن يكون L1 قد مُشِّط عليه. انظر قالب الـ Runbook.
• قارن التقدير بالفعلي، مرّة واحدة، كتابةً. هذا وحده ما يجعل العرض التالي أفضل. أمّا دروس العملية فتتكفّل بها الـ retros على إيقاعها المعتاد.
• لا نؤرشف المستندات في مكان ثانٍ. اللوحة والـ repo هما السجل. ونسخهما «للأرشيف» يُنشئ نسخة تنحرف — وهو نفس سبب حذف هذا الـ wiki بدل الأرشفة.
• لا «نُحرّر موارد المشروع». فالمختصّون موزَّعون على مشاريع متزامنة بحكم التصميم، ولا يوجد pool مخصّص يُعاد إليه شيء.

والنطاق اللاحق ليس استمرارًا — بل يدخل من الأعلى كـ lead جديد، بـ discovery وتقدير وSOW خاصّة به.