يُطرح الاختيار بين عقد بسعر ثابت ونظام الوقت والمواد عادةً على أنه اختيار يتعلق بالمخاطرة، وهذا صحيح، ثم يُساء التعامل معه فوراً، لأن الطرفين يفترضان أن المخاطرة تختفي بدلاً من أن تنتقل من طرف إلى آخر.

هي لا تختفي. في الترتيب ذي السعر الثابت يتحمل المورّد مخاطرة أن يكون التقدير خاطئاً، ويُسعّر تلك المخاطرة داخل الرقم المعروض. وفي نظام الوقت والمواد يتحملها العميل. السؤال ليس أبداً أي الخيارين يزيل عدم اليقين، بل أي الطرفين أقدر على إدارته، وهل يستحق ثمن نقل المخاطرة أن يُدفع.

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

ما الذي يشتريه عقد السعر الثابت فعلياً

يقيناً بشأن الفاتورة، ولا شيء غير ذلك. وهو تحديداً لا يشتري يقيناً بشأن النتيجة ولا الموعد ولا الجودة، رغم أن المشترين يفترضون أن هذه الثلاثة تأتي ضمن الحزمة.

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

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

يعمل السعر الثابت جيداً مع الأعمال المحددة الحدود فعلاً: ترحيل معروف المصدر والوجهة، وتكامل مع واجهة برمجية موثّقة، ومجموعة شاشات محددة وفق تصميم متفق عليه. ويعمل بشكل سيئ مع أي عمل استكشافي.

متى يكون نظام الوقت والمواد أقل تكلفة

خلافاً للحدس، يحدث ذلك كثيراً، لأنك لا تدفع احتياطي المخاطر ولا تدفع كلفة معالجة طلبات التغيير.

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

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

وإن لم يكن أحد لديكم قادراً على منح هذا الانتباه، فقولوها صراحة، لأن نظام الوقت والمواد لن يعمل جيداً ولا يوجد بند تعاقدي يصلح ذلك.

الخيار الذي ينبغي لمعظم المشاريع أن تستخدمه

ترتيب بسقف أو مقسّم على مراحل، وهو ليس أياً من الخيارين السابقين ويناسب من أعمال البرمجيات أكثر مما يناسبه كل منهما على حدة.

الوقت والمواد بسقف. يُحتسب العمل بالوقت، مع حد أعلى متفق عليه. يحتفظ العميل بمرونة تغيير الاتجاه، ويتحمل المورّد المخاطرة المتبقية فوق السقف. ويبقى للطرفين مصلحة في الكفاءة، وهو ما لا يحققه أي من النموذجين الصافيين.

سعر ثابت على مراحل. تنتج مرحلة استكشاف قصيرة ومدفوعة مواصفات مكتوبة، وعندها فقط يُسعَّر البناء بسعر ثابت مقابل شيء حقيقي. هذه هي النسخة الأمينة من السعر الثابت، لأن التقدير يجري بعد تقليص المجهول لا قبله. دليلنا لكتابة كراسة شروط البرمجيات يوضح ما ينبغي أن تحتويه تلك المواصفات.

سعر ثابت لكل مرحلة تطوير. تُسعَّر كل مرحلة على حدة ويُتفق عليها على حدة. تحصل على قابلية للتنبؤ بالميزانية على دفعات، وعلى حق التوقف، وهو أثمن حق يملكه العميل وبالضبط الحق الذي تلغيه العقود الطويلة ذات السعر الثابت.

الخيط الجامع واحد: دقة التقدير تتحسن تحسناً هائلاً بعد إنجاز جزء من العمل. وبناء الترتيب التجاري بحيث يستفيد من ذلك يساوي أكثر من أي بند تعاقدي.

أين تفشل مشاريع السعر الثابت فعلياً

ليس عند السعر. بل عند الحد الفاصل بين النطاق والتغيير.

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

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

الفشل الشائع الآخر هو التسلّم. إذا لم يحدد العقد كيف يُثبت الإنجاز، تحولت الدفعة الأخيرة إلى مفاوضة على الآراء. اكتب معايير القبول إلى جانب النطاق، وفضّل معايير يستطيع أحد اختبارها على معايير يضطر أحد للحكم عليها.

كيف تختار عملياً

اسأل عما هو مجهول حقاً. إن كان الجواب «قليل جداً» فالسعر الثابت معقول، وينبغي أن تتوقع دفع احتياطي مقابل هذا اليقين. وإن كان المجهول كثيراً، فالسعر الثابت لا يفعل سوى تحويل عدم اليقين التقني إلى احتكاك تجاري.

ثم اسأل عما تستطيع متابعته. نظام الوقت والمواد يكافئ الانتباه ويعاقب غيابه. أما السعر الثابت فيطلب منك أقل أسبوعاً بأسبوع، وأكثر بكثير في البداية داخل المواصفات، حيث تكون الأخطاء أرخص لكن ملاحظتها أصعب.

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

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

الأسئلة الشائعة

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

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

ما هو نظام الوقت والمواد بسقف؟ عمل يُحتسب بالوقت مع حد أعلى متفق عليه. يحتفظ العميل بمرونة تغيير الاتجاه بينما يتحمل المورّد المخاطرة فوق السقف. وهو يترك للطرفين مصلحة في الكفاءة، وهو ما لا يحققه السعر الثابت الصافي ولا نظام الوقت والمواد الصافي.

لماذا تتعثر مشاريع البرمجيات ذات السعر الثابت؟ غالباً عند الحد الفاصل بين النطاق والتغيير، لا عند السعر. تُكتب المواصفات قبل أن يستخدم أحد البرنامج، لذا فطلبات التغيير حتمية. وتعتمد السلامة على الاتفاق مسبقاً على من يقيّم التغيير وكيف يُسعَّر، وعلى احتفاظ العميل بميزانية احتياطية خاصة به.

هل ينبغي تحديد معايير القبول في العقد؟ نعم، إلى جانب النطاق. فبلا طريقة محددة لإثبات الإنجاز تتحول الدفعة الأخيرة إلى مفاوضة على الآراء. فضّل معايير يستطيع أحد اختبارها على معايير يضطر أحد للحكم عليها، لأن المعيار القابل للاختبار يحسم الخلاف بينما المعيار القائم على التقدير يطيله.