إزاي تقول "لا" للعميل من غير ما تخسر شغلك: إدارة توقعات العميل بذكاء

يا أهلاً بيك يا زميلي المبرمج. أكيد مريت باللحظة دي: العميل بيبعتلك رسالة الساعة 2 بالليل يقولك "معلش يا هندسة، هي حاجة بسيطة بس، ممكن نزود زرار يبعت إيميل وكمان يرفع ملفات الـ PDF على السحابة؟ مش هتاخد وقت!". طبعاً الحاجة البسيطة دي ممكن تقلب بليلة سودة من الشغل غير المدفوع وتأخير في التسليم. دي مشكلة "زحف النطاق" أو المعروفة تقنياً بـ (Scope Creep)، وهي العدو الأول لأي مطور برمجيات (Software Developer).

ليه "السكوب" (Scope) أهم من الكود نفسه؟

المشكلة مش في العميل، المشكلة في غياب الحدود الواضحة. لما بتبدأ مشروع من غير ما تحدد "نطاق العمل" (Project Scope) بدقة، أنت بتفتح الباب لكل الاحتمالات. إدارة التوقعات (Expectation Management) جزء لا يتجزأ من مهارات المطور الشاطر. لو معرفتش تقول "لا" في الوقت المناسب، هتلاقي نفسك بتشتغل في مشروع (Project) مفروض يخلص في شهر، وبقى بقاله 3 شهور مفتوح، وده هيأثر على جودة كودك (Code Quality) وصحتك النفسية.

إزاي تحمي نفسك بعقود واتفاقيات واضحة

الوقاية خير من العلاج. قبل ما تكتب سطر كود واحد، لازم يكون فيه وثيقة بتوضح المطلوب بالظبط. ده بيتحقق من خلال حاجتين:

• وثيقة متطلبات العمل (Business Requirements Document - BRD): لازم تكون مفصلة ومكتوب فيها إيه اللي هيتعمل، والأهم، إيه اللي "مش" هيتعمل.
• اتفاقية مستوى الخدمة أو نطاق العمل (Statement of Work - SOW): دي الوثيقة اللي بتمضي عليها العميل، وأي طلب زيادة بيعتبر (Change Request) وله تكلفة إضافية.

استراتيجية "لا" الذكية: التكلفة والوقت

لما العميل يطلب إضافة، بدل ما تقول "لا" فجأة وتخسره، استخدم أسلوب "التفاوض التقني". قول للعميل: "أنا ممكن أعمل دي، بس ده هيحتاج نعدل الجدول الزمني (Timeline) ونزود ميزانية (Budget) إضافية لأنها برة الاتفاق الأصلي". الكود ده مثال بسيط يوضح إزاي ممكن تفكر في الـ (Architecture) قبل ما توافق:

// نموذج لطلب تعديل برة النطاق (Out of Scope)
function estimateChangeRequest(feature) {
  const originalScope = ['Login', 'Dashboard', 'Reports'];
  
  if (originalScope.includes(feature)) {
    return "ضمن نطاق العمل الأصلي، هبدأ فيها فوراً";
  } else {
    return "دي ميزة إضافية (Feature Request)، محتاجين نعمل لها تقييم (Estimation) وتكلفة جديدة";
  }
}

امتى لازم تقول "لا" بجد؟

فيه حالات لازم تقطع فيها الشك باليقين، زي لما يكون الطلب بيخالف معايير الأمان (Security Standards) أو بيأثر على استقرار النظام (System Stability). المبرمج المحترف هو اللي بيعرف يقول لا لما الطلب يهدد جودة المنتج النهائي (Final Product). العميل بيحترم المبرمج اللي عنده "رأي فني" (Technical Opinion) أكتر بكتير من المبرمج اللي بيقول "حاضر" على كل حاجة وفي الآخر المنتج يطلع بايظ.

نصيحة من أخ ليك

يا زميلي، المهنة دي محتاجة صبر وذكاء اجتماعي مش بس مهارة في (Coding). "لا" مش معناها إنك مش متعاون، "لا" معناها إنك بتحترم وقتك وبتحترم العميل وبتحترم الشغل اللي بتطلعه. حاول دايماً توثق كل محادثة (Documentation) وكل طلب تعديل، عشان في الآخر ميكونش فيه كلام مرسل. ابدأ اتعلم مهارات التفاوض (Negotiation Skills) زي ما بتتعلم لغات البرمجة، وهتشوف فرق كبير في جودة حياتك المهنية.