عبدالله الكندي يجاوب: كيف تقيّم عرض سعر برمجة قبل ما توقّع؟

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

هل السعر الأرخص دائماً أسوأ؟

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

مين يملك الكود والحسابات بعد التسليم؟

هذا أهم سؤال في العرض كله، وأكثر سؤال ينتسى. لازم يكون مكتوب بوضوح:

• الكود المصدري يتسلّم لك كامل، ولك حق التعديل عليه أو نقله لمنفّذ ثاني.
• حساب المطوّر في App Store و Google Play باسمك أو باسم منشأتك، مو باسم المبرمج.
• الدومين والاستضافة وقاعدة البيانات مسجّلة عندك، أو على الأقل عندك صلاحية المالك.
• أي خدمة خارجية مدفوعة، مثل خدمة رسائل أو خرائط، يكون حسابها لك.
• مفاتيح توقيع التطبيق وكلمات مرور كل الخدمات تتسلّم لك في نهاية المشروع.

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

كيف المفروض يكون جدول الدفع؟

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

وش يصير لو تغيّرت المتطلبات في النص؟

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

وبعد التسليم؟

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

إشارات حمراء تستاهل توقف عندها

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

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

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