أصبح بناء التطبيقات أسهل. ماذا بعد؟

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

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

النسخة الأولى من تطبيقك تساعدك على فهم المشكلة واختبار نهج الحل

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

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

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

بعد ذلك، تظهر ثلاثة أسئلة يتوقف عليها عمل التطبيق يوميًا: ما البيانات التي يعتمد عليها، وكيف ستصونه، وما الذي يمكنك تفويضه إلى الوكلاء؟

بيانات يعتمد عليها التطبيق ويثق بها المستخدمون

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

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

وتؤثر في الإجابة أمور تبدو أبسط أيضًا. ترسل الأجهزة البيانات بصيغ مختلفة، وتصل الرسائل متأخرة، وتظهر فجوات في المسار المسجل. «المركبة لم تصل» و«لم نتلق بيانات الوصول» حالتان مختلفتان. يحتاج التطبيق إلى التمييز بينهما، وإلا فقد تبدو فجوة البيانات وكأن السائق تأخر.

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

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

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

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

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

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

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

المصادقة والتفويض للوكلاء

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

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

إذا تغيرت مهمة السائق، فمن المفيد معرفة من غيّرها ومتى. وإذا لم يتمكن الوكيل من إكمال مهمة، فينبغي فهم الصلاحية التي كانت تنقصه. يسهّل هذا السجل مراجعة النتائج وتحديد ما يمكن تفويضه إليه لاحقًا. يمكن البدء بإتاحة قراءة البيانات، ثم إضافة إجراءات تدريجيًا مع تنامي الثقة في عمل الوكيل.

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