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