يقترح مساعد البرمجة تعديلات، ثم يقوم شخص ما بقبولها ودمجها وتحمل مسؤوليتها. لا تتغير سلسلة المساءلة هذه بتغير كاتب المسودة، ومن الأفضل ألا تتغير: فهي الطريقة الوحيدة لضمان وجود شخص يمكن الرجوع إليه عند حدوث أي خلل غير متوقع في النظام أثناء التشغيل.
تكمن المشكلة في تخفيف المسؤولية ضمنيًا، دون أن يقرر أحد ذلك صراحةً. لا أحد يُعلن أنه لم يعد مسؤولاً عن الكود الذي كتبه. ببساطة، تتسع الفجوة بين من يقبلون الكود ومن فهموه.
هذا الارتباك مكلف لأنه يستنزف الميزانية ويقوض مصداقية المبادرة. فعندما يسأل أحدهم بعد ستة أشهر عما تحسن، تكون الإجابة الصادقة عادةً "التجربة الأولية"، وهذا لا يبرر برنامج تحول.
ثلاث آليات، جميعها صامتة:
يصبح التقييم سطحياً. عندما تحدث تغييرات كبيرة بشكل متكرر، يتحول موقف المراجع من "أنا أفهم هذا وأوافق عليه" إلى "يبدو معقولاً". قام تقرير DORA لعام 2024 بقياس التأثير الإجمالي: مع زيادة اعتماد الذكاء الاصطناعي، انخفض استقرار التسليم بمقدار 7.2%، وهو ما يرتبط بنمو أحجام دفعات التغيير.
يصبح تحديد المؤلف أمراً غامضاً. في إحدى الحالات، قوبل السؤال "من كتب هذا؟" بالإجابة "لقد أنشأناه". هذه الإجابة تمنع استمرار المحادثة.
الثقة تحل محل التحقق. يعمل الكود بشكل صحيح في بيئة الاختبار، لذا يُفترض أنه جيد. لكن العمل الجيد يختلف عن كونه جيدًا: فالأخير يشمل ما سيحدث عند تغير السياق.
في التقرير نفسه الصادر عن منظمة DORA، أعرب 39.21% من المطورين عن قلة ثقتهم أو انعدامها في الكود المُولّد. وهذه نتيجة غير مُريحة في الاتجاه المعاكس: فهناك انعدام ثقة مُعلن، ومع ذلك فإن حجم الكود المقبول في ازدياد.
لا يتعلق الأمر بإلقاء اللوم، بل بالقدرة على الإجابة عن أربعة أسئلة حول أي جزء من النظام:
يتحمل مسؤولية الكود كل من يستطيع الإجابة على الأسئلة الأربعة جميعها، سواءً كُتب بواسطة شخص أو أداة. أما من لا يستطيع الإجابة على أي منها، فلا يتحمل المسؤولية، حتى لو كان اسمه مدرجاً كمؤلف في المستودع.
دور | ما الذي تقدمه هذه الأداة؟ | ما تبقى إنسانياً |
|---|---|---|
تصميم | البدائل والأمثلة | أن تختار وأن تقبل الخيار |
تطبيق | مسودة وظيفية | تأكد من أنه يؤدي ما تتوقعه الشركة. |
مراجعة | الكشف عن الأنماط المعروفة | الحكم على مدى ملاءمة القرار وعواقبه |
عملية | التنبيهات والتشخيص | اتخاذ القرار بشأن ما يجب فعله عند حدوث خطأ ما |
مسؤولية | لا أحد | الجميع |
العبارة الأخيرة ليست مجرد كلام بلاغي. لا تتحمل أي أداة مسؤولية مشتركة أمام العميل أو المدقق أو المحكمة. فالمؤسسة مسؤولة عما يفعله برنامجها، بغض النظر عن كيفية إنتاجه، كما تم توضيحه في قضية روبوت الدردشة الخاص بشركة طيران كندا التي تم حلها عام 2024.
لا أحد يدمج ما لا يستطيع تفسيره. القاعدة الأساسية. لا تتطلب فهم كل التفاصيل، بل القدرة على الإجابة على الأسئلة الأربعة المذكورة أعلاه.
لكل تغيير شخص مسؤول عنه بالاسم. ليس فريقاً. بل شخص واحد مسؤول عن ذلك الجزء من النظام ويمكن توجيه الأسئلة إليه.
تُكتب الاختبارات الحاسمة بواسطة شخص واحد. إذا كانت نفس الأداة تولد كلاً من التنفيذ والاختبار الذي يتحقق منه، فإن الدائرة تغلق على نفسها ولا تتحقق من أي شيء ذي صلة.
حجم التغيير محدود. إنه الإجراء الذي يجعل الإجراءات الثلاثة السابقة ممكنة. لا يمكن مراجعة أي تغيير جوهري بشكل كامل، مهما كانت نوايا المراجع حسنة.
إذا كانت شركتك تستعين بمصادر خارجية لتطوير البرامج، فإن هذه المحادثة لها تأثير مباشر على العقد. إليك ثلاثة أسئلة للمزود:
من المسؤول عن العيوب في الكود المُسلّم؟ لا يُعدّ العيب تغييرًا في نطاق العمل. يجب تصحيحه مجانًا وتوثيقه كتابيًا. في حالتنا، نضمن ذلك بموجب ضمان Rain: فنحن نصحح أي عيوب في الكود الذي نقدمه، مدى الحياة.
هل يمكنك شرح أي جزء من النظام بعد ستة أشهر؟ الاختبار بسيط: اطلب شرحًا لوحدة مختارة عشوائيًا.
ما هي وثائق القرار المقدمة؟ ليس المقصود هنا التعليق سطرًا بسطر، بل شرح سبب اختيار كل نهج وما تم استبعاده. هذا ما يسمح لفريق آخر بتولي المهمة.
المورد الذي يقبل هذه الشروط الثلاثة يؤكد التزامه بالحفاظ على سلسلة المسؤولية سليمة. أما المورد الذي يقيّد هذه الشروط فيشير إلى مواطن الخلل المحتملة.
بالنسبة للمدير التقني الذي يرغب في معرفة الوضع الحالي لفريقه، هناك تمرين يستغرق ساعة واحدة: اختر ثلاثة أجزاء من النظام عشوائياً واطلب من المسؤولين عنها الإجابة على الأسئلة الأربعة..
لا تقيس النتيجة جودة الكود، بل تقيس شيئاً أكثر أهمية: ما إذا كانت المؤسسة تتحكم في نظامها أم أنها تملكه فقط.
الشخص الذي يقبل البرنامج ويُدمجه في النظام، والمنظمة التي تُشغّله. لا توجد أداة تتحمل المسؤولية أمام العميل أو المدقق أو المحكمة: فالشركة هي المسؤولة عما يفعله برنامجها، بغض النظر عن كيفية إنتاجه.
من خلال أربعة أسئلة: ما فائدة هذا من الناحية التجارية؟ ولماذا هو على هذا النحو؟ وما البديل الذي تم استبعاده؟ وما الذي سيتعطل إذا تم تغييره؟ وكيف نضمن استمرارية عمله؟ من يستطيع الإجابة على الأسئلة الأربعة جميعها يتحمل مسؤولية هذا الكود، سواءً كتبه شخص أو أداة.
من خلال ثلاثة مسارات صامتة: تصبح المراجعة سطحية مع ازدياد حجم التغييرات، وتصبح عملية تحديد المسؤولية غامضة حتى يصبح الرد على الحادث هو "لقد تسببنا فيه"، وتحل الثقة في نجاح الاختبارات محل التحقق من أن السلوك هو ما تتوقعه الشركة.
رابعاً: لا أحد يدمج ما لا يستطيع تفسيره، ولكل تغيير شخص مسؤول عنه وليس فريق، ويتم كتابة الاختبارات الحاسمة بواسطة شخص وليس نفس الأداة التي أنشأت التنفيذ، ويتم تحديد حجم التغييرات بحيث تكون المراجعة ممكنة.
يجب أن يكونوا مسؤولين عن العيوب في الكود المُسلّم بدون أي تكلفة وبشكل كتابي، وأن يكونوا قادرين على شرح أي جزء من النظام بعد ستة أشهر، وتقديم وثائق عن القرارات المتخذة والبدائل التي تم استبعادها، وليس مجرد تعليقات في الكود.
بحسب تقرير وزارة الصحة والخدمات الإنسانية لعام 2024، أعرب 39.21% من المشاركين عن قلة ثقتهم أو انعدامها في النظام. وهذه نتيجة مهمة لأنها تتزامن مع زيادة في عدد الاختبارات المقبولة، مما يشير إلى أن عدم الثقة المعلنة لا تُترجم بالضرورة إلى زيادة في عدد الاختبارات.
هل يستطيع فريقكم شرح أي جزء من نظامكم؟ يقوم التدقيق الفني لدينا بتقييم البنية، والبرمجيات، والديون، وقابلية الصيانة الفعلية، وذلك كتابياً وفي غضون 10 أيام عمل. طلب التدقيق → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
