سؤال «كم يستغرق التطبيق؟» يصلنا كل أسبوع تقريبا، والإجابة المعتادة في أغلب المقالات هي «من ثلاثة إلى ستة أشهر» ثم تنتهي عند هذا الحد. المشكلة أن هذه الجملة لا تنفع صاحب عيادة يريد فتح الحجز الإلكتروني قبل موسم بعينه، ولا صاحب متجر يريد تطبيقا جاهزا قبل بداية العام الدراسي. لذلك سنضع هنا الحساب الأسبوعي الصريح لثلاثة أحجام حقيقية من التطبيقات، ثم ندخل في الجزء الذي يؤخر الإطلاق فعليا: الحسابات والنماذج والصفحات القانونية وقواعد المراجعة التي تشترطها آبل وجوجل قبل أن تسمحا لأي شخص بتحميل تطبيقك.
الإجابة القصيرة، بالأسابيع
هناك ثلاث مدد تتكرر في مشاريعنا بشكل يكاد يكون ثابتا. التطبيق الصغير، أي من خمس إلى ثماني شاشات مع تسجيل دخول واحد وبلا مدفوعات، ينجز عادة في خمسة إلى ثمانية أسابيع. وتطبيق الأعمال القياسي، الذي فيه حسابات للمستخدمين ومدفوعات وإشعارات ولوحة تحكم إدارية، يحتاج من اثني عشر إلى ستة عشر أسبوعا. أما المنصة متعددة الأدوار، بتتبع مباشر ومحادثة داخل التطبيق وربط بأنظمة خارجية، فمداها الواقعي من ستة إلى تسعة أشهر.
والنقطة التي نحرص على قولها من البداية أن هذه المدة يحددها حجم ما بداخل التطبيق، لا مقدار اجتهاد الفريق ولا عدد ساعات العمل، ولهذا فإن الطريقة الوحيدة الحقيقية لتقريب الموعد هي تقليص ما بداخل التطبيق نفسه. يمكننا أن نضيف مبرمجا ثالثا إلى مهمة يؤديها اثنان، لكن ذلك نادرا ما يقصر المدة، لأن الشاشات مترابطة والوقت الذي يوفره القادم الجديد يذهب في شرح ما بني قبله.
ومن واقع ما نراه، أغلب من يأتوننا واصفين «تطبيقا بسيطا» يصفون في الحقيقة الفئة الوسطى، وذلك لأن الحسابات والمدفوعات والإشعارات ثلاثة أعمال منفصلة تماما، ولكل منها شاشاته وقواعده وحالات فشله التي يجب التعامل معها قبل أن يراها المستخدم.
تفترض هذه المدد أيضا أن القرارات تصل في موعدها، وهو الافتراض الذي يسقط أكثر من أي افتراض آخر في مشاريع البرمجيات، وسنبين بعد قليل كم يكلف سقوطه بالأيام حتى تصبح المسألة رقما لا شكوى.
ما الذي يجعل التطبيق صغيرا أو قياسيا أو كبيرا
لا تحتاج إلى خلفية تقنية لتصنف فكرتك، بل إلى ثلاث عمليات عد بسيطة: عد الشاشات التي سيراها المستخدم، وعد أنواع المستخدمين الذين يسجلون الدخول بصلاحيات مختلفة، وعد الأنظمة الخارجية التي يجب أن يتصل بها التطبيق مثل بوابة دفع أو شركة شحن أو نظام محاسبة قائم عندك بالفعل.
خذ مثالا واقعيا نراه كثيرا: تطبيق حجز لعيادة، فيه واجهة للمريض يبحث ويحجز ويدفع، وتقويم للطبيب يعرض مواعيده ويسمح بتعديلها، ورسائل تذكير قبل الموعد، ودفع إلكتروني. هذا التطبيق عند التفصيل يقع بين ثماني عشرة واثنتين وعشرين شاشة، وفيه نوعان من المستخدمين، أي أنه تطبيق قياسي وليس صغيرا مهما بدا بسيطا في الوصف. صاحب العيادة يراه «شاشة حجز»، ونحن نراه شاشة بحث ونتائج وتفاصيل طبيب واختيار موعد ودفع وتأكيد وإلغاء وإعادة جدولة وسجل زيارات، ولكل واحدة منها حالتها حين ينقطع الاتصال أو يفشل الدفع أو يتأخر الطبيب.
وهناك جزء يغفله كثيرون عند حساب المدة: لوحة التحكم الإدارية التي يدير بها موظفوك المحتوى والمواعيد والأسعار هي منتج ثان مختبئ داخل الأول، وهي تضيف عادة أسبوعين إلى ثلاثة أسابيع لأنها تحتاج شاشاتها وصلاحياتها وتقاريرها. لذلك حين نتحدث عن تطوير تطبيقات الجوال فنحن نعني المنظومة كاملة: التطبيق على الهاتف، والخادم الذي يغذيه بالبيانات، ولوحة الإدارة التي تشغله يوميا.
مراحل البناء الخمس، وما تستهلكه كل مرحلة من وقت
المشروع القياسي الذي يستغرق أربعة عشر أسبوعا ينقسم عمليا إلى خمس مراحل: أسبوعان لدراسة المتطلبات وكتابة وثيقة المواصفات، وثلاثة أسابيع لتصميم الواجهات، وستة أسابيع للبناء البرمجي، وأسبوعان للاختبار وإصلاح الأخطاء، وأسبوع أخير لتجهيز صفحة المتجر والمراجعة.
ما يحدث في مرحلة الدراسة تحديدا هو أننا نكتب كل شاشة باسمها، وكل قاعدة عمل بجملة صريحة يفهمها صاحب المشروع قبل المبرمج: ماذا يحدث إذا ألغى العميل قبل ساعة من الموعد؟ من يملك تعديل السعر؟ هل يستطيع مستخدم أن يحجز نيابة عن غيره؟ الهدف من هذا التعب المبكر أن لا يخترع أحد قرارا في الأسبوع التاسع، لأن القرار المرتجل في منتصف البناء يكلف أضعاف ما يكلفه القرار المكتوب في الأسبوع الأول، وفي Linkysoft نكتب هذه الوثيقة قبل أن يفتح أي مبرمج محرره.
ولهذا السبب نفسه نصر على إنهاء التصميم قبل بدء البرمجة، فتعديل رسم على الشاشة عمل دقائق ومناقشة هادئة، بينما إعادة بناء شاشة بعد برمجتها وربطها بالخادم تكلف نحو ثلاثة أضعاف تكلفة تعديل الرسم، لأنها تمس البرمجة والاختبار والشاشات المجاورة في وقت واحد.
أين تذهب الساعات فعلا، ولماذا البرمجة أقل من نصف العمل
حين نفكك جهد مشروع قياسي نجد التوزيع التالي: نحو خمسة وأربعين في المئة برمجة، وثمانية عشر في المئة اختبارا وإصلاحا، وخمسة عشر في المئة تصميما، واثني عشر في المئة ربطا بالأنظمة الخارجية مثل بوابة الدفع أو شركة التوصيل، وعشرة في المئة للامتثال لشروط المتاجر وأوراق الرفع. بعبارة أوضح، كتابة الكود التي يتخيلها الناس هي المشروع كله لا تصل إلى نصفه.
والاختبار بلغة بسيطة يعني أن التطبيق نفسه يجب أن يعمل على هاتف أندرويد قديم بشاشة مشروخة وذاكرة شبه ممتلئة، وعلى أحدث آيفون، وبينهما عشرات التركيبات من أحجام الشاشات وإصدارات النظام وسرعات الإنترنت. نحن لا نجرب جهازا أو جهازين ثم نعلن النجاح، بل نمر على مجموعة أجهزة تمثل ما يحمله عملاؤك في جيوبهم فعلا.
وأكثر ما نحذر منه هنا هو الاقتصاد الكاذب، أي حذف أسبوعي الاختبار لكسب أسبوعين في الموعد. الأعطال التي تظهر يوم الإطلاق تكلفك تقييمات منخفضة تبقى في المتجر شهورا، ومكالمات دعم، وطلبات استرداد، وكل ذلك أغلى بكثير من الأسبوعين اللذين ظننت أنك وفرتهما.
ما تشترطه آبل وجوجل قبل أن تنشرا أي شيء
قبل الحديث عن البرمجة أصلا، هناك حسابان يجب فتحهما: عضوية برنامج المطورين لدى آبل بتسعة وتسعين دولارا أمريكيا في السنة، وحساب Google Play Console برسم تسجيل واحد قدره خمسة وعشرون دولارا يدفع مرة واحدة فقط. والقاعدة التي نكررها على كل عميل هي أن يفتح الحسابين باسم الشركة لا باسم موظف بصفته الشخصية، لأن نقل تطبيق منشور من حساب شخصي إلى حساب شركة لاحقا عملية مؤلمة وقد تعني البدء من الصفر.
حساب الشركة يحتاج رقم هوية تجارية يعرف باسم D-U-N-S، مع تدقيق في أوراق السجل التجاري وبيانات التواصل، وهذا التحقق يستغرق عادة من ثلاثة إلى أربعة عشر يوما. والخبر الجيد أنه لا علاقة له بالبرمجة إطلاقا، أي يمكن البدء فيه في اليوم الأول من المشروع، وهذه الخطوة وحدها توفر أسبوعين على من ينتظر حتى اقتراب موعد الرفع.
ثم تأتي الأوراق التي يصر عليها المتجران معا: سياسة خصوصية منشورة فعلا على موقعك برابط يعمل، واستبيان للبيانات والخصوصية يجب أن يطابق ما يجمعه التطبيق حقا، وتصنيف عمري، وجهة اتصال للدعم يستطيع المستخدم مراسلتها ويأتيه رد منها. والاستبيان تحديدا ليس إجراء شكليا، لأن الإجابة عليه بلا مراجعة حقيقية لما يخزنه التطبيق من أرقام هواتف ومواقع وصور سبب متكرر للرفض، ولذلك نراجعه مع فريق الأمن السيبراني بندا ببند مقابل ما يخزنه التطبيق على أرض الواقع.
وهناك قواعد توقع كثيرين لأنها غير معروفة: إن كان المستخدم يستطيع إنشاء حساب داخل التطبيق، فالمتجران يطالبان بوجود طريقة واضحة داخل التطبيق نفسه لحذف هذا الحساب. وإن كنت تتيح تسجيل الدخول عبر جوجل أو فيسبوك، فغالبا سيطلب منك توفير تسجيل الدخول عبر آبل أيضا. أما في السوق الأوروبية فهناك اشتراط بالإفصاح عن بيانات التاجر ونشرها، ومن دونه لا يرفض التطبيق بإشعار واضح فحسب، بل يختفي ببساطة من متاجر الدول الأوروبية وكأنه غير موجود.
صفحة التطبيق في المتجر، وهي عمل لا يحسب له أحد حسابا
قبل الرفع تحتاج مجموعة أصول محددة لا يقبل المتجر غيرها: أيقونة مربعة بمقاس 1024 بكسل، ولقطات شاشة لكل مقاس هاتف ولوح مطلوب بحد أقصى عشر لقطات لكل مقاس، وصورة مميزة بمقاس 1024 في 500 بكسل لمتجر جوجل، ووصف قصير في حدود ثمانين حرفا، ووصف طويل يصل إلى أربعة آلاف حرف، إضافة إلى سياسة الخصوصية المستضافة على موقعك أنت لا على أي موقع آخر.
كتابة هذا كله وتصويره بشكل لائق يستغرق من ثلاثة إلى خمسة أيام عمل، وهو ليس عملا تقنيا بل عمل تسويقي، وكلماتك أنت هي التي تبيع التطبيق للزائر الذي يقارن بينك وبين ثلاثة تطبيقات أخرى في ثلاثين ثانية، ولذلك لا يصح تركه ليوم الجمعة الأخير قبل الرفع.
وهناك تفصيلة صغيرة تعطل مشاريع كاملة: الحساب التجريبي للمراجع. إن كان تطبيقك يتطلب تسجيل دخول، فعليك تسليم آبل وجوجل اسم مستخدم وكلمة مرور يعملان فعلا وقت المراجعة، لأن المراجع الذي يقف أمام شاشة دخول لا يستطيع تجاوزها سيرفض التطبيق مباشرة، وهذا من أكثر أسباب الرفض شيوعا وأسهلها تفاديا على الإطلاق.
والخبر المريح أن نصوص المتجر وصوره قابلة للتعديل في أي وقت بعد النشر، فصفحة إطلاق جيدة تكفي تماما، ولا داعي لتأجيل الموعد بحثا عن صفحة مثالية لن يلاحظ أحد كمالها.
كم تستغرق المراجعة، ولماذا ترفض التطبيقات
عمليا، أغلب طلبات المراجعة لدى آبل تعود خلال أربع وعشرين إلى ثمان وأربعين ساعة، لكن التطبيق الجديد كليا على حساب جديد كليا يأخذ في الغالب من يومين إلى خمسة أيام لأنه يمر بفحص أدق. وفي جوجل بلاي قد يستغرق أول إصدار من حساب جديد ما يصل إلى سبعة أيام، بينما تمر التحديثات اللاحقة عادة خلال ساعات.
وهناك قاعدة تفاجئ الجميع وتستحق أن تعرفها اليوم لا في الأسبوع الأخير: الحساب الشخصي الجديد في جوجل بلاي مطالب عادة بتشغيل اختبار مغلق مع اثني عشر مختبرا على الأقل مشتركين بشكل متصل لمدة أربعة عشر يوما قبل السماح بالنشر العلني، وهذان أسبوعان كاملان لا يحتويهما أي جدول بناء ولا تعوضهما سرعة الفريق، وهو سبب إضافي لفتح الحساب باسم الشركة وفتحه مبكرا.
ومن واقع تجربتنا، نحو طلب واحد من كل ثلاثة طلبات أولى يعود ومعه ملاحظة واحدة على الأقل، وهذا أمر عادي وليس كارثة، ودورة الإصلاح وإعادة الإرسال تستغرق عادة من يومين إلى خمسة أيام. أما الملاحظات المتكررة فهي محدودة ومعروفة: توقف التطبيق فجأة على جهاز المراجع، أو حساب تجريبي مفقود أو منتهي الصلاحية، أو إجابة في استبيان الخصوصية لا تطابق سلوك التطبيق، أو غياب وسيلة لحذف الحساب من داخل التطبيق، أو تحصيل ثمن محتوى رقمي خارج نظام الدفع الخاص بالمتجر.
أكثر التأخيرات التي نراها، وما يكلفه كل منها
أول الأسباب وأثقلها هو اعتماد الحساب البنكي أو بوابة الدفع، وهو يضيف نحو أربعة عشر يوما لأنه بيد جهة خارجية لا يملك أحد فينا تسريعها. يليه إضافة متطلبات جديدة في منتصف البناء بنحو اثني عشر يوما، ثم انتظار صور العميل ونصوصه بنحو عشرة أيام، ثم التحقق من هوية حساب المطور بنحو تسعة أيام، وأخيرا رفض واحد من المتجر وإعادة الإرسال بنحو أربعة أيام.
ولكي تصل الفكرة كاملة، لنحسبها بصوت مرتفع: فريق من ثلاثة أشخاص يتوقف أسبوعا واحدا في انتظار إجابة يعني خمسة عشر يوم عمل مدفوعة الأجر أنتجت لا شيء. هذا هو السبب الحقيقي في أن سؤالا بلا إجابة قد يكون أغلى بند في المشروع كله، وفي أن تعيين شخص واحد يملك قرارا نهائيا خلال يوم أوفر عليك من أي خصم تحصل عليه في التفاوض.
ثم يأتي الأثر التراكمي للإضافات الصغيرة، وهو أخطرها لأنه لا يظهر إلا في النهاية. كل «ميزة سريعة» تضاف أثناء البناء تكلف في المتوسط من يوم ونصف إلى ثلاثة أيام عمل بعد حساب التصميم والبرمجة والاختبار وإعادة فحص الشاشات المحيطة بها، وهي دائما أكثر من شاشة واحدة. خمس إضافات سريعة إذن تساوي أسبوعين انسحبا من الجدول بهدوء دون أن يلاحظهما أحد حتى موعد التسليم.
قاعدة برمجية واحدة أم اثنتان، وأثر ذلك على موعدك
البناء متعدد المنصات يعني بلغة بسيطة كتابة مجموعة واحدة من الكود تنتج تطبيقين، واحدا للآيفون وآخر للأندرويد، وهو يوفر عادة من خمسة وعشرين إلى خمسة وثلاثين في المئة من أسابيع البناء مقارنة بكتابة تطبيقين منفصلين تماما، وهذا فرق يقاس بالأسابيع لا بالأيام في المشاريع المتوسطة.
ويستحق البناء الأصلي لكل نظام على حدة وقته الإضافي في حالات محددة: معالجة ثقيلة للكاميرا أو الفيديو، أو تتبع موقع مستمر في الخلفية، أو استخدام عميق لعتاد الجهاز، أو لعبة. خارج هذه الحالات، ولأغلب تطبيقات الحجز والطلبات والعضويات والتوصيل والتطبيقات الداخلية للشركات، يكون البناء متعدد المنصات هو الجواب الصحيح، وفي Linkysoft نقولها كما هي بدل بيع الطريق الأطول لمجرد أن فاتورته أعلى.
ولاحظ أمرا مهما قبل أن تبني قرارك على التقنية وحدها: كل ما ذكرناه من متطلبات المتاجر لا يتغير بتغير التقنية. الحسابات والوثائق ولقطات الشاشة ومدة المراجعة واحدة في الحالتين، أي أن اختيار التقنية يقصر أسابيع البناء ولا يقصر يوما واحدا من أعمال الامتثال.
متى يكون الإطلاق الأصغر هو القرار الأصوب
أحيانا تكون نصيحتنا ألا تبني تطبيقا الآن، ونقولها حتى لو كانت ضد مصلحتنا القريبة. إذا كان دور المنتج الأساسي عرض معلومات واستقبال حجز أو طلب، فإن موقعا سريعا مهيأ للهاتف يصل إلى كل جهاز خلال أيام لا أشهر، ولا يحتاج موافقة متجر أصلا، ولا يطالب الزائر بتحميل شيء قبل أن يتعامل معك. تجد تفاصيل هذا المسار في صفحة تصميم وتطوير المواقع.
وإن كان التطبيق ضروريا فعلا، فالخيار العملي هو تقليص الإصدار الأول: بدل اثنتين وعشرين شاشة تطلق تسع شاشات في سبعة أسابيع بدل خمسة عشر، ثم تضيف الباقي بعد أن يخبرك المستخدمون الحقيقيون بما يستعملونه فعلا. الفائدة هنا ليست توفير المال فحسب، بل أنك تبدأ في جمع سلوك حقيقي بدل الدفع مقابل ميزات بنيت على التخمين، وقد رأينا مرارا أن جزءا كبيرا من قائمة الميزات الأولى لا يلمسه أحد بعد الإطلاق. يمكنك الاطلاع على أمثلة من هذا الأسلوب في دراسات الحالة.
ما يمكنك البدء فيه اليوم لحماية موعد إطلاقك
هناك قائمة قصيرة ينجزها العميل بالتوازي مع عملنا، وهي وحدها تحمي أسابيع من الجدول. افتح حسابي المتجرين باسم الشركة من الآن، وانشر على موقعك صفحة سياسة خصوصية وصفحة دعم ببريد يعمل ويقرأه أحد، ثم عين شخصا واحدا يملك اتخاذ قرار نهائي خلال يوم واحد لا خلال اجتماع أسبوعي.
ثم اجمع المحتوى مبكرا: صورا حقيقية لمنتجاتك أو مقر عملك، ووصفا حقيقيا للخدمات، والصياغة الدقيقة للأسعار والشروط وسياسة الإلغاء. المحتوى المؤقت يبدو حلا سريعا في حينه، لكنه يعود دائما في صورة تعديلات متأخرة في الأسبوع الأخير حين يكون كل يوم غاليا.
والأهم من ذلك كله: ابدأ أوراق مزود الدفع والبنك في الأسبوع الأول، لأن الاعتماد خارج سيطرة الجميع ويستغرق عادة من أسبوع إلى ثلاثة أسابيع. ورؤية مشروع مكتمل يقف عند الإطلاق بسبب بوابة دفع لم تعتمد بعد مشهد نراه كثيرا، وهو مؤلم لأن تفاديه كان مجانيا تماما.
بعد الإطلاق: التسعون يوما الأولى والمواعيد السنوية
توقع من تحديثين إلى أربعة تحديثات صغيرة في الشهر الأول، واعتبرها علامة صحة لا علامة عطب، لأن المستخدمين الحقيقيين يجدون دائما ما لا يجده أي فريق اختبار: هاتف بإعدادات غريبة، أو شبكة بطيئة في منطقة بعينها، أو طريقة استخدام لم تخطر لأحد على بال.
ثم هناك الإيقاع السنوي الذي يجب أن يدخل ميزانيتك من اليوم الأول: أنظمة الهواتف الجديدة تصدر كل خريف، ويرفع المتجران كل عام الحد الأدنى للإصدار الذي يجب أن يبنى التطبيق عليه. التطبيق الذي يترك سنة كاملة بلا تحديث قد يصل إلى نقطة يتعذر فيها تحديثه أصلا دون إعادة بناء جزء منه، وهي فاتورة كان يمكن تفاديها بتحديث صغير كل بضعة أشهر.
والقاعدة التقريبية التي نعطيها لعملائنا هي تخصيص ما بين خمسة عشر وعشرين في المئة من تكلفة البناء سنويا للصيانة والاستضافة ورسوم المتاجر والتحسينات الصغيرة. وإن كانت لديك فكرة محددة وتريد لها جدولا واقعيا بالأسابيع لا بالوعود، يسعد فريق Linkysoft أن يجلس معك ويحسبها بندا ببند عبر صفحة التواصل.
