تطوير تطبيقات الجوال: فريق يبني ويواصل، لا مشروع ينتهي عند النشر

تطبيق الجوال برنامج يعمل على هواتف iPhone وأجهزة Android، يربط بين مستخدمك وخدمتك أو منتجك مباشرة في جيبه. لكن العمل الحقيقي ليس مجرد كتابة الكود الذي يظهر على الشاشة؛ هذا الجزء الظاهر لا يتعدى ثلث القدرة المطلوبة. الجزء الأكبر مخفي: قاعدة بيانات تحفظ بيانات المستخدمين، خادم (API) ينقل المعلومات بأمان، نظام تسجيل دخول، بوابة دفع، إشعارات فورية، ولوحة تحكم تدير منها المحتوى والطلبات بنفسك.

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

• واجهة المستخدم (Front-end): الشاشات التي يراها العميل ويتفاعل معها، بتصميم عربي يدعم الاتجاه من اليمين لليسار.
• الخادم وواجهات البرمجة (Back-end / API): العقل الذي يخزّن البيانات ويتحقق من الصلاحيات ويتعامل مع الدفع والإشعارات.
• لوحة تحكم إدارية (Dashboard): تدير منها المستخدمين والمحتوى والطلبات والتقارير بنفسك.
• التكاملات الخارجية: بوابات دفع سعودية مثل مدى و Apple Pay، خرائط، رسائل SMS عبر مزوّد محلي، وربط مع أنظمتك الحالية.
• النشر وما بعده: رفع التطبيق على App Store و Google Play، ثم المراقبة والتحديثات ومتابعة سياسات المتاجر بشكل دائم.

لاحظ البند الأخير: النشر ليس خط النهاية بل نقطة البداية. الأعطال، وإصدارات النظام الجديدة، ومراجعات المتاجر، والميزة التالية عمل أسبوعي دائم. ولهذا وحدة التسليم في كادر ليست "تطبيقًا"، بل فريقًا هندسيًا مخصصًا يملك قدرة iOS و Android كاملة، تديره كادر من مركزنا الهندسي في عمّان، ويعمل على خارطة طريقك بـ Sprint أسبوعي، بتقدير مكتوب قبل كل مهمة وموافقتك قبل تجاوزه.

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

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

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

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

ولا يقل عن ذلك أهمية أن التطبيق يمنحك بياناتك أنت: من يستخدم خدمتك، متى، وأي ميزة يتجاهلها. هذه المعرفة تتيح قرارات مبنية على أرقام حقيقية، لكنها تعني أيضًا مسؤولية. وإن كان عملك خاضعًا لمتطلبات حماية بيانات محدّدة في جمع الموافقات وحفظ البيانات، فالضوابط التي يحدّدها مستشارك القانوني تُكتب في بيان العمل (SOW) ويبني الفريق عليها منذ اليوم الأول.

هذا أول قرار تقني حقيقي، وله أثر مباشر على الوقت والأداء وكلفة الصيانة لسنوات. التطوير الأصيل (Native) يعني كتابة تطبيق منفصل لكل منصة: Swift لـ iOS و Kotlin لـ Android، أي قاعدتَي كود وفريقين عمليًا. أما متعدّد المنصّات عبر Flutter فيعني كودًا واحدًا يعمل على iOS و Android معًا. لا يوجد خيار "أفضل" مطلق؛ يوجد خيار أنسب لحالتك. هذه هي المعايير التي يقرّر الفريق على أساسها معك:

• الوقت وحجم الفريق: Flutter غالبًا أسرع وأخفّ لأنك تبني مرة واحدة بدل مرتين، وهو مناسب جدًا لأول إصدار (MVP) ولفريق صغير مركّز.
• نوع التطبيق: تطبيقات الخدمات والمتاجر والحجوزات والمحتوى تعمل بكفاءة عالية على Flutter دون أي تنازل ملموس.
• الأداء الثقيل: إن كان التطبيق يعتمد على رسوميات ثلاثية الأبعاد أو معالجة كاميرا متقدمة أو ألعاب، يميل القرار نحو Native.
• ميزات الجهاز العميقة: بعض التكاملات الدقيقة جدًا مع نظام التشغيل تكون أنضج وأسهل في Native.
• الصيانة على المدى الطويل: كود Flutter واحد يعني تحديثات أرخص وفريقًا أصغر يكفي لإدارته أسبوعًا بأسبوع، وهذا وزنه الحقيقي يظهر بعد السنة الأولى لا قبلها.
• تجربة المستخدم: كلا الخيارين يصل اليوم لتجربة سلسة بمعايير عالية؛ الفرق صار في الحالات المتطرفة لا في الاستخدام اليومي.

يبدأ الفريق بسؤالك عن هدف التطبيق وخطتك للنمو، ثم يوصي بالخيار الذي يخدم منتجك لا الذي يسهّل عمله. أغلب مشاريع السوق السعودي اليوم تُخدَم بشكل ممتاز عبر Flutter، ويبقى Native للحالات التي تستحقه فعلًا. والقرار وأسبابه يُكتبان في SOW قبل أن يبدأ العمل، لا بعده، حتى لا يتحوّل إلى نقاش متأخّر.

لا صندوق مغلق حتى النهاية. الفريق يعمل بإيقاع أسبوعي ثابت تراه بعينك: Sprint أسبوعي ينتهي بـ demo على جهاز حقيقي لا على شريحة عرض، وتقدير مكتوب قبل أي مهمة، وموافقتك قبل تجاوزه، وتقرير أسبوعي بما أُنجز وما استُهلك وما التالي. الأولويات تبقى بيدك وتعيد ترتيبها في بداية كل Sprint.

أما محتوى العمل نفسه فيغطّي دورة المنتج كاملة، وتتكرّر هذه الأنشطة أسبوعيًا بدل أن تحدث مرة واحدة:

• تحديد الأولويات: ما المشكلة التي تُحلّ الآن، ومن المستخدم، وما الذي يدخل هذا الـ Sprint وما الذي يُؤجَّل.
• التصميم (UI/UX): رسم التجربة والشاشات بنموذج تفاعلي (Prototype) تجرّبه قبل كتابة الكود.
• التطوير: بناء الواجهة والخادم بالتوازي، مع نسخة تعمل في نهاية كل Sprint.
• الاختبار و QA: اختبار على أجهزة iPhone و Android حقيقية، والتحقق من الأداء والأمان ودعم العربية والاتجاه RTL.
• النشر: تجهيز حسابات App Store و Google Play، ورفع التطبيق، والتعامل مع متطلبات المراجعة لدى Apple و Google.
• ما بعد الإطلاق: مراقبة الأعطال والأداء، وتوافق إصدارات iOS و Android الجديدة، وتطوير الميزات بناءً على سلوك المستخدمين الحقيقي.

تقنيًا، يعتمد الفريق Flutter للتطبيقات متعددة المنصّات، و Swift/Kotlin عند الحاجة للأصيل، مع خوادم حديثة وقواعد بيانات موثوقة وبنية سحابية قابلة للتوسّع. يُبنى الدفع عبر بوابات تدعم مدى و Apple Pay، وتُصمَّم طبقة حماية البيانات وفق الضوابط المكتوبة في SOW منذ اليوم الأول لا كإضافة لاحقة.

ومن يقود كل هذا Tech PM من كادر يترجم أولوياتك إلى مهام ويحمي الإيقاع. المهندسون موظفون لدى كادر ويعملون تحت إشرافها من مركزنا الهندسي في عمّان، وأنت لا تدير أفرادًا ولا تتحمّل عبء التوظيف، بل تشتري تسليمًا مُدارًا ونتائج. حسابات App Store و Google Play تُنشأ باسم شركتك، ويعمل عليها الفريق بصلاحيات تمنحها أنت وتسحبها متى شئت، أما ملكية الكود وحقوق الملكية الفكرية فتُحدَّد في MSA و SOW ويُتفق عليها قبل بدء أي عمل.

بناء قسم جوال داخلي يعني توظيف مهندس iOS ومهندس Android ومهندس backend ومصمّم UI/UX و QA وقائد تقني، ثم الاحتفاظ بهم. السؤال العملي لأغلب الشركات ليس "من يبني لي التطبيق؟" ولا "من الأرخص؟"، بل "كيف أضمّ هذه القدرة إلى شركتي بلا عبء التوظيف؟". هذه المعايير تفصل بين فريق يمتدّ لشركتك وبين مورّد يبيعك وعدًا:

• من يوظّف المهندسين ومن يشرف عليهم؟ في كادر المهندسون موظفون لدى كادر ويعملون تحت إشرافها من مركزنا الهندسي في عمّان. أنت تشتري تسليمًا مُدارًا ونتائج، لا إدارة أفراد.
• ما الذي يحكم العلاقة كتابةً؟ اتفاقية إطارية (MSA) وبيان عمل (SOW) يُتفق عليهما قبل بدء العمل، وفيهما النطاق والصلاحيات وشروط الملكية الفكرية، بدل تقدير شفهي مفتوح يتوسّع لاحقًا.
• ما الإيقاع الأسبوعي؟ Sprint أسبوعي ينتهي بـ demo على جهاز حقيقي، وتقدير مكتوب قبل كل مهمة، وتقرير أسبوعي. الصندوق المغلق حتى التسليم أول علامة خطر.
• استمرارية التسليم: ماذا يحدث لو غادر مهندس؟ التوثيق ومراجعة الكود ومعرفة موزّعة داخل الفريق مسؤولية الجهة لا مسؤوليتك. من يعتمد على شخص واحد يبيعك مخاطرة لا قدرة.
• الحسابات والصلاحيات: حسابات App Store و Google Play تُنشأ باسم شركتك ويعمل عليها الفريق بصلاحيات تمنحها وتسحبها متى شئت.
• الخبرة بالسوق: دعم العربية و RTL، والتكامل مع بوابات الدفع المحلية، ومتطلبات حماية البيانات التي يحدّدها مستشارك ليست تفاصيل ثانوية، والفريق الذي يعمل بالعربية يوميًا يفرق هنا فعلًا.

بعد هذه المعايير يبقى سؤال واحد: أي نموذج فريق يناسب وضعك؟ إن كان لديك تطبيق حيّ يعمل ويحتاج صيانة وتعديلات متفرّقة بلا خارطة طريق مستمرة، فـ ساعات كادر (/services/hours) هي المناسبة. وإن كانت لديك خارطة طريق منتج تحتاج فريقًا كل أسبوع، فـ فرق كادر (/services/squads). وإن كنت تبني قسمًا هندسيًا طويل الأمد يغطّي الجوال والخادم والبيانات معًا، فـ مركز كادر للتطوير (/services/offshore).

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