تطبيقات ويب مخصصة

ما المشكلات التي تحلّها تطبيقات الويب المخصصة؟

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

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

برنامج جاهز أم تطوير مخصص؟

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

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

مجالات الاستخدام المعتادة

هذه أمثلة شائعة على تطبيقات الويب المخصصة:

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

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

مراحل تطوير تطبيقات الويب: من تحليل الاحتياج إلى الإطلاق

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

1. استكشاف العملية: نستخرج كيف يسير العمل اليوم ومن يشارك فيه وأين يتعثر، عبر الحديث مع أعضاء الفريق المعنيين.
2. تحليل الاحتياج والنطاق: نجمع أدوار المستخدمين والشاشات وقواعد العمل والأنظمة التي سيُربط بها في نطاق مكتوب.
3. التدفقات والنموذج الأولي: نرسم الشاشات الرئيسية والانتقالات ونجرّب العملية على النموذج الأولي مع المستخدمين.
4. قرار البنية والتقنية: نحدد نموذج البيانات وبنية الاستضافة والتقنيات المستخدمة بحسب احتياج المشروع.
5. التطوير المرحلي: نطوّر التطبيق وحدات، ونراجع معكم النسخة العاملة في نهاية كل مرحلة.
6. الاختبار: نختبر قواعد العمل والصلاحيات والسلوك في المتصفحات المختلفة قبل الإطلاق.
7. الإطلاق والانتقال: ننقل البيانات الحالية إلى النظام الجديد ونخطط للانتقال من النظام القديم إلى الجديد.

ماذا نناقش في تحليل الاحتياج؟

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

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

تقسيم النطاق إلى مراحل

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

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

ماذا ننظر فيه في مرحلة النموذج الأولي؟

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

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

قرارات البنية والتقنية في تطبيقات الويب المخصصة

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

يُختار التقنية بحسب المشروع

لا نطبّق التقنية نفسها على كل مشروع. فللواجهة الخلفية يمكن النظر في خيارات مثل Laravel أو Node.js أو Django أو .NET؛ وللواجهة الأمامية مكتبات مثل React أو Vue؛ وفي جانب البيانات قواعد بيانات مثل PostgreSQL أو MySQL. ويحدد الاختيار احتياجات التطبيق وأنظمتكم الحالية ومن سيطوّر التطبيق مستقبلًا.

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

أدوار المستخدمين ونموذج الصلاحيات

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

ماذا تعني البنية القابلة للتوسع؟

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

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

الاستضافة والبيئات

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

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

الربط بالأنظمة الحالية

نادرًا ما تعمل تطبيقات الويب المخصصة منفردة. فتبادل البيانات مع برنامج المحاسبة أو ERP أو CRM أو مزوّد الدفع أو شركة الشحن جزء من معظم المشاريع. ونوضّح في مرحلة النطاق كيف ستُقام هذه الروابط وأيّ نظام سيكون المصدر الأصلي لأي بيانات؛ وشرحنا التفاصيل في صفحة تكامل واجهات API والأنظمة.

الأمان والسرعة وسهولة الاستخدام

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

الأمان

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

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

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

السرعة

الشاشة التي تُفتح ببطء تتحول إلى هدر كبير للوقت في تطبيق عمل يُستخدم عشرات المرات يوميًا. نقيس أثناء التطوير أزمنة تحميل الصفحات وطريقة عرض الجداول الكبيرة وأداء الاستعلامات الكثيرة الاستخدام. وتُعدّ معايير Core Web Vitals الموصوفة في موارد Google على web.dev نقطة انطلاق جيدة لتقييم السرعة التي يشعر بها المستخدم.

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

سهولة الاستخدام

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

الإطلاق ونقل البيانات وما بعده

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

وهذه أمور ينبغي الانتباه إليها في فترة الانتقال:

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

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

تسليم التطبيق إلى فريقكم

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

النطاق والتحضير في مشاريع تطبيقات الويب المخصصة

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

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

ما ينبغي تحضيره

إذا جئتم إلى اجتماع تطوير تطبيقات الويب بالمعلومات التالية فيمكننا إجراء تحليل الاحتياج بكفاءة أكبر بكثير:

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

أخطاء شائعة

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

الأسئلة الشائعة

ما الفرق بين تطبيقات الويب المخصصة والبرمجيات الجاهزة؟

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

كم يستغرق تطوير تطبيقات الويب؟

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

هل يعمل تطبيق الويب على الهاتف أيضًا؟

نعم. فحين تُصمَّم الشاشات لتتوافق مع أحجام الهاتف واللوح يُفتح التطبيق على كل جهاز من المتصفح. وإذا لزم تطبيق يُنزَّل من المتجر فيُقيَّم خيار تطبيق الجوال بشكل منفصل.

هل يمكننا لاحقًا بيع التطبيق لشركات أخرى أيضًا؟

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

هل يمكن نقل بيانات Excel الحالية إلى النظام الجديد؟

يمكن نقلها. تُنظَّف البيانات أولًا وتُطابَق مع البنية الجديدة، ثم تُفحص عبر نقل تجريبي.

هل تطبيقات الويب المخصصة آمنة؟

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

لنفحص عمليات عملكم معًا

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