معظم نزاعات البرمجيات تعود إلى بند واحد مفقود

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

سبب تعذّر حسم ذلك الجدل ليس تقنيًا. العقد لم يحدد إطلاقًا ما تعنيه "تعمل". من دون معيار قبول، يقول المطوّر إنها سُلِّمت، ويقول العميل إنه لم يستلمها، وكلاهما محق بمقياسه الخاص.

هذه الفجوة الواحدة هي الخيط المشترك عبر معظم نزاعات البرمجيات التي رأيتها.

كيف تُكتب بند قبول يعمل فعليًا

القبول هو اللحظة التي تُطلق العواقب القانونية للتسليم، بما فيها بدء سريان فترة ضمان العيوب. تاريخ قبول غير محدد يعني تاريخ نهاية غير محدد للمسؤولية أيضًا.

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

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

ربط القبول بالرضا هو أسوأ الخيارات على الإطلاق. القبول المشروط بـ"رضا العميل" يخلق التزامًا مفتوحًا، وعمل المطوّر لا ينتهي فعليًا أبدًا.

حقوق الملكية الفكرية لا تنتقل من تلقاء نفسها

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

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

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

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

عقد بلا عملية إدارة تغيير لا ينجو من احتكاك المشروع

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

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

أجيبوا عن هذه الخمسة ويتوقف التغيير عن كونه أزمة ويصبح عملية.

أن تصبح معالج بيانات يمكن أن يحدث من دون أن يلاحظ أحد

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

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

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

الصيانة عقد منفصل

أخيرًا، الصيانة والدعم. هذا التزام منفصل عن التطوير وينبغي معاملته بشكل منفصل.

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

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

من ينبغي أن يصوغ هذا

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

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