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