سندي

لم يبدأ سندي من فكرة تقنية، بل من ملاحظة كم من يوم التاجر العراقي يُستهلك في نقل المعلومة نفسها بين أنظمة لا تتحدّث مع بعضها. والمنصة تعمل اليوم على sendyiq.com.

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

وثمن ذلك ليس «قلة كفاءة» مجرّدة، بل تاجر لا يستطيع فعلياً أن يخبرك أي منتجاته يربح، وكم تكلّف خدمة منطقة توصيل معيّنة، وهل كان الشهر الماضي رابحاً — دون أن يجلس مساءً كاملاً مع آلة حاسبة.

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

• التاجر / صاحب المتجر

  يدير العمل بالكامل. يحتاج الصورة الكاملة — المنتجات والمخزون والطلبات والمال — دون أن يفهم التفاصيل الداخلية للنظام.

• مركز الاتصال والصندوق

  إدخال متكرر بحجم عالٍ. مُحسَّن للسرعة والعمل بلوحة المفاتيح، لا للاستكشاف.

• شركة التوصيل والأسطول

  ترى المهام وتحوّلات الحالة عبر تجّار كثر — لكن فقط الحقول التي يخوّلها عقدها.

• السائق

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

• العميل النهائي

  لا يرى اللوحة أبداً. يلتقي بالتاجر عبر متجر عام يجب أن يُحمَّل بسرعة على بيانات الهاتف.

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

• الطلبات والعملاء والمنتجات والمخزون والمخازن تشكّل النواة التشغيلية — لا شيء آخر يُطلق قبل أن تتطابق هذه.
• المتاجر والتوصيل والسائقون يمدّون دورة حياة الطلب نحو العميل والطريق.
• المدفوعات والمصاريف والخصومات والاشتراكات تربط المال بسجلات موجودة بدل إنشاء دفتر موازٍ.
• التحليلات وإدارة العملاء تقرأ من المصدر الواحد — ولا تحتفظ بأرقامها الخاصة أبداً.

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

• التحدّي

  أكثر من ٧٠ جدول بيانات كان كل منها يحل الترقيم والتصفية وحالات الفراغ والخطأ بطريقة مختلفة قليلاً.

  القرار

  دقّقتُ كل جدول وكل واجهة معتمدة على البيانات، ثم جمعتُها في بنية جداول واحدة قابلة للتركيب بعقود حالة مشتركة.

  المقايضة

  إعادة هيكلة كبيرة وغير براقة لم تنتج ميزات جديدة — لكنها سدّدت نفسها في كل شاشة بُنيت بعدها.

• التحدّي

  عكس الواجهة للإنجليزية كان يكسر باستمرار الحقول الرقمية والنقدية والتقنية.

  القرار

  التخطيط الاتجاهي يُعكس؛ أما المعرّفات والعملة وأرقام الهواتف والروابط والرموز التقنية فتُعزل كجزر LTR بغضّ النظر عن اللغة.

  المقايضة

  كل حقل جديد يجب أن يعلن سلوكه الاتجاهي — انضباط أكبر في البداية، وصفر أخطاء ثنائية الاتجاه لاحقاً.

• التحدّي

  شركاء التوصيل والتجّار احتاجوا شاشة الطلب نفسها بمستويات ظهور مختلفة جوهرياً.

  القرار

  تحقّق الصلاحيات يعمل على مستوى الحقل لا المسار فقط، فتُعرض الشاشة الواحدة بصدق لسبعة أدوار.

  المقايضة

  منطق عرض أعقد، لكن دون شاشات مكرّرة تتباعد مع الوقت.

• تعدّد المستأجرين دون تسريب

  كل استعلام وكل اشتراك Socket وكل ملف مرفوع محدّد بالمستأجر. الفشل هنا ليس خللاً عادياً بل رؤية تاجر لعملاء تاجر آخر — لذلك يُفرض نطاق المستأجر في طبقة البيانات لا بالثقة بالعميل.

• التتبّع الحي دون فوضى

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

• التخطيط ثنائي الاتجاه على نطاق واسع

  دعم RTL سهل في صفحة تعريفية وصعب فعلاً عبر جداول تشغيلية كثيفة ومخططات ومنتقيات تواريخ وقوائم جانبية. بناء التخطيط بخصائص منطقية من البداية كان أرخص من عكس منتج LTR مكتمل.

• تكاملات تفشل بلباقة

  بوابات الدفع ومزوّدو التوصيل خارجيون وقد ينقطعون. جلسات الدفع ومعالجة Webhooks وواجهات حالة المعاملات مبنية بحيث يُضعف انقطاع المزوّد وحدة واحدة بدل إيقاف عمل التاجر.

• الحالة

  في الإنتاج، مُختبر مع تجّار تجريبيين

• دوري

  مؤسس ومهندس برمجيات متكامل

• الواجهات المُنجزة

  لوحة التاجر، تطبيق السائق، المتاجر

• اللغات

  العربية (افتراضية) والإنجليزية

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