كيف نختار شركة لتطوير البرمجيات؟
ترى Mesterséges Intelligencia Központ Kft.، شركة تطوير البرمجيات في بودابست بالمجر، أن الاختيار الجيد يتوقف على ثلاثة أسئلة: هل يفهم المطوّر الهدف، وهل يمكن التحقق من عرضه، ولمن ستكون الشيفرة والنظام بعد التسليم.
الخلاصة: اكتبوا أولًا الهدف والمتطلبات الإلزامية، ولا تطلبوا العروض إلا بعد ذلك. ومن المفيد طلب الاطلاع على أعمال منجزة تعمل فعلًا، وعلى طريقة عمل شفافة، وطلب الوصول إلى الشيفرة؛ ويجب مقارنة العروض على أساس المواصفات المفصّلة نفسها، ويُفضَّل أن يكون ذلك على أساس الحجم المقاس. ويجب أن يثبّت العقد أيضًا الشيفرة المصدرية وحقوق الاستخدام، والسرية، وإصلاح الأخطاء، والتشغيل، وطريقة الخروج.
الهدف أولًا: ما الذي يجب أن يؤديه البرنامج؟
تبدأ معظم الاختيارات السيئة لا عند المطوّر، بل عند تكليف غامض. فإذا لم يُكتب ما يجب أن يؤديه البرنامج، فسيعني كل عرض شيئًا مختلفًا، ولن يكون هناك ما يُقاس عليه السعر ولا العمل المنجز. ولا تلزم مواصفات جاهزة (فالمطوّر الجيد يساعد في كتابتها)، لكن من المفيد التفكير مسبقًا في بعض الأمور:
- الهدف: ما المشكلة التي يحلّها البرنامج، وبمَ سيُعرف أنه ناجح.
- المستخدمون: مَن سيستخدمه: موظفون داخليون، أم عملاء، أم شركاء.
- المتطلبات الإلزامية: ما لا يمكن الإطلاق من دونه، مفصولًا عن بنود «سيكون من الجيد لو».
- الأنظمة القائمة: بماذا يجب أن يرتبط (ERP، وCRM، والمتجر الإلكتروني، وخدمة الفوترة، والبنك).
- البيانات: ما البيانات التي يعالجها، ومنها البيانات الشخصية أيضًا.
- الأطر: هل هناك موعد نهائي ملزم، أو قواعد داخلية، أو متطلبات للاستضافة أو للأمن.
ومن المفيد أيضًا تحديد ما إذا كانت هناك حاجة إلى تطوير مخصّص أصلًا، أم يكفي منتج جاهز، أو ربما منتج جاهز مع توسيع مخصّص. ويساعد في ذلك مقال برمجيات مخصّصة أم حل جاهز (SaaS)؟.
القائمة المختصرة: مَن يُستحسن التواصل معهم؟
لا حاجة إلى التواصل مع شركات كثيرة؛ فبضعة مرشحين مختارين بعناية أفضل من عروض كثيرة سطحية. معايير التضييق:
- عمل مماثل: هل بنى من قبل نظامًا بحجم وطبيعة مماثلين، كبرمجيات أعمال، أو متجر إلكتروني، أو تطبيق جوال، أو دمج للذكاء الاصطناعي.
- الملاءمة التقنية: هل يعمل بالتقنيات التي يجب أن ترتبط بها الأنظمة القائمة.
- التناسب في الحجم: هل تناسب قدرة الشركة المشروع؛ فالنظام الكبير يحتاج إلى تخصصات أكثر، والمهمة الصغيرة إلى أقل.
- اللغة والتوافر: هل يستطيع التنسيق معكم بلغتكم وفي منطقتكم الزمنية.
التحقق من الأعمال والمراجع
أقوى دليل هو برنامج يعمل فعلًا. اطلبوا من المرشحين أن يعرضوا نظامًا يمكن تجربته فعلًا، وأن يوضّحوا بالضبط ما كان دورهم فيه. وكثير من أعمال العملاء تحميه السرية، ولذلك لا يمكن دائمًا ذكر الأسماء. وفي هذه الحالة يكشف الكثير أيضًا وصفٌ مُجهَّل الهوية، أو عرض توضيحي، أو المنتجات الخاصة بالشركة.
وإذا قدّم عميل سابق مرجعًا، فمن المفيد طرح أسئلة محددة: هل التزم المطوّر بالنطاق المتفق عليه، وكيف عولجت التغييرات والأخطاء، وهل حصل العميل على الشيفرة المصدرية، وهل ما زالا يعملان معًا. فعبارة عامة مثل «كنا راضين» لا تقول الكثير؛ أما أن يواصل العميل تشغيل النظام معهم بعد التسليم، فهذا يقول الكثير.
الحوار التقني
من المفيد عقد حوار تقني مع كل مرشح، ويُفضَّل أن يحضره من جانبكم أيضًا مختص تقني. ولا تهمّ ثقة الإجابات بنفسها، بل ما إذا كان المطوّر يطرح الأسئلة ويسمّي المخاطر. أسئلة جيدة:
- كيف ستبدؤون العمل، وما المرحلة الأولى؟
- كيف ستربطون أنظمتنا القائمة، وما الذي تحتاجون إلى معرفته عنها؟
- كيف تختبرون، ومَن يقرّر أن جزءًا ما قد اكتمل؟
- مَن سيعمل على المشروع، ومَن سيكون الشخص المسؤول عن التواصل معنا؟
- أين سيعمل النظام، ومَن المسؤول عن التحديثات الأمنية؟
- إذا تضمّن النظام ذكاءً اصطناعيًا أيضًا: أيّ البيانات تذهب إلى أين، وماذا يحدث إذا أخطأ الذكاء الاصطناعي؟
ومن علامات التحذير أن يذكر مرشحٌ سعرًا وموعدًا نهائيًا دقيقين بعد الحوار الأول دون أن يطرح أي سؤال.
طريقة العمل والتواصل
في تطوير البرمجيات نادرًا ما تنشأ المفاجآت في الشيفرة، بل في التواصل في الغالب. ولذلك من المفيد السؤال عن كيفية اطّلاعكم على التقدّم أثناء العمل. علامات الممارسة الجيدة:
- التطوير على مراحل: يُقسَّم العمل إلى مراحل، وفي نهاية كل مرحلة يُعرض برنامج يعمل فعلًا، لا مجرد تقرير.
- الوصول إلى الشيفرة: يرى العميل مستودع الشيفرة (repository) منذ اليوم الأول، لا عند التسليم فقط.
- قائمة مهام قابلة للتتبّع: تظهر المهام والأخطاء والتغييرات في سجل مشترك.
- جهة اتصال ثابتة: هناك شخص يعرف المشروع ويستطيع اتخاذ القرارات.
- إدارة التغييرات: يُوصف المتطلب الجديد أو المعدَّل، ويُقاس أو يُقدَّر، ولا يدخل العمل إلا بعد الموافقة.
مقارنة العروض
لا يمكن مقارنة عرضين إلا إذا كانا يغطيان النطاق نفسه. ولذلك يتلقى كل مرشح الوصف المفصّل نفسه بندًا بندًا، واطلبوا منهم معرفة الوظائف والحجم اللذين حدّدوا السعر على أساسهما. وإذا كان المطوّر يقيس الحجم الوظيفي للبرنامج بطريقة معيارية، بنقاط COSMIC الوظيفية مثلًا، فيمكن التحقق من الحجم انطلاقًا من المواصفات نفسها؛ ويعرض مقال ما نقطة COSMIC الوظيفية، ولماذا هي أدق من تقدير الساعات؟ هذه الطريقة.
وإذا كان الفرق بين عرضين كبيرًا، فمن المفيد طرح الأسئلة التالية:
| السؤال | ما الذي يكشفه |
|---|---|
| على أيّ حجم وأيّ وظائف يقوم السعر؟ | هل سعّروا النطاق نفسه |
| ما الذي يرد بندًا منفصلًا؟ | هل يشمل العرض التكامل، وترحيل البيانات، والرسومات، والتشغيل |
| ما المتطلبات غير الوظيفية التي أخذوها في الحسبان؟ | الأداء، والأمن، وإمكانية الوصول |
| كيف يتعاملون مع التغييرات؟ | ماذا يحدث إذا ظهرت حاجة جديدة أثناء العمل |
| ما ترتيبات إصلاح الأخطاء بعد التسليم؟ | ما الذي يشمله المقابل، وما الذي يُعدّ عملًا إضافيًا |
| لمن ستكون الشيفرة المصدرية، وما الحقوق التي نحصل عليها؟ | هل يمكن لجهة أخرى مواصلة تطوير النظام |
| هل المحاسبة بسعر ثابت أم على أساس الجهد؟ | مَن يتحمّل مخاطر النطاق |
ويصلح السعر الثابت إذا كان النطاق مثبّتًا بندًا بندًا؛ أما المحاسبة على أساس الجهد فأكثر مرونة، لكن مخاطر النطاق تبقى على عاتق العميل. وفي الحالتين، المهم أن يكون النطاق قابلًا للقياس والتتبّع. وتصف صفحة التسعير طريقة تسعيرنا.
النقاط الجوهرية في العقد
العقد هو ما يُعتدّ به عند نزاع أو موقف غير متوقع. وما يلي معلومات إرشادية وليس استشارة قانونية: ومن المفيد أن يراجع محامٍ العقد أيضًا.
الشيفرة المصدرية وحقوق الاستخدام
يحمي قانون حق المؤلف المجري (القانون رقم LXXVI لسنة 1999، بالمجرية) برامج الحاسوب، بالشيفرة المصدرية وبالشيفرة الهدف (object code) على حد سواء، بوصفها مصنفات يحميها حق المؤلف (البند (c) من الفقرة (2) من المادة 1)، وينص على أن الحقوق المالية المتعلقة بالبرمجيات قابلة للنقل (الفقرة (3) من المادة 58). فالعميل إذن إما أن يكتسب الحقوق المالية، أو يحصل على ترخيص بالاستخدام؛ والأمران ليسا سواء.
وهذه بعض القواعد التي تجعل الصياغة الدقيقة مهمة: لا يمنح عقد الترخيص حقًا حصريًا إلا إذا نُصّ على ذلك صراحةً (الفقرة (1) من المادة 43)؛ وإذا لم يحدّد العقد طرق الاستخدام ونطاقه، اقتصر الترخيص على القدر الذي لا غنى عنه لتحقيق غرض العقد (الفقرة (5) من المادة 43)؛ وإذا كان المضمون غير واضح، وجب الأخذ بالتفسير الأكثر فائدة للمؤلف (الفقرة (3) من المادة 42)؛ ولا يجوز للمرخَّص له منح ترخيص لطرف ثالث إلا بإذن صريح من المؤلف (الفقرة (1) من المادة 46). ولذلك من المفيد أن يُثبَّت في العقد:
- تسليم الشيفرة المصدرية كاملة والوثائق، على مراحل أيضًا؛
- هل يكتسب العميل الحقوق المالية، أم ما نطاق الترخيص الذي يحصل عليه: هل هو حصري، وهل يجوز التعديل، وهل يجوز نقله إلى الغير؛
- أن المطوّر يملك الحقوق في الشيفرة التي كتبها موظفوه ومقاولوه من الباطن؛
- قائمة المكوّنات مفتوحة المصدر والمكوّنات المأخوذة من أطراف ثالثة المستخدمة، وتراخيصها.
السرية (NDA)
إذا كانت الفكرة أو بيانات الأعمال سرية، فمن المفيد توقيع اتفاقية عدم إفصاح (NDA) قبل الخوض في التفاصيل. وحدّدوا فيها ما يُعدّ معلومات سرية، ومَن يجوز له الاطلاع عليها، ومدة السرية، وما يحدث للمواد عند انتهاء العمل.
إصلاح الأخطاء والضمان
ينبغي أن ينص العقد على ما يُعدّ خطأً (أي انحرافًا عن المتطلب المثبّت)، وكيف يجري اختبار القبول، وما مستويات الخطورة، ومدى سرعة استجابة المطوّر لكل مستوى. وثبّتوا أيضًا المدة التي يصلح خلالها المطوّر مجانًا الأخطاء التي كانت خفية عند التسليم، وما الذي يُعدّ بالفعل تطويرًا إضافيًا.
التشغيل واتفاقية مستوى الخدمة (SLA)
إذا كان المطوّر يشغّل النظام بعد التسليم أيضًا، فإن اتفاقية مستوى الخدمة (service level agreement، SLA) تثبّت الشروط: التوافر الملتزَم به، وطريقة الإبلاغ عن الأعطال، وأوقات الاستجابة والإصلاح بحسب الخطورة، ونوافذ الصيانة، والنسخ الاحتياطية، والتقارير. وما لم يُكتب لا يمكن المطالبة به عند النزاع.
خطة الخروج
تجيب خطة الخروج عن سؤال: ماذا يحدث إذا لم يُستمرّ العمل مع المطوّر، سواء بسبب عدم الرضا أو بسبب زوال المطوّر. عناصرها:
- وثائق محدَّثة عن التثبيت، والبنية، والتشغيل؛
- مستودع الشيفرة، والاستضافة، والنطاق (domain)، وحسابات السحابة باسم العميل، أو على الأقل مع صلاحية وصول العميل؛
- ترتيب تسليم كلمات المرور ومفاتيح الوصول؛
- إمكانية تصدير البيانات بصيغة معيارية؛
- التعاون في التسليم إلى مطوّر جديد.
حماية البيانات: اتفاقية معالجة البيانات
إذا اطّلع المطوّر خلال العمل على بيانات شخصية (مثلًا لأنه يشغّل النظام، أو يختبر ببيانات حية)، فإنه يُعدّ عادةً بموجب GDPR معالِجًا للبيانات، ويلزم إبرام اتفاقية معالجة بيانات مكتوبة معه (المادة 28 من GDPR). ويجب أن تنص، ضمن أمور أخرى، على أنه لا يعالج البيانات إلا وفق التعليمات الموثّقة من العميل، وأنه يضمن السرية والأمن، ولا يستعين بمعالِج آخر إلا بإذن، ويحذف البيانات أو يعيدها عند انتهاء الخدمة، ويتيح التدقيق.
الممارسات الأمنية
لا يمكن إضافة الأمن إلى البرنامج لاحقًا، ولذلك من المفيد السؤال عن كيفية تعامل المطوّر معه. ونقطة انطلاق جيدة هي OWASP Top 10، وهي قائمة معروفة على نطاق واسع بأخطر المخاطر الأمنية لتطبيقات الويب؛ والإصدار الحالي هو OWASP Top 10:2025 (تم التحقق في 17 أكتوبر 2026). وتحتل المراكز الثلاثة الأولى فيها: الخلل في التحكم في الوصول، والتهيئة الأمنية الخاطئة، وإخفاقات سلسلة توريد البرمجيات. اسألوا:
- كيف تديرون الصلاحيات، وكيف تختبرون أن المستخدم لا يرى إلا بياناته الخاصة؟
- كيف تحدّثون المكتبات الخارجية المستخدمة، وكيف تعرفون إن أصبحت إحداها عرضة للثغرات؟
- أين تخزّنون كلمات المرور والمفاتيح، ومَن يستطيع الوصول إليها؟
- هل لديكم مراجعة للشيفرة (code review) واختبارات آلية؟
- كيف تُنشأ النسخ الاحتياطية، وهل جرّبتم استعادتها من قبل؟
مطوّر مستقل أم شركة تطوير؟
كلاهما قد يكون خيارًا جيدًا؛ والسؤال هو حجم المهمة وطول عمر النظام.
| المعيار | المطوّر المستقل | شركة التطوير |
|---|---|---|
| التواصل | مباشر، مع شخص واحد | عبر جهة اتصال، مع عدة مختصين |
| التخصصات | معرفة شخص واحد | تخصصات متعددة: الواجهة، والأنظمة الخلفية، والجوال، والتشغيل، والاختبار |
| قابلية الاستبدال | يتوقف العمل في حال المرض أو المغادرة | يستطيع أعضاء الفريق تولّي أعمال بعضهم بعضًا |
| القدرة | للمهام الأصغر والمحددة جيدًا | للأنظمة الأكبر، والعمل المتوازي |
| العقد | مع المختص مباشرة | مع الشركة، المسؤولة عن عمل الفريق |
| التشغيل على المدى الطويل | يتوقف على توافر المطوّر المستقل | يمكن الالتزام به بشكل منظّم |
يناسب المطوّر المستقل مهمةً محددة جيدًا، ولا سيما إذا كان لدى العميل قائد تقني خاص به يوجّه العمل ويستلمه. أما إذا كان النظام جزءًا من العمل اليومي للشركة، ويحتاج إلى تخصصات متعددة، وسيعمل لسنوات، فإن شركة التطوير تمثّل عادةً مخاطرة أقل. وخطة الخروج وتسليم الشيفرة المصدرية مهمان بالقدر نفسه في الحالتين.
علامات التحذير
- سعر وموعد نهائي دقيقان منذ الحوار الأول، دون أي أسئلة.
- لا مواصفات مكتوبة، أو عرض لا يوضّح ما الذي يغطيه.
- لا يستطيع العميل رؤية الشيفرة، ولن يحصل عليها إلا عند التسليم.
- إجابة غامضة عمّن سيعمل على المشروع.
- ليس واضحًا لمن ستكون الشيفرة المصدرية، وما الحقوق التي يحصل عليها العميل.
- التهرّب من اتفاقية معالجة البيانات أو من اتفاقية عدم الإفصاح.
- لا يوجد عمل قائم يعمل يمكن عرضه.
قائمة التحقق
| السؤال | الأمر سليم إذا |
|---|---|
| هل كُتب الهدف والمتطلبات الإلزامية؟ | يوجد وصف قصير يفهمه الجميع بالطريقة نفسها |
| هل رأينا عملًا قائمًا يعمل؟ | جرّبنا نظامًا مماثلًا واحدًا على الأقل |
| هل يفهمون المهمة؟ | طرحوا أسئلة وسمّوا المخاطر |
| هل سنرى التقدّم؟ | عروض توضيحية على مراحل، ووصول إلى مستودع الشيفرة |
| هل يمكن مقارنة العرض؟ | يغطي النطاق المفصّل نفسه، والبنود المنفصلة ظاهرة |
| هل سُوّيت مسألة الشيفرة المصدرية والحقوق؟ | يسمّي العقد التسليم ونطاق الحقوق |
| هل توجد اتفاقية عدم إفصاح واتفاقية معالجة بيانات؟ | وُقّعتا حيث يلزم |
| هل ثُبّت إصلاح الأخطاء والتشغيل؟ | مستويات الخطورة، وأوقات الاستجابة، وSLA |
| هل توجد خطة خروج؟ | الوثائق، وصلاحيات الوصول، وتصدير البيانات |
| هل سألنا عن الأمن؟ | إجابة محددة عن الصلاحيات، والتحديثات، والنسخ الاحتياطية |
الأسئلة الشائعة
مطوّر مستقل أم شركة تطوير؟
للمهمة الأصغر المحددة جيدًا، قد يكون المطوّر المستقل ذو الخبرة خيارًا جيدًا أيضًا، ولا سيما إذا كان لدى الشركة قائد تقني خاص بها. أما إذا كان النظام جزءًا من العمل اليومي، ويحتاج إلى تخصصات متعددة، وسيعمل مدة طويلة، فإن شركة التطوير تمثّل مخاطرة أقل، لأن العمل لا يتوقف على شخص واحد.
كيف نقارن بين عرضَي أسعار؟
لا يمكن مقارنة إلا العروض المقدّمة للمواصفات المفصّلة نفسها. اسألوا كلا مقدّمَي العرضين على أيّ حجم وأيّ وظائف بنى سعره، وما الذي يرد بندًا منفصلًا، وكيف يتعامل مع التغييرات. وإذا قيس الحجم بطريقة معيارية، مثل نقاط COSMIC الوظيفية، فيمكن التحقق منه انطلاقًا من المواصفات نفسها.
ماذا ينبغي أن يتضمن العقد؟
النطاق (المواصفات المفصّلة)، والسعر والجدول الزمني، وتسليم الشيفرة المصدرية ونطاق حقوق الاستخدام، والسرية، وترتيبات القبول وإصلاح الأخطاء، والتشغيل واتفاقية مستوى الخدمة (SLA)، وخطة الخروج، وإذا تعلّق الأمر ببيانات شخصية أيضًا، اتفاقية معالجة البيانات. هذه معلومات إرشادية وليست استشارة قانونية.
ماذا يحدث إذا اختفى المطوّر؟
إذا كانت الشيفرة المصدرية والوثائق وصلاحيات الوصول لدى العميل، فيستطيع مطوّر آخر أن يتولى النظام. ولذلك من المفيد رؤية مستودع الشيفرة منذ اليوم الأول، وإبقاء الاستضافة والنطاق باسمكم، وتثبيت خطة خروج في العقد. وإذا غابت هذه الأمور، فقد تكون مواصلة تطوير النظام صعبة وبطيئة.
لمن ستكون الشيفرة المصدرية؟
لمن يستحقها بموجب العقد: فبحسب قانون حق المؤلف المجري، الحقوق المالية المتعلقة بالبرمجيات قابلة للنقل، لكن ذلك ليس تلقائيًا. ومن المفيد أن ينص العقد على أن العميل يحصل على الشيفرة المصدرية كاملة، وعلى الحقوق التي يكتسبها فيها بالتحديد. ولدينا أيضًا، تخضع الشيفرة المصدرية وحقوق الاستخدام لأحكام العقد.
كيف نساعدكم؟
هكذا نعمل: الاستشارة الأولى مجانية، ونكتب المواصفات معًا، ونقيس حجم البرنامج بنقاط COSMIC الوظيفية، ومنه يُعَدّ العرض والجدول الزمني. ويتقدّم التطوير على مراحل، مع عرض توضيحي في نهاية كل مرحلة؛ ونوقّع عند الطلب اتفاقية عدم إفصاح (NDA)، وبعد التسليم نتولى التشغيل والصيانة أيضًا. وتخضع الشيفرة المصدرية وحقوق الاستخدام لأحكام العقد. وتصف صفحة كيف نعمل الخطوات، وتصف صفحة التسعير طريقة التسعير.
ونطوّر حاليًا نظام ERP وCRM كبيرًا؛ ونعرض مشاريعنا الخاصة التي يمكن تجربتها في صفحة أعمالنا، ويمكنكم القراءة عن الشركة في صفحة من نحن، وعن الأسئلة المتكررة في صفحة الأسئلة الشائعة. وإن كنتم تبحثون عن مطوّر، فاكتبوا لنا عبر بيانات التواصل الواردة في صفحة التواصل.