كم يستغرق بناء تطبيق؟ أين يذهب الوقت فعلاً

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

هذا هو المكان الذي يذهب إليه الوقت في مشروع تطبيق، مرحلة مرحلة، وما الذي يطيل كل واحدة.

1. تحديد ما سيُبنى

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

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

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

2. التصميم

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

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

3. البناء

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

ما الذي يطيلها:

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

4. الاختبار

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

ما الذي يطيلها: تنوّع الأجهزة. نظام Android تحديداً يعمل على مئات المقاسات والإصدارات. تحديد الأجهزة التي ستدعمها فعلاً منذ البداية يُبقي هذه المرحلة محدودة.

5. الرفع على المتاجر والإطلاق

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

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

التأخيرات التي بيدك

معظم تأخيرات مشاريع التطبيقات ليست مشكلات هندسية. إنها:

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

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

سؤال أفضل من "كم سيستغرق؟"

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