FA AR EN

عندما يتحول الاختيار الأرخص إلى تكلفة أعلى؛ تجربة من مشروع برمجي

من التجارب التي مررت بها خلال سنوات عملي المهني، تجربة تتعلق بمشروع في زمینه الموسيقى.

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

بعد دراسة المشروع وتحديد التكلفة، اتفقنا على أن يتولى تنفيذ المشروع.

لكن مر وقت دون أن أسمع منه شيئًا.

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

سألته:

«كنت ستسند المشروع إليّ، فما الذي حدث؟»

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

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

وطلب مني مساعدته في حل هذه المشكلة.

كان أول سؤال طرحته عليه:

«كيف حددتم في العقد موعد التسليم، وتكلفة المشروع، ونطاق العمل؟»

وكانت إجابته لافتة بالنسبة إليّ:

«ليس لدينا عقد مكتوب؛ اتفقنا فقط على أن يتم تنفيذ المشروع خلال شهرين وبالمبلغ المحدد.»

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

أوضحت له أن العقد في المشاريع البرمجية ليس مجرد إجراء إداري؛ بل هو أحد الأدوات المهمة لتحديد التوقعات والحد من الخلافات المستقبلية.

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

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

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

الدرس الذي تعلمته من هذه التجربة

ذكّرتني هذه التجربة بنقطة مهمة:

عند اختيار منفذ لمشروع برمجي، لا ينبغي أن يكون السعر هو المعيار الوحيد لاتخاذ القرار.

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

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

أحيانًا قد يتحول الاختيار الأرخص في بداية المشروع إلى تكلفة أعلى بكثير لاحقًا.

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

تعليقك

إذا كانت لديك تجربة أو رأي حول هذه المقالة، فسيسعدني أن تشاركه معي ومع بقية القراء.

0 / 3000 حرف
لم يتم تسجيل أي تعليق على هذه المقالة حتى الآن.