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