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