مشاريع في التجارة، التعليم، التقنية المالية والذكاء الاصطناعي. اخترت هنا الأنظمة التي كانت فيها مشكلة واضحة وقرارات هندسية تستحق الشرح.
أنا محمد نافع.
مهندس برمجيات وذكاء اصطناعي. بدأت تجربتي المهنية بالعمل مع Qi Card، وبعدها عملت على عدة مشاريع ومنتجات في مجالات مختلفة. اليوم أعمل بشكل مستقل وأتعاون مع الشركات والفرق على بناء المنتجات والأنظمة البرمجية.
أغلب المشاريع التي أفضلها ما تكون مجرد شاشة مرتبطة بـAPI. يكون فيها مستخدمون بصلاحيات مختلفة، بيانات تنتقل بين أكثر من جزء، وعمليات لازم يبقى سلوكها واضح حتى إذا فشل طلب، تغيرت حالة، أو حاول مستخدم الوصول إلى شيء خارج صلاحياته.
لهذا عادةً أبدأ من طريقة عمل النظام قبل شكل الواجهة.
أحدد من يستخدم المنتج، ماذا يحتاج، ماذا يستطيع أن يغيّر، وكيف يجب أن يتصرف النظام في الحالات الطبيعية وغير المتوقعة.
بعدها أبدأ بالبناء.
أحدد المستخدمين، الصلاحيات، تدفق البيانات، الحالات الأساسية ونقاط الفشل قبل أن تتحول القرارات إلى تعديلات متفرقة أثناء التنفيذ.
قاعدة البيانات، الـAPI والواجهة أجزاء من نفس المنتج. أي قرار في واحد منها لازم يكون تأثيره على بقية النظام واضحاً.
إذا المنتج عربي وإنجليزي، أبنيه من البداية على هذا الأساس: RTL وLTR، النصوص، الجداول، النماذج، وحركة المستخدم داخل الواجهة.
بالنسبة إلي، اكتمال الكود مو نهاية المشروع. أراجع الـflows الأساسية، حالات الخطأ، الصلاحيات، الـAPIs والنسخة المنشورة قبل التسليم، وأتأكد أن المنتج في بيئته الحقيقية يتصرف مثل ما صُمم له.
أسست وهندست منصة SaaS للتجارة واللوجستيات متعددة المستأجرين.
Banking System — عالجت مشكلة تكرار عمليات تحويل الأموال عند تنفيذ نفس الطلب أكثر من مرة، مع التركيز على سلامة المعاملة ومنع تكرار العملية.
NANO — منصة للتعرّف الضوئي على النصوص باستخدام الذكاء الاصطناعي.
Dynamic Form Builder — منشئ نماذج ديناميكي يتيح بناء وتهيئة النماذج بدون كتابة كود.
ما أضع هنا كل تقنية جرّبتها. هذه الأدوات التي أرجع لها بشكل متكرر في المشاريع.
Backend
Frontend
Infrastructure
AI & Automation
الشاشة النهائية مهمة، لكن مو هي القصة كلها.
في كل دراسة حالة أشرح المشكلة، القيود، القرارات التي أخذتها، والجزء الذي احتاج تفكير أكثر من مجرد كتابة الكود.
من عمليات منفصلة إلى منصة تشغيل واحدة
التاجر يحتاج يتابع الطلب من بدايته إلى نهايته، بينما النظام نفسه لازم يعرف من يملك الطلب، من يستطيع تعديله، ومن يقدر يشوف كل جزء من العملية.
في دراسة الحالة أشرح بنية النظام، تعدد الأدوار، وكيف تعاملت مع العمليات التي تمر بأكثر من حالة قبل أن تكتمل.
اقرأ دراسة حالة سندي
تطبيق الطالب ولوحة الإدارة مو نفس المنتج
الطالب والإدارة يتعاملون مع نفس المنظومة، لكن احتياجاتهم وصلاحياتهم مختلفة.
التحدي كان رسم الحد بين الطرفين بشكل واضح: ماذا يصل إلى تطبيق الطالب، ماذا يبقى داخل لوحة التشغيل، ومن يسمح له النظام بالدخول إلى كل جزء.
اقرأ دراسة حالة إيمار
ماذا يحدث عندما يُرسل نفس التحويل أكثر من مرة؟
في الأنظمة المالية، نجاح الـrequest مو كافي. المهم أن العملية نفسها ما تتكرر بسبب ضغط المستخدم، إعادة المحاولة أو مشكلة بالشبكة.
المشروع يركز على سلامة عمليات التحويل، إدارة حالة المعاملة، ومنع تنفيذ نفس العملية المالية أكثر من مرة.
اقرأ دراسة حالة Virtual Banking APIمشاريع أصغر من دراسات الحالة الرئيسية، لكنها تمثل أجزاء مختلفة من شغلي.
منتج لعميلنظام مدرسة التفوقمنصة تشغيل مدرسيةحضور، غيابات، أقساط ومتابعة يومية ضمن لوحة واحدة.شاهد المشروع
مشروع برنامج تدريبيتطبيق الفواتير المصغّرSuperQi Mini Appتطبيق لإنشاء الفواتير وعرضها داخل بيئة Mini App، حيث يعمل المنتج ضمن APIs وقيود منظومة أكبر منه.شاهد المشروعإذا عندك منتج جديد، نظام داخلي، Dashboard، Backend أو فكرة تحتاج تتحول إلى منتج، احچي لي عنها.
ما أحتاج منك Brief مرتب.
قل لي شنو موجود حالياً، شنو المفروض يصير، وشنو المشكلة اللي موقفه.
إذا أشوف أني أقدر أضيف للمشروع، أشرح لك شلون أتعامل وياه من البداية. وإذا مو ضمن شغلي، أقولها مباشرة.
