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