كيف تختار شركة برمجة لمشروعك

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

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

اطلب أن تفتح نظامًا يعمل اليوم

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

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

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

الأشخاص، بأسمائهم

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

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

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

ملكية الشيفرة والبيانات والحسابات

هذه ثلاثة أشياء منفصلة، ويخلط بينها كثيرون، بمن فيهم بائعون حسنو النية.

• الشيفرة. من يملك المستودع (Repository) في النهاية، وبأي رخصة، وهل تشمل الملكية المكتبات الداخلية التي تعيد الشركة استخدامها بين عملائها. إعادة الاستخدام أمر طبيعي وغالبًا مفيد، لكنك تحتاج رخصة مكتوبة تتيح لك الاستمرار في استخدامها إذا افترقتما.
• البيانات. هل تستطيع تصدير كل بياناتك بنفسك، بصيغة موثّقة، في أي يوم، دون إذن. إذا كان الجواب يمرّ بطلب دعم فأنت لا تتحكّم في بياناتك.
• الحسابات. حساب الاستضافة السحابية، ومسجّل النطاق، وإعدادات الـ DNS، وحسابات متاجر التطبيقات، وحساب التاجر لدى بوابة الدفع (Payment Gateway)، ومفاتيح الخدمات الخارجية: كلها باسم شركتك وعلى فواتير شركتك، ويملك المورّد صلاحية الوصول لا الملكية.

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

قراءة العرض: النطاق والاستثناءات والافتراضات

العرض الجادّ أربعة أقسام: النطاق (Scope)، والاستثناءات (Exclusions)، والافتراضات (Assumptions)، والسعر. ومعظم المشترين يقرأون الأخير، بينما المعلومة في القسمين الأوسطين.

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

أمّا الافتراضات فهي قائمة تغييرات السعر في ثوب آخر: «يوفّر العميل بيانات المنتجات في ملف نظيف»، «يتيح النظام المحاسبي واجهة برمجية». كل افتراض يتبيّن خطؤه يتحوّل إلى أمر تغيير (Change Order). راجعها بندًا بندًا واسأل: أيّها إن كان خاطئًا يغيّر الرقم، وبكم تقريبًا.

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

السعر الثابت والوقت والمواد، بصراحة

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

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

لماذا يكون العرض الأرخص أغلى ما تدفعه

هذه نقطة تُحاجَج ولا تُعلَن، لأن عبارة «الرخيص غالي» لا تقنع من ينظر إلى رقم يساوي نصف الأرقام الأخرى.

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

العرض الرخيص ليس رقمًا أصغر للشيء نفسه، بل شيء أصغر موصوف بالألفاظ نفسها.

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

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

الشهر الأول، والأسئلة التي تحملها إلى الاجتماع

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

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

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

احمل هذه الأسئلة إلى الاجتماع:

1. أرِني نظامين تشغّلونهما اليوم وأستطيع فتحهما الآن. من يستخدمهما ومنذ متى؟
2. حين تعطّل أحدهما آخر مرة، كيف علمتم، وكم استغرق الإصلاح؟
3. سمّوا لي من سيكتبون هذه الشيفرة. هل هم موظفون لديكم؟ وعلى ماذا يعملون غير مشروعي؟
4. اقرأ لي الاستثناءات. ما الذي ليس داخلًا في هذا السعر؟
5. أي افتراض في هذا العرض، إن كان خاطئًا، يغيّر الرقم؟ وبكم؟
6. أي من عمليات التكامل هذه نفّذتموها من قبل، ومع أي نظام وأي إصدار؟
7. من يملك المستودع وحساب الاستضافة والنطاق والبيانات؟ أرِني البند.
8. هل أستطيع تصدير بياناتي كاملة بنفسي، بصيغة موثّقة، في أي يوم؟
9. كم يكلّف الدعم بعد التشغيل، وما الذي يغطّيه، وما زمن الاستجابة المكتوب؟
10. إذا ترك المطوّر الرئيسي العمل في الشهر السادس، فما الذي يبقى ليكمل غيره؟
11. ما الذي تحتاجونه منّي، ومتى، حتى يصمد هذا الجدول الزمني؟
12. ما الذي يجعلكم تقولون لي إن هذا المشروع لا ينبغي أن يُبنى؟

السؤال الأخير أكثرها إفادة. فالشركة التي لم ترفض عملًا قطّ لن يكون لديها جواب.

قبل التوقيع

احسم الدعم والملكية داخل العقد، لا في لحظة الارتياح بعد انتهاء التفاوض؛ فمعظم عمر النظام يقع في ما بعد التسليم. وإذا أردت تحديد نطاق نظامك تحديدًا دقيقًا قبل أن يسعّر أحد بناءه، يمكنك التواصل مع Softwiro.