عندما طلب العميل الشيفرة المصدرية بعد تسليم المشروع

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

تجربة واقعية؛ عندما طُرحت مسألة الشيفرة المصدرية بعد انتهاء المشروع

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

وهنا طُرحت مسألة ملكية الشيفرة المصدرية وأصبحت موضع خلاف.

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

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

لماذا طلبت تقديم الطلب رسميًا؟

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

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

وافقوا في البداية على هذا الأمر.

لكن حدث أمر آخر

بعد فترة، اكتشفت، من دون أن يتم إبلاغي مسبقًا، أنهم أوقفوا استخدام النظام وقرروا إعادة كتابة البرنامج بالكامل من البداية بشكل منفصل.

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

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

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

اقرأ العقد قبل التوقيع

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

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

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

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

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

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