#011 — Understanding the Problem | فهم المشكلة
في هندسة البرمجيات، أحد أكبر الأخطاء هو أن نبدأ في تصميم الحل قبل أن نتأكد أننا فهمنا المشكلة الحقيقية.
قد يقول العميل:
"الطلبات تتأخر، نحتاج نظامًا جديدًا."
لكن هل النظام هو المشكلة فعلًا؟ ربما التأخير سببه طريقة توزيع الطلبات، أو تعدد قنوات الاستقبال، أو ضعف التواصل بين الأقسام، أو عملية يدوية غير منظمة.
لهذا يجب أن نفرّق بين:
Symptom — العرض الظاهر
و
Root Cause — السبب الجذري
فالعرض يخبرنا أن هناك مشكلة، لكنه لا يخبرنا دائمًا لماذا تحدث.
إحدى الطرق البسيطة للوصول إلى السبب الحقيقي هي 5 Whys؛ لا تتوقف عند أول إجابة، بل استمر في السؤال "لماذا؟" حتى تصل إلى السبب الذي إذا عالجته، تقل احتمالية تكرار المشكلة.
لكن السؤال وحده لا يكفي. التحليل الجيد يعتمد على Evidence وليس Assumptions.
مقابلات المستخدمين، البيانات والتحليلات، Logs، تذاكر الدعم، الملاحظة المباشرة، والاستبيانات قد تغيّر فهمك للمشكلة بالكامل.
مثال:
العميل يقول:
"تطبيق التوصيل بطيء، نحتاج Server أقوى."
لكن بعد التحليل نكتشف أن السيرفر يعمل بشكل طبيعي، بينما معظم التأخير يحدث أثناء تعيين السائق للطلب.
هنا لم تكن المشكلة في قوة السيرفر أصلًا، بل في آلية توزيع الطلبات.
وهذا يوضح التسلسل الصحيح:
Symptom → Investigation → Root Cause → Need → Requirement → Solution
وليس:
Problem → أول حل يخطر في بالك
ومن المهم أيضًا فهم السياق: الأشخاص، العمليات، البيانات، التقنية الحالية، القواعد والقيود، وبيئة العمل. لأن المشكلة نفسها قد تحتاج حلًا مختلفًا من مؤسسة إلى أخرى.
بعد ذلك نستطيع صياغة Problem Statement واضحة تحدد من يعاني من المشكلة، وما المشكلة، ومتى أو أين تحدث، وما أثرها.
القاعدة التي أعود إليها دائمًا:
Understand First. Solve Second.
افهم أولًا... ثم حل.
مهندس البرمجيات القوي لا يتميز فقط بقدرته على بناء حلول ممتازة، بل بقدرته على التأكد من أنه يبني الحل الصحيح للمشكلة الصحيحة.
سؤال للنقاش:
لو قال لك عميل:
"موقعي بطيء، نحتاج Server أقوى."
ما أول شيء ستفعله قبل الموافقة على هذا الحل؟
المنشور القادم:
#012 — Stakeholders
من الأشخاص والجهات الذين يجب أن نستمع إليهم قبل تحديد متطلبات النظام؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #UnderstandingTheProblem #ProblemAnalysis #RootCauseAnalysis #5Whys #SystemAnalysis #RequirementsEngineering #ProblemSolving #BusinessAnalysis #SoftwareDevelopment #SystemDesign #BackendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تحليل_النظم #تحليل_المشكلات #تطوير_البرمجيات
في هندسة البرمجيات، أحد أكبر الأخطاء هو أن نبدأ في تصميم الحل قبل أن نتأكد أننا فهمنا المشكلة الحقيقية.
قد يقول العميل:
"الطلبات تتأخر، نحتاج نظامًا جديدًا."
لكن هل النظام هو المشكلة فعلًا؟ ربما التأخير سببه طريقة توزيع الطلبات، أو تعدد قنوات الاستقبال، أو ضعف التواصل بين الأقسام، أو عملية يدوية غير منظمة.
لهذا يجب أن نفرّق بين:
Symptom — العرض الظاهر
و
Root Cause — السبب الجذري
فالعرض يخبرنا أن هناك مشكلة، لكنه لا يخبرنا دائمًا لماذا تحدث.
إحدى الطرق البسيطة للوصول إلى السبب الحقيقي هي 5 Whys؛ لا تتوقف عند أول إجابة، بل استمر في السؤال "لماذا؟" حتى تصل إلى السبب الذي إذا عالجته، تقل احتمالية تكرار المشكلة.
لكن السؤال وحده لا يكفي. التحليل الجيد يعتمد على Evidence وليس Assumptions.
مقابلات المستخدمين، البيانات والتحليلات، Logs، تذاكر الدعم، الملاحظة المباشرة، والاستبيانات قد تغيّر فهمك للمشكلة بالكامل.
مثال:
العميل يقول:
"تطبيق التوصيل بطيء، نحتاج Server أقوى."
لكن بعد التحليل نكتشف أن السيرفر يعمل بشكل طبيعي، بينما معظم التأخير يحدث أثناء تعيين السائق للطلب.
هنا لم تكن المشكلة في قوة السيرفر أصلًا، بل في آلية توزيع الطلبات.
وهذا يوضح التسلسل الصحيح:
Symptom → Investigation → Root Cause → Need → Requirement → Solution
وليس:
Problem → أول حل يخطر في بالك
ومن المهم أيضًا فهم السياق: الأشخاص، العمليات، البيانات، التقنية الحالية، القواعد والقيود، وبيئة العمل. لأن المشكلة نفسها قد تحتاج حلًا مختلفًا من مؤسسة إلى أخرى.
بعد ذلك نستطيع صياغة Problem Statement واضحة تحدد من يعاني من المشكلة، وما المشكلة، ومتى أو أين تحدث، وما أثرها.
القاعدة التي أعود إليها دائمًا:
Understand First. Solve Second.
افهم أولًا... ثم حل.
مهندس البرمجيات القوي لا يتميز فقط بقدرته على بناء حلول ممتازة، بل بقدرته على التأكد من أنه يبني الحل الصحيح للمشكلة الصحيحة.
سؤال للنقاش:
لو قال لك عميل:
"موقعي بطيء، نحتاج Server أقوى."
ما أول شيء ستفعله قبل الموافقة على هذا الحل؟
المنشور القادم:
#012 — Stakeholders
من الأشخاص والجهات الذين يجب أن نستمع إليهم قبل تحديد متطلبات النظام؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #UnderstandingTheProblem #ProblemAnalysis #RootCauseAnalysis #5Whys #SystemAnalysis #RequirementsEngineering #ProblemSolving #BusinessAnalysis #SoftwareDevelopment #SystemDesign #BackendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تحليل_النظم #تحليل_المشكلات #تطوير_البرمجيات