كيف تستلم مشروع تطوير برمجيات وما الذي يُسلَّم للعميل

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

ما هو الاستلام ولماذا يُخطَّط له مبكرًا

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

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

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

ما الذي يحصل عليه العميل

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

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

وتُحدَّد شروط التسليم، أي ما الذي يُسلَّم ومتى وبأي شكل، في العقد قبل بدء العمل. وبعد ذلك يأتي الدعم والتطوير وفق ما يُتفق عليه.

ما الذي يُسلَّم ولماذا

كل بند من بنود التسليم يعالج خطرًا محددًا. ويساعدك الجدول التالي على التأكد من عدم نسيان شيء:

تسليم الشيفرة المصدرية وحقوقها

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

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

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

ومن الأنسب استلام الشيفرة في مستودع يحفظ سجل التغييرات، لا في ملف مضغوط. فالسجل يوضح ما الذي تغيّر ولماذا، ويساعد الفريق التالي.

الصلاحيات والأسرار: تُحفظ خارج الشيفرة

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

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

ما الذي يجب فحصه في الصلاحيات

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

فحوص ما قبل الإصدار: البوابة الحمراء تعني لا إصدار

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

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

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

الاستلام على أجزاء بدل تسليم واحد في النهاية

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

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

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

قائمة التحقق لاستلام مشروع البرمجيات

يمكنك اعتماد القائمة التالية أساسًا وإكمالها بما يناسب منتجك:

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

الدعم بعد الإطلاق

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

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

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

اختبار قبول المستخدم (UAT): من يتحقق وكيف

اختبار قبول المستخدم (UAT، user acceptance testing) هو فحص المنتج بعيون من سيعملون به. يختبر فريق التطوير الكود والسيناريوهات قبل النشر، أما UAT فيجيب عن سؤال آخر: هل يحل المنتج مشكلة العميل في العمل الفعلي؟

ولكي يؤتي هذا الفحص ثماره يُحضَّر له مسبقًا:

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

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

الملاحظات ومحضر القبول وإغلاق المرحلة

بعد الفحص تبقى قائمة ملاحظات. ولكي لا يتحول القبول إلى دورة تعديلات لا تنتهي، تُصنَّف الملاحظات:

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

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

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