تكلفة تطبيق موبايل: لماذا تحددها الشاشات لا البرمجة

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

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

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

لماذا يخرج التطبيق أغلى من المتوقع في معظم المشاريع

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

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

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

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

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

الشاشة هي وحدة القياس الحقيقية في تكلفة تطبيق موبايل

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

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

أنواع الشاشات من حيث الجهد

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

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

مثال تقريبي: تطبيق طلبات لمطعم

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

الحالات الخفية داخل كل شاشة

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

التغيير بعد الموافقة على التصميم: البند الذي يضاعف الجهد

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

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

لماذا يحدث التغيير أصلا

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

كيف تقلل التغيير دون أن تفقد المرونة

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

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

الربط مع الأنظمة الأخرى: الوقت الذي لا يظهر في التصميم

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

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

أسئلة يجب أن تجيب عنها قبل البدء

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

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

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

الاختبار على أجهزة كثيرة: بند مستقل وليس تفصيلا

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

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

ماذا يعني هذا لميزانيتك

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

ماذا يحدث بعد النشر في المتاجر

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

لوحة التحكم: الجزء الذي ينساه الجميع حتى اللحظة الأخيرة

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

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

لا تترك لوحة التحكم للنهاية

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

التقارير: الشاشات التي تحتاجها بعد شهر من الإطلاق

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

مقارنة عملية: ما الذي يرفع التكلفة وما الذي لا يرفعها

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

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

كيف تحدد شاشات تطبيقك قبل أن تطلب تقديرا للتكلفة

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

ابدأ بالرحلة لا بالشاشات

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

اكتب رحلة لكل نوع مستخدم

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

حدد ما هو ضروري وما هو إضافي

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

ارسم الشاشات بشكل تقريبي

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

قائمة مراجعة قبل بدء تطوير التطبيق

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

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

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

النسخة الأولى الصغيرة: كيف تبدأ بأقل عدد من الشاشات

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

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

كيف تختار شاشات النسخة الأولى

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

ما الذي تخسره إذا بدأت كبيرا

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

متى تضيف الشاشات المؤجلة

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

الخلاصة: الشاشات المحددة من البداية هي أفضل توفير

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

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

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