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

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

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

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

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

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

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

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

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

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

المبدأ له اسم رسمي

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

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

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

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

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

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

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

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

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

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

اللي ما نجح من أول مرة

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

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

أهم درس طلعت فيه

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

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