عقلية مهندس الأنظمة: قبل ما تبني أي حل، افهم المشكلة الحقيقية أولاً

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

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

وكانت الصدمة: كل شي قالوه لي كان مختلف تمامًا عن اللي سمعته في الاجتماع.

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

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

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

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

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

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

قبل لا نكمل

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

كيف تفهم مشكلة حقيقية

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

التوثيق: كان نقطة ضعفي الحقيقية

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

نفس الفجوة تتكرر

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

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

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

ولما تشوف نفس النمط يتكرر أكثر من مرة، تقدر تبني حل واحد يخدم أكثر من قسم بدل ما تبني أداة منفصلة لكل قسم لحاله. وهذا الفرق بين نظام يكبر معاك، ونظام يتحول بعد سنتين لعشر أدوات متفرقة ولا أحد يعرف يستخدمها كلها. لاحقًا، توسّع نفس المبدأ ليصير منصة ARA Brain بأنظمتها السبعة، أتأكد بنفسي من كل مشكلة، أدور على النمط المشترك، وأبني حل واحد بدل حلول متفرقة.

بصراحة، مو كل شي نجح من أول مرة

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

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

وش أهم شي اتعلمته؟

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

فقبل ما تبني أي حل المرة الجاية، مهما كان نوع المشكلة أو من طلبها منك، اسأل نفسك سؤالين لا سؤال واحد: هل فهمت المشكلة فعليًا؟ ولو فهمتها، هل الحل اللي راح تسويه يسهّل عليهم فعلاً، أو فقط يضيف عليهم شي جديد يتعلمونه؟