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