🔄 التعديلات على المشروع

"ممكن تعديل بسيط؟" — أربع كلمات تسرّع نبض كل مستقل. وفي المقابل: "التعديل يكلّف إضافي" — ثلاث كلمات تُشعر كل عميل أنه يُستغل.

التعديلات هي أكثر نقطة خلافية في العلاقة بين المستقل والعميل. وفي الغالب، كلا الطرفين يشعر أنه مظلوم. لذلك هذا المقال لن ينحاز لطرف — بل سيضع الأمور في نصابها.

المستقل يعمل لساعات على تصميم أو كود أو نص. يبذل جهداً في البحث والتخطيط والتنفيذ. ثم يأتي طلب التعديل — وغالباً يكون غامضاً: "حسّنه شوي" أو "مو حاسس فيه".

المستقل يفكر: أنا بذلت مجهوداً كبيراً، وأنت لا تقدّره. كل تعديل يعني ساعات إضافية غير مدفوعة. وإذا قلت لا، سأخسر العميل.

شعوره مشروع: التعديلات غير المحسوبة تأكل من ربحه ووقته وطاقته. ومع تكرارها في كل مشروع، يتراكم الإحباط حتى يصبح كراهية للمهنة نفسها.

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

العميل يفكر: أنا دافع فلوسي وأحتاج النتيجة تكون مثل ما أبي. لو المستقل شاطر كان عرف من الأول. ولماذا يحاسبني على تعديلات وأنا دافع مسبقاً؟

شعوره مشروع أيضاً: العميل غير متخصص ولا يستطيع تقييم العمل إلا بعد رؤيته. طبيعي أن تكون ملاحظاته بعد الاستلام لا قبله.

المشكلة ليست في التعديلات نفسها — بل في غياب ثلاثة أشياء:

1. تعريف واضح لـ "التعديل": هل تغيير لون زر هو "تعديل"؟ نعم. هل إعادة تصميم صفحة كاملة هو "تعديل"؟ لا — هذا عمل جديد. لكن بدون تعريف مسبق، كل شيء يصبح "تعديل بسيط".

2. اتفاق على العدد: "تعديلات غير محدودة" وعد مستحيل. و"لا تعديلات" مطلب غير واقعي. الوسط هو الأعدل: جولتان أو ثلاث جولات تعديلات ضمن السعر.

3. طلب تعديل واضح: "حسّنه" ليس طلباً. "غيّر لون الزر الرئيسي من الأزرق للأخضر وكبّر النص في القسم الأول" — هذا طلب. الغموض يسبب إعادة عمل ويُحبط الطرفين.

ظاهرة "زحف النطاق" (Scope Creep) ليست مشكلة المستقلين فقط — حتى أكبر الشركات في العالم تعاني منها.

مشروع طائرة Boeing 787 Dreamliner كان مخططاً أن يُنجز خلال 4 سنوات بتكلفة 5 مليارات دولار. لكن التعديلات المستمرة — تغييرات في المواد، إضافات تقنية جديدة، طلبات من شركات الطيران — أخّرت المشروع 3 سنوات إضافية ورفعت التكلفة إلى أكثر من 32 مليار دولار حسب تحليل نشرته Reuters عام 2011.

السبب الرئيسي حسب تحليل Harvard Business School: لم يكن هناك آلية واضحة لتقييم أثر كل تغيير قبل الموافقة عليه. كل تعديل بدا "صغيراً" بمفرده، لكن مجموع التعديلات الصغيرة حوّل المشروع لكابوس.

الدرس لنا كمستقلين: إذا كانت Boeing بفرقها المكونة من آلاف المهندسين تعاني من التعديلات غير المنضبطة — فمن الطبيعي أن يعاني منها مستقل يعمل وحده. الحل ليس في رفض التعديلات، بل في نظام واضح لإدارتها.

تقرير Pulse of the Profession الصادر عن Project Management Institute (PMI) — أكبر منظمة عالمية متخصصة في إدارة المشاريع — يكشف أرقاماً صادمة:

- 52% من المشاريع تعاني من زحف النطاق (scope creep). - المشاريع التي لا تُحدد نطاقها بوضوح من البداية تفشل بنسبة أعلى بـ 3 مرات من التي تحدده. - 39% من فشل المشاريع يعود لتغيّر المتطلبات أثناء التنفيذ.

ودراسة من Geneca — شركة استشارات تقنية — وجدت أن 75% من العملاء يعترفون بأنهم يعرفون أن مشاريعهم ستفشل من البداية بسبب عدم وضوح المتطلبات.

هذه الأرقام تؤكد: المشكلة ليست في نوايا الطرفين — بل في غياب النظام. عندما يوجد اتفاق مكتوب واضح على ما يشمله المشروع وما لا يشمله، تنخفض النزاعات حول التعديلات بشكل كبير.

للمستقل: - ضع في اتفاقك عدد جولات التعديلات بوضوح (مثلاً: "يشمل السعر 3 جولات تعديلات. كل جولة تعديلات إضافية بـ X دولار"). - اطلب ملاحظات مجمّعة: "اكتب كل ملاحظاتك في رسالة واحدة" بدلاً من رسائل متفرقة طوال اليوم. - وضّح الفرق بين التعديل والتغيير الجذري من البداية. - استخدم منهجية Agile المبسّطة: قسّم المشروع لمراحل قصيرة (أسبوع أو أسبوعين)، واعرض كل مرحلة على العميل قبل الانتقال للتالية. هذا يكشف التعديلات مبكراً بدلاً من تراكمها.

للعميل: - خذ وقتك في مراجعة العمل قبل إرسال الملاحظات. لا ترسل ملاحظة كل 5 دقائق. - كن محدداً: "اللون الأحمر" بدلاً من "لون أقوى". "النص أكبر بقليل" بدلاً من "مو واضح". - افهم أن بعض التعديلات التي تبدو "بسيطة" قد تتطلب ساعات عمل. اسأل المستقل عن التأثير قبل أن تطلب.

للطرفين: - اتفقوا على آلية التعديلات قبل بدء العمل — ليس أثناءه. - استخدموا أداة واحدة للملاحظات بدلاً من واتساب وإيميل وتويتر. - تذكّروا أن الهدف واحد: مشروع ناجح يرضي الطرفين.

في عالمنا العربي، هناك مثل شامي يقول: "الحكي ببلاش، بس التنفيذ بيكلّف" — وهذا بالضبط جوهر مشكلة التعديلات. التعديلات ليست عدواً — إنها جزء طبيعي من أي مشروع. حتى Boeing بميزانياتها المليارية لم تسلم من زحف النطاق.

وفي السوق العربي تحديداً، ظاهرة "التعديل اللامتناهي" لها بُعد ثقافي: كثير من العملاء يتعاملون مع المستقل كأنه موظف بدوام كامل — يرسلون ملاحظات على واتساب الساعة 11 ليلاً ويتوقعون تنفيذاً صباح اليوم التالي. منصات مثل مستقل وخمسات حاولت حل هذه المشكلة بوضع أنظمة واضحة لجولات التعديلات، لكن كثير من التعاملات تحصل خارج المنصات — وهنا تبدأ المشاكل.

المشكلة تبدأ عندما لا يكون هناك اتفاق واضح على حدودها وطريقتها. كما يقولون بالمصري: "الحساب قبل الأكل بيزوّد المحبة". المستقل ليس جشعاً إذا حدد عدد التعديلات، والعميل ليس صعباً إذا طلب تعديلات معقولة. الحل يبدأ بحوار صريح وتوثيق واضح قبل أن يبدأ العمل.