كيف ينبغي تقسيم مراحل تطوير تطبيق أندرويد في عرض السعر — وكم يوماً لكل خطوة؟

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

النقطة الأكثر حساسية في تفصيل عرض الأندرويد هي تكامل الـ API وبنية قاعدة البيانات المحلية. إذا كان برنامج المحاسبة الحالي لديكم لا يملك REST API جاهز، فسيضيع من الـ 90 يوماً 30 يوماً لمجرد سحب البيانات. اسألوا الوكالة من البداية: من سيمنح صلاحيات قاعدة البيانات ومن سيوفر التوثيق البرمجي؟

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

بدأنا العام الماضي تطبيقاً مشابهاً لطلبات الميدان بميزانية 360.000 TL والتزام بـ 75 يوم عمل. استغرق التصميم 14 يوماً والبرمجة 40 يوماً. لكن اعتماد المتجر والاختبار التجريبي الداخلي تأخرا 20 يوماً. لولا أن التقسيم كان مكتوباً بالتفصيل لرموا سبب التأخير علينا.

الوكالة التي تقول 90 يوماً بدون تفاصيل قد تسند العمل لمطورين من الباطن. إذا كان الفريق عاجزاً عن وضع هيكل تفصيلي للعمل، فتمكنه من بيئة أندرويد مشكوك فيه. اسألوا كم مبرمج أندرويد خبير (senior) في الفريق واطلعوا على أعمال سابقة لهم منشورة فعلياً على Play Store.

اطلبوا المعالم التالية في العرض المعدل: 1) تسليم المخططات الهيكلية (Wireframes) ومخطط التدفق 2) اعتماد النموذج الأولي القابل للنقر للتصميم 3) أول نسخة ألفا مع اكتمال ربط الـ API 4) نسخة بيتا مغلقة للاختبار الميداني 5) الإطلاق الفعلي واعتماد المتجر.

نحنا عشان ما حسبنا حساب ربط الـ erp المشروع اتأخر 3 شهور. يعني الوكالة رمت الحق عالمحاسب والمحاسب رماه عالوكالة. اطلبوا ضروري يحضر مبرمج الـ erp الاجتماع قبل تقديم العرض.

ملاحظة: كتبت هذا بناءً على تجربتي الشخصية، قد لا ينطبق على الجميع.

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

عندنا نفس المشكلة. يجب فتح بيانات الوصول باسم المؤسسة، وليس بحسابات شخصية.

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

سؤالي قد يبدو مبتدئاً بعض الشيء، آسف على ذلك. كل من يستعجل في تطوير تطبيقات أندرويد يتعثر في نفس النقطة.

إذا كتبت النتيجة هنا، فستفيد الآخرين أيضاً.

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

أتمنى أن يفيدك هذا.

أنت محق. وضع عملية لطلبات التغيير لا يبطئ العمل، بل يسرّعه.

لا تترددوا في السؤال، فالسائل يدفع ثمناً أقل دائماً... دعني أتركها كملاحظة، قد تكون مفيدة.

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

إذا كان هناك من يفعلها بطريقة أخرى، فأنا فضولي لمعرفة ذلك.

صحيح.

عندنا نفس المشكلة.

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

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

مثبت بالتجربة.

دعني أوضح الجانب التقني قليلاً. النظام يستمر بعد التسليم؛ الصيانة بند منفصل.