#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 #هندسة_البرمجيات #تحليل_النظم #تحليل_المشكلات #تطوير_البرمجيات

يمكنك تحميل opencode وتجريب العديد النماذج مجانا بما فيها Ox Alpha الذي يشاع بأنه بآداء أفضل من Fable

لتسهيل الوصول له
حمل OpenCode desktop

https://opencode.ai/download

اضغط على النماذج اسفل مربع النص
واختر manage models
وفعل النموذج : Ox Alpha
ثم اختره تحت مربع النص واستمتع بالنموذج مجانا لمدة أسبوع

#012 — Stakeholders | أصحاب المصلحة

عندما تبدأ تحليل أي نظام، لا يكفي أن تسأل:
ما الذي يجب أن يفعله النظام؟
السؤال الأهم أولًا هو:
من الأشخاص والجهات التي يجب أن أستمع إليها؟
هنا يأتي مفهوم Stakeholders — أصحاب المصلحة.
الـStakeholder هو أي شخص أو جهة لها علاقة بالنظام؛ قد تستخدمه، تديره، تعتمد على مخرجاته، توفر له بيانات، تؤثر في قراراته، أو تتأثر بنتائجه.
ولهذا فليس كل Stakeholder مستخدمًا للنظام، وليس كل مستخدم صاحب القرار.

في متجر إلكتروني مثلًا قد نجد:

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

ثم تأتي خطوة أخرى مهمة: Stakeholder Analysis.
ليس جميع أصحاب المصلحة بنفس مستوى التأثير والاهتمام، ولذلك يمكن استخدام Power–Interest Matrix لتحديد طريقة التعامل معهم:
High Power + High Interest → إدارة ومشاركة وثيقة.
High Power + Low Interest → الحفاظ على رضاهم.
Low Power + High Interest → إبقاؤهم على اطلاع.
Low Power + Low Interest → المتابعة بالقدر المناسب.

وقد تبدأ المشكلة عندما تتعارض احتياجاتهم.

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

Understand → Compare → Prioritize → Negotiate → Balance

أي: يفهم، يقارن، يرتب الأولويات، يتفاوض، ثم يصل إلى توازن منطقي يخدم المشروع.
وأحد أخطر أخطاء التحليل هو بناء النظام بناءً على رأي شخص واحد، بينما بقية أصحاب المصلحة لم يتم الاستماع إليهم.
لذلك يمكن اختصار الفكرة بهذه المعادلة:
Right Stakeholders → Better Requirements → Better System

كلما فهمت أصحاب المصلحة بشكل أفضل، أصبحت متطلباتك أكثر واقعية، وقرارات التصميم أدق، وفرصة نجاح النظام أكبر.
سؤال للنقاش:
لو كنت ستحلل تطبيق توصيل طعام، من أهم 5 Stakeholders ستبدأ معهم قبل كتابة المتطلبات؟

المنشور القادم:

#013 — Process Modeling
كيف نفهم ونمثل خطوات العمل داخل النظام؟

م. طارق العمري
Software Engineer | Backend Developer

#SoftwareEngineering #Stakeholders #StakeholderAnalysis #RequirementsEngineering #SystemAnalysis #BusinessAnalysis #PowerInterestMatrix #Requirements #SystemDesign #SoftwareDevelopment #BackendDevelopment #SoftwareEngineer #ProcessModeling #هندسة_البرمجيات #تحليل_النظم #أصحاب_المصلحة #تطوير_البرمجيات