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

ما هو الـ 5 لماذا التقنية؟

(تويودا) قامت بأخذ هذه الممارسة كجزء من نظام إنتاج (تويوتا) الذي أصبح لاحقاً الأساس لتطور برامج (لين) و(لين) الافتراضية مباشرة: عندما تحدث مشكلة، تسأل "لماذا" مراراً وتكراراً، خمس مرات،

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

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

علم النفس خلف الـ 5 أسباب

The 5 Whys technique is effective because it counteracts several cognitive biases that plague problem-solving in engineering teams. The first is the anchoring bias], where teams latch onto the first explanation that seems reasonable and stop investigating. By mandating multiple layers of questioning, the 5 Whys forces teams to move past their initial anchor and consider deep contributing factors.

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

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

تطبيق 5 أسباب في تطوير البرامج الهندسية

In the context of engineering software, the 5 Whys can be applied across multiple stages of the development life cycle. During debugging, it helps developers move beyond the immediate mistake message to understand the formation, environmental, or design choices that enabled the green to exist. During testing

مثال على الخمسة أسباب في العمل

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

  • Problem:] The application crashes during login.
  • Why? because the login function throws an unhandled exception.
  • لماذا؟ ] لأن بيانات المستخدمين لا تسترد بشكل صحيح من قاعدة البيانات.
  • لماذا؟ لأن استفسار قاعدة البيانات يعيد قيماً باطلة بدلاً من سجلات المستخدمين.
  • لماذا؟ ] لأن سلسلة وصلات قاعدة البيانات غير صحيحة، مما يتسبب في أن يضرب الاستفسار على قاعدة بيانات غير موجودة أو غير موثقة.
  • Why? ] because the formation file was updated during a recent deployment with an incorrect connection string, and the change was not caught by automated validation.

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

دليل الخطوة خطوة إلى الأمام لإجراء تحليل لخمسة أسباب

لكي تخرج الفرق الهندسية من الخمسة أسباب يجب أن تتبع عملية قابلة للتكرار وهنا دليل الخطوة التالية:

الخطوة 1: تعريف المشكلة بوضوح

اكتبي المشكلة كما يبدو، مع قدر الإمكان من التحديد، تجنب الأوصاف الغامضة مثل "النظام بطيء" بدلاً من ذلك، اذكري: "وقت الاستجابة للآداب المُستخدمة تجاوز 5 ثواني خلال ذروة الحمل في 15 آذار/مارس".

الخطوة 2: تجميع المشاركين المناسبين

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

الخطوة 3: إسألي أول "لماذا"

ابدأ بسؤال سبب حدوث المشكلة اكتبي الجواب لا تقبلي "لأن لدينا حشرات" أو "لأن شخصاً ما ارتكب خطأ" ادفعي من أجل إجابة واقعية محددة مثل "لأن مجموعة قواعد البيانات استنفدت الروابط المتاحة"

الخطوة الرابعة: اسأل "لماذا" مرة أخرى لكل رد

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

الخطوة 5: تحديد الإجراءات الإصلاحية

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

الخطوة 6: الوثيقة والتقاسم

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

دراسة الحالة الحقيقية في العالم: حل مرحلة انقطاع النظام

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

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

  • Problem:] The application becomes unresponsive for 10-15 minutes every two to three weeks.
  • Why? ] because the application process stops accepting connections.
  • لماذا؟ ] لأن العملية تُنفَّذ من الذاكرة المتاحة ونظام التشغيل OOM-kills it.
  • Why? ] because memory usage gradually increases over time without being released.
  • لماذا؟ ] لأن وظيفة خلفية تتزامن مع المحتوى من طرف ثالث من الأطراف API لها إشارات إلى أشياء تمنع جمع القمامة.
  • لأن الوظيفة تستخدم مادة قائمة ثابتة تنمو بدون قيود مع كل دورة متزامنة لا تنظف أبداً القيود القديمة

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

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

فوائد استخدام الـ 5 أسباب في السياقات الهندسية

وتكتسب الأفرقة الهندسية التي تعتمد الـ 5 أسباب كممارسة معيارية عدة مزايا متميزة:

  • Root Cause Identification:] The technique setss the fundamental issue rather than just addressing symptoms, preventing teams from wasteting time on superficial fixes that do not last.
  • Cost-Effective Resolution:] By addressing the true root cause, teams avoid repeated expenditures of time and effort on the same class of problems. The upfront investment in a thorough analysis pays for itself many times over in reduced incident response and rework.
  • Cultural Shift Toward Systemic Thinking:] regular use of the 5 Whys encourages teams to think in terms of systems, processes, and environments rather than individual blame. This shift leads to a more collaborative and psychologically safe engineering culture.
  • Knowledge Capture and Learning:] Each 5 Whys analysis produces a documented chain of reasoning that serves as a learning artifact for the entire organization. New team members can study past analyses to understand common failure modes and the rationale behind current engineering practices.
  • Prevention of Recurrence:] because the corrective actions target the root cause, the same issue is unlikely to reappear. This contrasts with shall that merely treat symptoms and leave the underlying vulnerability in place.

القيود وكيفية التخفيف منها

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

تجاوز تبسيط المشاكل المعقدة

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

Mitigation:] Use the 5 Whys in combination with other analysis methods, such as ]fishbone diagrams] (Ishikawa diagrams) or fault analysis. These tools help map multiple cagramus

فترة تأكيد

إذا كان لدى الفريق فكرة مسبقة عن السبب الجذري ربما يوجّهون الأسئلة نحو ذلك الاستنتاج بغموض، يسألون عن السبب الرئيسي؟

Mitigation:] Ensure diverse perspectives are involved in the analysis. Include team members from different disciplines, such as QA, operations, and product management. Assign a facilitator who is not directly involved in the affected system to keep the questioning neutral and open-ended.

توقف مبكراً

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

Mitigation: ] Establish a rule that the analysis is not complete until the answer points to a process, policy, or system that can be changed. If the answer is about an individual's action, ask " Why? again to uncover the systemic factors that enabled that action.

عدم وجود نتائج عملية

وهناك خمسة أسباب تؤدي إلى نتائج مثيرة للاهتمام ولكنها لا تؤدي إلى تغييرات ملموسة، وبدون متابعة، يضيع الجهد.

Mitigation: ] For each root cause identified, define at least one specific, measurable corrective action with an owner and a deadline. Track these actions in the team's project management system and review them in subsequent retrospectives. The analysis is only as valuable as the changes it drives.

إدماج الأسباب الخمسة في أساليب حل المشاكل الأخرى

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

Diagrams Fishbone

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

Root Cause Analysis (RCA)

وفي الأطر الرسمية للتقييمات الإقليمية، كثيرا ما تستخدم الـ 5 أسباب كتقنية أساسية لإجراء المقابلات، ويمكن أن توثق الأفرقة النتائج في نموذج قياسي للتقييمات الإقليمية يتضمن وصف المشاكل، والجدول الزمني، وسلسلة السببية، والسبب الجذري، والإجراءات التصحيحية، والدروس المستفادة.() ويضمن استخدام نموذج الاتساق عبر التحليلات وييسر مقارنة النتائج في مختلف الحوادث.

بلا معنى بعد الموت

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

التحسين المستمر (كازين)

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

أفضل الممارسات للفرق الهندسية

وبغية تحقيق أقصى قدر من الفعالية في تطوير البرامجيات الهندسية، ينبغي أن تعتمد الأفرقة أفضل الممارسات التالية:

  • حدد الوقت لإجراء تحليل شامل: ] لا تستعجل العملية.
  • أكتب كل إجابة: ] Document the chain of questions and answers in real time. This creates a clear record and prevents the team from lose track of the logical.
  • Verify the root cause with data:] Before implementing corrective actions, test whether the identified root cause actually produces the observed problem. This might involve reproducing the issue in a staging environment or analyzing logs and metrics to confirm the causal link.
  • ]Keep the analysis actionable:] Each root cause should lead to at least one concrete change in code, formation, process, or infrastructure. Avoid abstract recommendations that no one owns.
  • Share findings broadly:] Post the analysis in a shared knowledge base, internal wiki, or engineering blog. Encourage other teams to review it and apply similar reasoning to their own systems.
  • ] iterate on the technique itself:] After a few analyses, hold a retrospective on the 5 Whys process itself. ask the team what worked, what did not, and how the method can be improved for future use.

خاتمة

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