اختيار من يبني لك البرمجيات قرار أثره أكبر من اختيار ما تبنيه. نفس البريف يعطي أربعة أرقام مختلفة من أربعة مورّدين، وثلاثة منهم قد يسلّمونك شيئاً يعمل، وواحد يسلّمك شيئاً ستدفع ثمنه مرتين. هذا المقال عن كيفية التمييز بينهم قبل أن تدفع، لا بعد ستة أشهر.
أكتبه وأنا طرف في المعادلة، فاقرأه بهذا الاعتبار. أعمل مطوراً مستقلاً، وسأقول لك بوضوح في القسم المناسب متى أكون الخيار الخاطئ لمشروعك. وما سأكتبه مبني على ٤٢ مشروعاً سلّمتها، وعلى عدد معقول من الأنظمة التي أُعطيت لإنقاذها بعد أن بناها غيري، وعلى عملاء جاءوني بعد تجربة سيئة وشرحوا لي بالتفصيل ما حدث.
أربعة أنواع من المورّدين، ولماذا لا يوجد أفضلهم
السؤال الشائع أي النوع أفضل، والجواب الصحيح أن لكل نوع مشروعاً يناسبه. والخطأ ليس في اختيار نوع بل في اختيار نوع لا يناسب مشروعك.
الوكالة المحلية
الأغلى، وفيها ما تدفع مقابله فعلاً: فريق لا يتوقف إن مرض شخص، وإدارة مشروع رسمية، وشخص تستطيع الاجتماع به، وقدرة على استيفاء متطلبات شراء رسمية إن كنت تتعامل مع جهة كبيرة تطلب سجلاً تجارياً وضماناً وعقداً نموذجياً.
والمخاطرة الحقيقية فيها أن تدفع مقابل إدارة حساب لا هندسة. في بعض الوكالات، نسبة معتبرة من المبلغ تذهب إلى طبقة بين المطور وبينك، وقيمتها حقيقية في مشروع كبير بعدة فرق، ومعدومة في مشروع يكفيه مطور واحد خبير.
متى تكون الاختيار الصحيح: ميزانية كبيرة، أو موعد صلب يحتاج عدة أشخاص بالتوازي، أو مشتريات رسمية، أو كنت ستتعامل مع عدة أطراف داخلية تحتاج من ينسّق بينها.
الاستوديو الإقليمي
الوسط، وحيث يقع معظم العمل الجدي في المنطقة. فريق من ثلاثة إلى عشرين شخصاً، بتكلفة أقل من الوكالة وقدرة أوسع من الفرد.
والمخاطرة أن الجودة متفاوتة بشدة في هذه الفئة. استوديوان بنفس الحجم والسعر قد يكون أحدهما ممتازاً والآخر مصنعاً للقوالب. ولا توجد طريقة لمعرفة ذلك من الموقع أو من العرض، بل من فحص عمل حقيقي ومن الاتصال بعملاء سابقين، وسأفصّل كيف لاحقاً.
المطور المستقل الخبير
الوسط إلى المنخفض في التكلفة، والأعلى في التواصل المباشر. تتكلم مع من يكتب الكود بلا وسيط، فالقرار يُتخذ في دقائق لا في اجتماع، والشخص الذي فهم مشكلتك هو نفسه الذي يبنيها.
والمخاطرتان واضحتان: الطاقة الاستيعابية، لأنه لا يستطيع مضاعفة السرعة بإضافة أشخاص، وما يحدث إن اختفى. وسأشرح كيف تحمي نفسك من الثانية في قسم الملكية، وهي حماية ينبغي أن تطلبها من أي نوع مورّد لا من المستقل فقط.
متى يكون الاختيار الصحيح: مشروع واضح يسع رأساً واحداً. ومتى يكون الخطأ: مشروع يحتاج فعلاً أربعة أشخاص يعملون بالتوازي على موعد صلب. اسألني أي الاثنين مشروعك، واسأل أي مورّد السؤال نفسه.
منصات أقل عرض سعر
الأرخص، ومناسبة فعلاً لمهام صغيرة موصوفة بدقة ويمكن التخلي عنها: تعديل صفحة، أو تركيب قالب، أو إصلاح خطأ محدد. وهي اختيار سيئ لأي شيء ستملكه سنتين.
والسبب ليس أن المطورين هناك سيئون، فبعضهم ممتاز. السبب أن آلية الاختيار نفسها تدفع نحو أرخص عرض، وأرخص عرض يُفاز به بحذف أشياء لا تراها في العرض وتظهر في السنة الثانية.
ماذا يسعّر العرض المنخفض فعلاً
عرض بخمس تكلفة الآخرين ليس كرماً ولا عدم خبرة في الغالب. هو نطاق مختلف، والأجزاء المحذوفة متوقعة بدقة لأنني رأيتها تتكرر في كل نظام أُعطيت لإنقاذه.
- العربية ترجمة آلية، أو واجهة إنجليزية ملحق بها عربي يُدرك القارئ العربي فوراً أنه لاحق
- لوحة إدارة شكلية لا يستطيع فريقك العمل منها، فتعود إليه في كل تعديل
- بلا معالجة أخطاء، فأي حالة غير متوقعة تعطي شاشة بيضاء أو رسالة تقنية للعميل
- بلا صلاحيات حقيقية، فإخفاء الزر هو كل الحماية
- بلا اختبارات ولا توثيق، فأي تعديل لاحق مجازفة
- بلا نسخ احتياطية مجرَّبة
- بناء على قالب مشترى بترخيص باسم المطور لا باسمك
- بلا أي شيء بعد الإطلاق، فأول عطل في الأسبوع الثاني يصبح فاتورة
والتكلفة تظهر في السنة الثانية عندما تريد تعديلاً ولا يستطيع أحد تنفيذه بأمان. وأقول هذا بصفتي من سُلّم أنظمة كهذه: الإنقاذ غالباً أغلى من البناء الأصلي من شخص كفؤ، لأن المنقذ يحتاج فهم ما بُني ثم إعادة بناء أجزاء منه وهي مشغولة ببيانات حقيقية.
فإن كانت ميزانيتك صغيرة فالحركة الصحيحة مشروع أصغر مبني بشكل صحيح، لا مشروع كبير مبني بسوء. صفحة هبوط واحدة ممتازة أنفع من ثمان صفحات رديئة، ونظام يغطي عملية واحدة بإحكام أنفع من نظام يغطي خمساً بترقق.
ما يسعّره العرض المرتفع
العدل يقتضي الجهة الأخرى أيضاً، لأن السعر المرتفع ليس دليل جودة.
بعض ما تدفعه في العرض المرتفع حقيقي: خبرة تقلل المخاطرة، وتوثيق يمكّنك من تغيير المورّد، ومعالجة حالات لم تفكر فيها، وأشخاص متاحون عند الحاجة. وبعضه ليس حقيقياً: طبقة إدارية لا تحتاجها، ومكتب في موقع غالٍ، وعلاوة مخاطرة بسبب بريف ضعيف، ووقت بيع ومقترحات تُحمَّل على المشاريع التي تُربح.
والعلاوة الأخيرة تستحق وقفة لأنها أكبر مما يُتوقع. المورّد الذي يقدّم عشرة عروض ويربح ثلاثة يحمّل تكلفة العشرة على الثلاثة. ولا يمكنك منع هذا، لكن يمكنك تقليص علاوة المخاطرة بشيء واحد: بريف واضح. المورّد الذي لا يعرف ما يبنيه يسعّر النسخة السيئة من مشروعك لا النسخة المرجحة، وأنت تدفع هذا الفرق مقابل غموضك أنت.
كيف تفحص مورّداً قبل أن تدفع
هذه الفحوص لا تحتاج خبرة تقنية، وهي أدق من أي شهادة أو معرض أعمال.
اطلب نظاماً عاملاً وجرّبه بنفسك
لا صوراً ولا فيديو عرض ولا معرض أعمال. اطلب رابطاً وحساب دخول لشيء مُطلق ومستخدَم. ثم افعل الأشياء التي يفعلها مستخدم متعب: اترك حقلاً فارغاً واضغط إرسال، اكتب نصاً عربياً في حقل يتوقع إنجليزياً، اضغط الزر مرتين سريعاً، أغلق الصفحة في منتصف عملية وارجع إليها، افتح الموقع على جوالك بشبكة بيانات لا واي فاي.
النظام المبني جيداً يتصرف بشكل معقول في كل هذه الحالات. والمبني بسرعة ينكسر في ثانيتين، وتكون قد عرفت ما تحتاج معرفته بلا نقاش تقني.
انظر كيف يتعامل مع بريفك
أفضل إشارة واحدة عندي. المورّد الذي يقرأ بريفك ويرد بأسئلة، وبعضها أسئلة لم تفكر فيها، فكّر في مشروعك. والمورّد الذي يرد بعرض سعر فوري وقائمة ميزات منسوخة لم يقرأه.
واعتبر الأسئلة الصعبة علامة جيدة لا إزعاجاً. سؤال محرج في الأسبوع الأول أرخص بكثير من نفس السؤال بعد ثلاثة أشهر من البناء. والمورّد الذي يسألك عن الاستثناءات وعن من يوافق وعن ما يحدث عند الإلغاء هو من بنى أنظمة حقيقية قبلاً.
اسأله عن مشروع فشل
سؤال أحبه لأن جوابه يكشف أكثر من قائمة الأعمال كلها. كل من عمل سنوات عنده مشروع تعطّل أو تأخر أو انتهى بسوء. من يحكيه بتفصيل ويقول ما تعلّمه منه عمل فعلاً وفكّر في عمله. ومن يقول إن كل مشاريعه نجحت إما حديث جداً أو غير صادق، وكلاهما معلومة مفيدة.
تحدث مع عميل سابق لا مع شهادة مكتوبة
الشهادات على المواقع كلها إيجابية بطبيعتها ولا تحمل معلومة. اطلب رقم عميل سابق واتصل، واسأل سؤالين محددين: كيف كان التواصل عند وجود مشكلة؟ وهل انتهى المشروع في الوقت والسعر المتفق عليهما؟
والجواب على السؤال الأول أهم بكثير من الثاني، لأن المشاكل ستحدث في مشروعك أيضاً، والفرق بين مورّد جيد وسيئ ليس غياب المشاكل بل تصرفه عندها. واسأل سؤالاً ثالثاً إن استطعت: هل كنت ستتعامل معه مرة أخرى؟ التردد في الجواب معلومة.
اسأله عن شيء يجب أن يرفضه
فحص أستخدمه ويعمل دائماً. اطلب ميزة لا تحتاجها فعلاً، شيئاً كبيراً وبراقاً: ذكاء اصطناعي يكتب المحتوى، أو تطبيق جوال لمشروع لا يحتاجه، أو نظاماً يتحمل مليون مستخدم وعندك مئة.
المورّد الذي يقول لك إن هذا لا يستحق ميزانيتك ويشرح لماذا يعمل لمصلحتك. والذي يضيفه للعرض فوراً ويسعّره يعمل لمصلحته. والسؤال الأوضح من هذا: ما البند الذي تقترح حذفه من طلبي ولماذا؟ من يجيب عليه بجدية هو من ستحصل منه على أفضل نتيجة بميزانيتك.
اسأل من يكتب الكود
سؤال مشروع تماماً ويُحرج من يجب أن يُحرج. الوكالات التي تربح العمل بشخص خبير وتنفّذه بمبتدئ موجودة في كل سوق، وليس في ذلك عيب بحد ذاته إن كان المبتدئ يعمل تحت إشراف حقيقي. فاسأل: من يكتب الكود، وما خبرته، وهل سيبقى على المشروع في الشهر الثالث؟ وطلب أسماء في العقد ليس مبالغة في المشاريع الكبيرة.
كيف تقارن عروضاً تبدو غير قابلة للمقارنة
أكثر خطأ أراه في جانب المشتري: جمع ثلاثة عروض ومقارنة الأرقام. العروض الثلاثة لمشاريع مختلفة، والمقارنة بين أرقامها بلا معنى.
ابنِ الجدول بنفسك
اكتب جدولاً فيه صف لكل بند وعمود لكل مورّد، وعلامة أمام ما هو مشمول صراحة. والبنود التي أضعها دائماً:
- الأدوار وما يستطيع كل دور فعله
- لوحة الإدارة، ومن سيستخدمها، وهل جُرّبت معه
- النسخة العربية: من يكتبها، وهل البحث العربي مشمول
- التكاملات بالاسم، وهل تم التحقق من وجود واجهة برمجية لكل منها
- ترحيل بياناتك الحالية، وهل سيُجرّب قبل التسليم
- الصلاحيات وسجل من فعل ماذا
- التقارير بالاسم، وقابلية التصدير
- عدد مرات تعديل التصميم المشمولة
- من يكتب المحتوى ومن يوفّر الصور
- الاستضافة والنطاق والرسوم السنوية، ومن يدفعها
- مدة الدعم بعد الإطلاق، وتعريف العطل مقابل الطلب الجديد
- التدريب والتوثيق
- ملكية الكود، والحسابات باسم من
- الاستثناءات صريحة
الجدول يحوّل المقارنة من رقم إلى معلومة. وفي نصف الحالات التي فعلت فيها هذا مع عميل تبيّن أن العرض الأغلى هو الأرخص فعلاً لكل ما يحصل عليه، وفي النصف الآخر تبيّن أن العرض الغالي يبيع أشياء لا يحتاجها.
أرسل الجدول لكل مورّد
خطوة تستغرق دقائق وتغيّر النتيجة. أرسل الجدول نفسه للثلاثة واطلب من كل واحد تعبئته. من يعبّئه بصدق، بما يشمل كتابة "غير مشمول" أمام بنود، هو المورّد الذي ستعمل معه بارتياح. ومن يضع علامة أمام كل بند بلا تفصيل إما لم يقرأ أو يبيعك وعداً.
انتبه للعرض الذي يصل بسرعة
عرض يصل خلال ساعة من أول محادثة لم يُقدَّر بل خُمِّن، وسيُدافع عن التخمين لاحقاً بحذف أشياء. والتقدير الجدي يحتاج قراءة وأسئلة، وأحياناً مكالمة ثانية. وإن وصلك عرض فوري فاسأل على أي أساس حُسب، والجواب سيخبرك.
بند الاستثناءات: الفحص الأقوى
إن أخذت شيئاً واحداً من هذا المقال فليكن هذا. اطلب من كل مورّد أن يكتب في عرضه ما ليس مشمولاً.
المورّد الذي يكتب ما لن يفعله فكّر في مشروعك، لأن معرفة الحدود تستلزم فهم الكل. والمورّد الذي يكتب ما سيفعله فقط كتب كتيّباً دعائياً. وفوق ذلك، بند الاستثناءات هو الذي يمنع كل خلاف ستدخل فيه لاحقاً، لأن معظم الخلافات في المشاريع البرمجية ليست عن جودة ما سُلّم بل عن شيء افترض العميل أنه مشمول وافترض المورّد أنه ليس كذلك.
وأمثلة لاستثناءات مشروعة تماماً ويجب أن تُكتب: كتابة المحتوى، وتوفير الصور، وشراء الخطوط أو القوالب، والترجمة، وتسجيل بوابة الدفع، واستضافة السنة الأولى، والتدريب لأكثر من جلستين، وأي تكامل مع نظام لم يُفحص بعد. كل واحد من هذه قد يكون مشمولاً أو لا، والمهم أن تعرف أياً منهما.
الملكية: ما تطلبه قبل أن تدفع أول دفعة
هذا القسم يحميك من كل أنواع المورّدين، لا من السيئ منهم فقط. والموضوع يُحسم في البداية أو لا يُحسم أبداً.
الكود
تملكه أنت عند السداد الكامل، مكتوباً في العقد. والمستودع يعيش في حساب تتحكم فيه شركتك من اليوم الأول، والمورّد مدعو إليه لا العكس. هذا الترتيب لا يكلف شيئاً في البداية وهو شبه مستحيل الحصول عليه بعد خلاف.
التراخيص
اسأل صراحة: هل في هذا البناء قالب أو مكوّن تجاري، وباسم من ترخيصه، وهل ينتقل إليّ؟ القالب المشترى باسم المورّد يعني أنك تستخدم شيئاً لا تملكه، وقد تجد نفسك بلا حق في تحديثاته أو بلا حق في استخدامه إن انتهت العلاقة.
الحسابات
البند الأكثر إغفالاً والأكثر إيلاماً. مسجّل النطاق، والاستضافة، وبوابة الدفع، والتحليلات، وقوائم متاجر التطبيقات، وحساب البريد. كلها يجب أن تكون مسجّلة ببريد شركتك لا بريد المورّد، حتى عندما يكون المورّد هو من أنشأها.
استعادة نطاق مسجّل باسم متعاقد اختلفت معه عملية مؤلمة فعلاً، ورأيت منشأة تخسر أسابيع فيها وهي لا تستطيع تعديل موقعها ولا نقله. والوقاية سطر واحد في العقد وخمس دقائق عند كل تسجيل.
التسليم كمخرَج
اطلب في العقد، مرتبطاً بالدفعة الأخيرة: صلاحية المستودع في حسابك، وعملية نشر مكتوبة في ملف، وبيانات البيئة مسجّلة في مكان غير جهاز شخص واحد، وشرحاً مسجّلاً قصيراً لكيفية تشغيل النظام وصيانته.
والسؤال الذي يفرز المورّدين أكثر من أي سؤال آخر: إن أردت الانتقال إلى مطور آخر بعد سنتين، فماذا سأسلّمه؟ من يبني لمصلحتك يجيب بسهولة ويعدّد. ومن يبني ليخلق تبعية يغيّر الموضوع أو يقول إن هذا سابق لأوقته.
العقد: البنود التي تحمي الطرفين
العقد الجيد في مشروع برمجي ليس حماية من المورّد بل وثيقة تمنع الخلاف قبل وجوده، وهي تحميه منك كما تحميك منه. وهذا ما أضعه في عقودي بنفسي.
تعريف التسليم
ما معنى أن المشروع انتهى؟ قائمة أشياء قابلة للاختبار لا جملة عامة. "النظام يعمل" ليست تعريفاً. أما "المستخدم يستطيع إنشاء حجز وتعديله وإلغاؤه ويصله تأكيد" فتعريف يستطيع الطرفان الحكم عليه.
مدة ضمان الأعطال
فترة بعد الإطلاق تُصلَح فيها الأخطاء بلا مقابل، لأنها أخطاء في عمل مدفوع. ثلاثون يوماً معقولة وستون أفضل. والبند الذي يجب أن يكون واضحاً هو التفريق بين عطل وطلب جديد: إن كان النظام لا يفعل ما نص عليه التسليم فهو عطل، وإن كان يفعله وأنت تريد شيئاً آخر فهو طلب جديد. هذا التعريف وحده يمنع أشهراً من الجدل.
تسعير التغييرات
سعر ساعة أو يوم متفق عليه مسبقاً للعمل الخارج عن النطاق. الاتفاق المسبق يحوّل كل تغيير من مفاوضة إلى قرار، ويمنع أن يصبح المورّد شخصاً يبحث عن أسباب ليقول لا.
الدفع على مراحل
لا تدفع كل شيء مقدماً، ولا تتوقع من مورّد أن يعمل شهوراً مقابل لا شيء. تقسيم على نحو ٣٠ بالمئة عند البدء و٤٠ عند نظام عامل تستطيع استخدامه و٣٠ عند الإطلاق يبقي الطرفين ملتزمين. واربط كل دفعة بشيء تستطيع رؤيته واختباره لا بتاريخ.
حق التوقف
ما يحدث إن أراد أي طرف إيقاف المشروع في منتصفه. والصيغة العادلة أن العميل يدفع مقابل العمل المنفذ ويتسلّم ما أُنجز وما وُثّق منه، وأن المورّد لا يحتجز عملاً مدفوعاً. ووجود هذا البند يجعل الطرفين أكثر ارتياحاً للبدء، لأنه يحوّل المشروع من قفزة إلى خطوات.
السرية
بند متبادل. بيانات عملك وبيانات عملائك لا تُستخدم ولا تُعرض خارج المشروع دون إذن مكتوب، بما يشمل عرض المشروع في معرض أعمال المورّد. أنا أطلب إذناً صريحاً قبل إضافة أي عميل إلى سابقة أعمالي، وبعض العملاء يرفضون ولهم حقهم الكامل.
الملكية والتسليم
كما في القسم السابق، مكتوباً، ومرتبطاً بالدفعة الأخيرة.
العلامات التي تقول اتركه الآن
هذه إشارات رأيتها تتكرر عند عملاء جاءوني بعد تجربة سيئة، وكلها كانت ظاهرة قبل التوقيع.
يرفض كتابة الاستثناءات
أقوى علامة. المورّد الذي يرفض كتابة ما ليس مشمولاً يحتفظ بالغموض لأنه يخدمه. وإن قال إن كل شيء مشمول، فاسأله عن كتابة المحتوى وعن تسجيل بوابة الدفع وعن الترجمة، وستجد الحد.
يعدك بموعد لم يسأل عن قيودك
من يقول لك إنه ينجز نظامك في ثلاثة أسابيع قبل أن يسأل عن تكاملاتك وأدوارك وحجمك لا يعرف ما سيبنيه. والموعد الذي يُعطى بلا أسئلة موعد سيُخلَف، وستكون أنت من يُلام على التأخير.
يقلّل من أهمية العربية
علامة خاصة بسوقنا ومهمة. المورّد الذي يقول إن العربية مجرد ملف ترجمة لم يبنِ نظاماً عربياً حقيقياً. اسأله عن البحث العربي تحديداً: ماذا يحدث إن كتب المستخدم "استشاره" وهو يريد "استشارة"؟ الجواب يفرز فوراً.
لا يريد أن تتكلم مع من يكتب الكود
في مشروع صغير أو متوسط هذا الرفض غير مبرر. وفي مشروع كبير قد يكون منطقياً أن يكون التواصل عبر مدير مشروع، لكن أن تمنع تماماً من معرفة من يبني فهذه إشارة.
يضغط عليك بالوقت أو بخصم ينتهي
أساليب بيع سريعة لا مكان لها في مشروع ستملكه سنوات. ومن يحتاج الضغط لإقناعك يعرف أن عرضه لا يصمد للمقارنة الهادئة.
يوافق على كل شيء
العلامة التي يخطئ معظم العملاء في قراءتها، لأن الموافقة تبدو مريحة. المورّد الذي يوافق على كل طلب بلا مناقشة أثر ولا تكلفة سيكتشف المشكلة بعد البناء، وستُحل حينها بحذف شيء أو بتجاوز موعد. والمورّد الذي يقول "هذا ممكن لكنه سيكلف كذا ويؤخر كذا، وهل تريده فعلاً؟" يعمل معك.
عرضه أقل بكثير من الجميع ويرفض شرح السبب
السعر المنخفض ليس عيباً بحد ذاته، وقد يكون المورّد في سوق بتكاليف أقل أو عنده أساس جاهز يسرّعه. والعلامة ليست السعر بل رفض شرحه. اسأل: ما الذي يجعل عرضك أقل بهذا الفارق؟ والجواب الجيد محدد، والجواب السيئ مجاملة.
اطلب عرضين من نفس المورّد
حركة بسيطة وأثرها كبير. اطلب من كل مورّد عرضين: واحداً للنطاق الكامل كما وصفته، وواحداً لأصغر نسخة تحل مشكلتك الأساسية. والفرق بين العرضين يخبرك بثلاثة أشياء: هل فهم أي الأجزاء جوهرية، وهل يستطيع التفكير على مراحل، وكم من طلبك كان قابلاً للتأجيل أصلاً.
والمورّد الذي يقدّم العرضين بتفصيل ويشرح لماذا أجّل ما أجّله هو من ستحصل منه على أفضل نتيجة بميزانيتك. والذي يقدّم العرض الكامل فقط ويقول إن كل شيء ضروري إما لم يحلل مشروعك أو يفضّل الفاتورة الأكبر.
وفائدة ثانية لك: ستجد في معظم الحالات أن العرض المصغّر يكفيك فعلاً، وأنك ستقرر المرحلة الثانية بعد ثلاثة أشهر من استخدام حقيقي بأدلة بدل أن تقررها الآن بتخمين.
البريف: أرخص مال تنفقه على مشروعك
البريف الواضح يخفض عروض السعر التي تتلقاها أكثر من أي مفاوضة، والسبب حسابي لا نفسي: السعر الثابت يحتوي علاوة مخاطرة، والمورّد الذي لا يعرف ما يبنيه يسعّر النسخة السيئة من مشروعك. فكل سطر توضيح يحذف جزءاً من تلك العلاوة.
ابدأ بالمشكلة لا بالحل
"نحتاج تطبيقاً" حل. أما "فروعنا الثلاثة كل واحد منها يحتفظ بدفتر مواعيده، فنحجز للشخص نفسه مرتين ولا نرى الطاقة الاستيعابية على مستوى المجموعة" فمشكلة، وهي تدعو المورّد أن يخبرك بأرخص شيء يحلها. أحياناً يكون تطبيقاً، وغالباً يكون أقل.
صِف الواقع بصدق بما يشمل غير المرتب
الجدول في إكسل، ومجموعة واتساب التي تمسك العمل، والدفتر خلف الكاونتر، والشخص الواحد الذي يعرف الأسعار. هذه هي المتطلبات الحقيقية، والنظام الذي يتجاهلها يُتحايل عليه في شهر.
اسرد الأدوار
كل نوع من الأشخاص يلمس النظام، وتحت كل واحد من ثلاثة إلى خمسة أشياء يفعلها وشيء واحد لا يجوز أن يفعله. هذه الصفحة تمنع خلافات أكثر من أي شيء آخر في المشروع.
سمِّ تكاملاتك
لا "نظام المحاسبة عندنا" بل المنتج الفعلي ونسخته، وهل له واجهة برمجية، وهل عندك بيانات الدخول إليها. وإن كنت لا تعرف فقل لا أعرف وضَعها كبند يُفحص بمبلغ محتجز مقابله، فهذا أصدق من تركها بلا ذكر.
قل كيف يبدو النجاح برقم
تصفير الحجز المزدوج. تمرير ٣٠ بالمئة من الطلبات عبر قناتنا بدل المنصة. تقليص زمن إنتاج التقرير الشهري من يومين إلى ساعة. هذا يخبر المورّد أي الأجزاء تستحق الجهد، ويعطيك طريقة لتقييم النتيجة ليست رأياً في التصميم.
اذكر ميزانيتك
السؤال الذي يحرج الناس وهو أنفع ما تفعله. المورّد الذي يعرف نطاقك يصمم له ويخبرك بما يسعه. والذي لا يعرفه إما يخمّن عالياً فيخسر العمل، أو يخمّن منخفضاً فيسلّمك شيئاً رقيقاً. أنت لا تكشف موقفك في مفاوضة بل تمكّن شخصاً من حل المشكلة الصحيحة.
أضف أصعب ثلاث حالات
الملحق الذي يغيّر العروض أكثر من أي شيء. "عميل حجز وحدة ودفع نصف المبلغ ثم طلب تحويل الحجز لأخيه" أنفع لمورّد من عشرين سطر مواصفات. وهي أيضاً الطريقة التي تكشف بها بسرعة من فهم مشكلتك.
كيف تتصرف أثناء المشروع
الجزء الذي يملكه العميل وحده، وتأثيره على النتيجة أكبر مما يُتوقع. وأقول هذا من الجهة الأخرى: المشاريع التي تخرج أفضل ليست مع أفضل العملاء دفعاً بل مع أسرعهم قراراً.
عيّن شخصاً واحداً يقرر
شخص واحد عنده صلاحية الموافقة ويجيب في يوم. واللجنة التي تجتمع كل أسبوعين ستنتج مشروعاً أسوأ وأغلى، لأن وقت المورّد في الانتظار وقت تدفع مقابله إما مباشرة أو في سعر ثابت أعلى في المرة القادمة.
افحص مبكراً لا في النهاية
اطلب عرضاً كل أسبوع أو أسبوعين، وجرّب النظام بنفسك في كل مرة. الملاحظة في الأسبوع الثالث رخيصة، ونفس الملاحظة في الأسبوع الثاني عشر تعني إعادة عمل. والعميل الذي يقول "سأراه عند الانتهاء" يشتري مفاجأة.
احتفظ بسجل تغييرات مكتوب
كل إضافة أو تعديل يُكتب في قائمة بتكلفته وأثره الزمني، حتى عندما يكون الأثر صفراً. وهذا يحمي الطرفين: يمنعك من أن تُفاجأ بفاتورة، ويمنع المورّد من أن يحمل عشرين إضافة صغيرة بلا مقابل حتى يصل إلى نقطة يقول فيها لا لكل شيء.
قل لا للأفكار الجديدة إلى ما بعد الإطلاق
الأفكار ستأتي أثناء البناء وبعضها جيد. ضعها في قائمة للمرحلة الثانية بدل إدخالها الآن. والسبب ليس الانضباط فقط: فكرة تُقيَّم بعد ثلاثة أشهر من استخدام النظام تُقيَّم بأدلة، ونصف الأفكار التي تبدو ضرورية اليوم تختفي بعد أن ترى كيف يستخدم الناس النظام فعلاً.
وفّر محتواك
المحتوى غالباً من ١٥ إلى ٢٠ بالمئة من المشروع وهو السبب الأول لتأخر الإطلاق. إن استطعت كتابة نصوصك وتوفير صور حقيقية فأنت توفّر مالاً وتحصل على محتوى أفضل لأنك تعرف مجالك. وإن لم تستطع فقل ذلك وقت التسعير لا وقت الإطلاق.
ما تفعله إن سار المشروع في الاتجاه الخطأ
هذا القسم لأن المقالات عن اختيار المورّد تنتهي عند التوقيع، والحياة لا تنتهي هناك.
الإشارات المبكرة
تأخر الردود من أيام إلى أسبوع. وعروض تُلغى أو تُؤجَّل. وشخص جديد على المشروع لم تُخبَر عنه. وأجوبة عامة على أسئلة محددة. وطلب دفعة قبل تسليم ما تربط به. أي واحدة من هذه قابلة للتفسير، واثنتان معاً إشارة.
اكتب بدل أن تتصل
أول خطوة عند القلق: انقل التواصل إلى الكتابة. اكتب ما فهمته من آخر محادثة، وما تتوقعه، وبأي تاريخ. والمورّد الجاد سيصحّح أو يؤكد، والمورّد المتعثر سيتهرب، وفي الحالتين عرفت موقفك. وللكتابة فائدة ثانية: تحوّل الغموض إلى التزام.
اطلب الكود الآن لا لاحقاً
إن كان المستودع ليس في حسابك بعد، فهذه هي اللحظة. اطلبه كإجراء عادي لا كاتهام. والمورّد الذي يرفض تسليم كود مدفوع يخبرك بما سيحدث لاحقاً، وأنت تعرفه الآن بدل أن تعرفه بعد ثلاثة أشهر.
قسّم الدفعات أصغر
اقترح تقسيم ما بقي إلى دفعات أصغر مرتبطة بمخرجات أقرب. المورّد الذي يعمل فعلاً سيوافق لأن هذا يضمن له دخلاً متصلاً. والذي يرفض يكشف أن المشكلة ليست في التدفق النقدي.
لا تنتظر طويلاً
أكثر ما يكلف العملاء في هذه الحالات ليس المورّد المتعثر بل الانتظار. كل شهر إضافي يعني مالاً أكثر مدفوعاً وكوداً أكثر لا يفهمه غيره. وإن مرّ شهر بلا تقدم محسوس بعد أن كتبت وطلبت وقسّمت، فأوقف واحسب خسارتك وانتقل. الخسارة المحدودة أرخص من محاولة إنقاذ علاقة لن تنتج نظاماً.
وقبل أن توقف
احصل على ثلاثة أشياء: الكود في حسابك، وبيانات الحسابات والنطاق والاستضافة، وأي بيانات حقيقية في النظام. هذه الثلاثة تحدد هل سيبدأ المورّد التالي من حيث انتهى الأول أم من الصفر، والفرق بينهما قد يكون نصف المبلغ الذي دفعته.
متى لا تستأجر أحداً
قسم ضد مصلحتي المباشرة، وهو أنفع ما في المقال لبعض القراء.
لا تستأجر مطوراً إن كانت منصة جاهزة تؤدي العمل واعتراضك عليها شكلي أو يخص خطوة مزعجة. متجر بأربعين منتجاً وشحن عادي لا يحتاج برمجة مخصصة، وموقع محتوى ومدونة لا يحتاج نظاماً. تعايش سنة، وأنفق الفرق على جلب عملاء، وستعرف بعدها بدقة ما تمنعك المنصة من فعله.
ولا تستأجر أحداً للتحقق من فكرة يمكن اختبارها بصفحة هبوط ورقم جوال وأسبوعين من الإعلانات. الصفحة الواحدة تجيب على سؤال هل عرضك ينجح أسرع وأرخص من منصة كاملة، والفارق بينهما قد يكون عشرة أضعاف.
ولا تبدأ وعمليتك نفسها غير مستقرة وتتغير كل شهر، لأن برمجة عملية مرتبكة تثبّت الارتباك وتجعل تغييره أغلى. نظّمها على ورق حتى تستقر ثلاثة أشهر ثم ابنِها.
ولا تبدأ والشخص الذي سيملك المشروع داخلياً غير متفرغ الشهرين القادمين. سيتمايل المشروع وستدفع ثمن التمايل في صورة قرارات متأخرة ونطاق ينمو بلا اتجاه. والانتظار في هذه الحالة أرخص من البدء.
والمشاريع التي تنجح عندي تشترك في صفة واحدة: شخص في المنشأة احتاج الشيء بدرجة كافية ليتخذ القرارات بسرعة. فإن لم يوجد هذا الشخص بعد، فأي مورّد تختاره لن يصنع فرقاً.
نماذج التسعير وأي منها يناسب حالتك
اختيار النموذج الخطأ لحالتك يكلفك أكثر من اختيار المورّد الخطأ، وهذا ليس مبالغة. والنماذج ثلاثة.
سعر ثابت
تتفقان على نطاق ورقم. ينجح عندما يكون النطاق معروفاً مسبقاً فعلاً، وهذا صحيح أكثر بكثير مما يحب المورّدون الاعتراف به: موقع شركة، متجر، نظام حجز تستطيع وصفه بالكامل.
وما يجب أن تفهمه أن السعر الثابت يحتوي علاوة مخاطرة، لأن المورّد يحتمل عدم اليقين. ونقطة الفشل فيه هي التغيير: بعد تثبيت النطاق تصبح كل إضافة مفاوضة. فاتفقا مسبقاً على كيفية تسعير التغييرات قبل أن تحتاج واحداً.
بالوقت والجهد
تدفع مقابل ساعات أو أيام. نموذج صادق عندما لا يرى أحد نهاية العمل: منصة طويلة الأمد، أو تكامل في نظام لا تتحكم فيه، أو منتج ما زال يبحث عن شكله.
وهو ينقل المخاطرة كلها إليك، فلا ينجح إلا مع مورّد تستطيع التحقق منه. اطلب ثلاثة أشياء: حداً أعلى أسبوعياً لا يُتجاوز بلا موافقة، وعرضاً كل أسبوع أو أسبوعين، وحق التوقف في نهاية أي شهر. ومن يرفض الثلاثة يخبرك بشيء مهم.
وأضيف طلباً رابعاً يُغفل: كشفاً بالساعات موزعاً على المهام لا رقماً إجمالياً. ليس شكاً في الأمانة بل لأن الكشف المفصّل يُظهر لك أين يذهب المال، وغالباً ستجد مهمة تستهلك أكثر مما تستحق فتقرر حذفها.
عقد شهري
مبلغ شهري ثابت مقابل عمل ودعم مستمر. النموذج الصحيح بعد الإطلاق وعندما يصبح النظام مهماً للمنشأة. وتوقع أن تدفع ما بين ١٠ و٢٠ بالمئة من تكلفة البناء سنوياً، وأكثر إذا كان نظامك فيه تكاملات كثيرة لأن أنظمة الآخرين تتغير ونظامك يجب أن يلاحق.
والسؤال الذي يجب طرحه: ماذا يغطي العقد عندما لا يتعطل شيء؟ الجواب الجيد يشمل تحديثات أمنية ومراقبة ونسخاً احتياطية وعدداً محدداً من ساعات التطوير. والجواب السيئ كلمة "دعم"، ومعناها أنك تدفع شهرياً مقابل حق الإبلاغ عن المشاكل.
النموذج الهجين الذي أفضّله
سعر ثابت للنسخة الأولى بنطاق مكتوب واستثناءات صريحة، ثم عقد شهري بعد الإطلاق، ثم تسعير بالوقت للمراحل التالية غير المحددة. يعطي العميل رقماً يستطيع إدخاله في ميزانيته للجزء المعروف، ويعطي المورّد عدلاً في الجزء المجهول.
المورّد المحلي والمورّد في بلد آخر
سؤال عملي في الخليج لأن كثيراً من العمل يُنفّذ من مصر والأردن وشرق آسيا وأوروبا الشرقية، والفارق في السعر كبير بما يستحق النظر.
ما يستفاد فعلاً
السعر أولاً، والفارق حقيقي ولا يعني بالضرورة جودة أقل. وثانياً سعة السوق: مطورو لارافيل ولغات الويب المعروفة متوفرون بأعداد كبيرة في المنطقة العربية، فأنت غير مرتبط بشخص واحد وتستطيع تغيير المورّد.
ما يجب الانتباه إليه
الفروق الزمنية ليست مشكلة داخل المنطقة العربية، وتصبح مشكلة حقيقية مع شرق آسيا أو أمريكا. وإن كانت الساعات المشتركة أقل من أربع ساعات يومياً فتوقع أن كل سؤال يستغرق يوماً، وهذا يتراكم.
واللغة أهم من الوقت. المورّد الذي لا يقرأ العربية لن يكتشف أن الترجمة ركيكة ولا أن البحث العربي لا يعمل كما يتوقع المستخدم ولا أن التخطيط ينكسر في حالة معينة. وإن اخترت مورّداً لا يقرأ العربية فاحتجز ميزانية لمراجعة لغوية ووظيفية من شخص يقرأها.
وفهم السوق ثالثاً. مدى والفاتورة الإلكترونية وطرق الدفع المحلية وتوقعات المشتري الخليجي أشياء يعرفها من عمل هنا، ويتعلمها غيره على حسابك. وهذا بند قابل للحل: أخبره صراحة بما ينطبق واطلب أن يكون مكتوباً في النطاق.
الجانب القانوني
العقد عبر الحدود أصعب في التنفيذ، وهذه حقيقة يجب التعامل معها لا تجاهلها. والحماية العملية ليست قانونية بل إجرائية: دفعات صغيرة مرتبطة بمخرجات، والكود في مستودعك من اليوم الأول، والحسابات باسمك. هذه الثلاثة تحميك أكثر من أي بند جزائي لن تتقاضى بشأنه.
خلاصتي
اختر على أساس الكفاءة والتواصل أولاً والموقع ثانياً. مورّد كفؤ بعيد أفضل من مورّد ضعيف قريب، ومورّد كفؤ قريب يفهم سوقك أفضل من الاثنين إن كانت الميزانية تسمح. ولا تختر على أساس السعر وحده في أي اتجاه.
كيف تقيّم عرضاً تقنياً لا تفهم تفاصيله
الموقف الذي يشعر فيه معظم المشترين بأنهم بلا أدوات. وليسوا كذلك، فهذه أسئلة لا تحتاج خبرة ويكشف جوابها الكثير.
اسأل لماذا هذه التقنية
لا تسأل ما التقنية بل لماذا اخترتها لمشروعي. والجواب الجيد يتكلم عن مشروعك: سعة سوق المطورين، وما يحتاجه نظامك، وما ستملكه خمس سنوات. والجواب السيئ يتكلم عن التقنية نفسها بصفات عامة.
اسأل من سيستطيع صيانة هذا غيرك
سؤال ممتاز لأنه يكشف قرارات تخدم المورّد لا العميل. التقنية النادرة أو الإطار المكتوب داخلياً يعنيان أنك مرتبط. والجواب الجيد يسمّي تقنية يسهل إيجاد مطورين لها في المنطقة.
اسأل كم سجلاً جرّبتم عليه
السؤال الذي يفرز من فكّر في الأداء. ولا تسأل هل النظام قابل للتوسع، فالجواب سيكون نعم دائماً. اسأل عن حجم البيانات الذي اختُبر عليه، واطلب أن يكون الاختبار على حجم يشبه حجمك بعد سنتين لا حجمك يوم الإطلاق.
اسأل كيف تُفرض الصلاحيات
اطلب إثباتاً أن مستخدماً بدور محدود لا يستطيع الوصول إلى بيانات دور أعلى حتى عند معرفة العنوان المباشر. وإخفاء الزر ليس صلاحية، والمورّد الذي بنى بشكل صحيح يجيب على هذا في دقائق.
اسأل ماذا يحدث عند الفشل
ماذا يرى المستخدم إن انقطعت بوابة الدفع في منتصف عملية؟ وماذا يحدث إن تعطّل إرسال البريد؟ وأين يُسجَّل الطلب إن فشل كل شيء؟ هذه الأسئلة تكشف من بنى أنظمة حقيقية، لأن معالجة الفشل هي أكثر ما يُحذف من البناء السريع.
وهذا السؤال تحديداً تعلمته من موقعي الشخصي. توقف إيصال رسائل البريد عندي فترة، وخسرت خلالها طلبات حقيقية قبل أن ألاحظ، لأن البريد كان الطريق الوحيد. والقاعدة التي بنيتها بعدها وأطلبها الآن في كل نظام: الطلب يُسجَّل في النظام أولاً ثم يُرسل البريد. فإن فشل البريد تكون قد خسرت إشعاراً لا عميلاً.
اسأل من يراقب النظام بعد الإطلاق
هل هناك مراقبة تخبر أحداً إن توقف الموقع أو تعطّل شيء؟ أو ستعرف من عميل يتصل؟ وهذه إضافة رخيصة جداً ويغفلها معظم العروض.
الكود المكتوب بالذكاء الاصطناعي: ما يعنيه لك كمشترٍ
موضوع صار حقيقياً في ٢٠٢٦ ولا بد من الحديث عنه بصدق. معظم المطورين اليوم، وأنا منهم، يستخدمون أدوات ذكاء اصطناعي في كتابة الكود. والسؤال ليس هل يستخدمها مورّدك، بل كيف.
لماذا هذا ليس عيباً
الأداة تسرّع كتابة الأجزاء المتكررة، وهي أجزاء كثيرة في أي نظام. والمطور الذي يستخدمها جيداً ينتج أسرع بنفس الجودة، وهذا في مصلحتك لأنه يخفض التكلفة ويقصر المدة. ورفض الأدوات ليس دليل جودة أكثر من رفض استخدام إطار عمل.
أين تصبح مشكلة
عندما يكون المطور مجرد ناقل. الكود الذي يُنتَج بلا فهم يعمل في الحالة المعتادة وينكسر في الاستثناء، ويكون غالباً أطول وأعقد مما يحتاج، ويحمل افتراضات لم يفحصها أحد. والأخطر أنه قد يحمل مشاكل أمنية تبدو سليمة للعين غير الخبيرة: صلاحيات مفحوصة في الواجهة لا في الخادم، أو استعلامات بلا تحقق من المُدخَل.
وهذا النوع من الكود يضاعف مشكلة قديمة: الكود الذي لا أحد يفهمه. والفرق أن كود القالب المشترى يعرف المطور على الأقل أنه لم يكتبه، أما الكود المُنتَج فيُفترض أنه مفهوم وهو ليس كذلك.
كيف تفحص هذا بلا خبرة تقنية
لا تسأل هل استخدمت ذكاءً اصطناعياً، فالجواب نعم عند الجميع تقريباً والسؤال لا يفيد. اسأل أسئلة تكشف الفهم:
- اشرح لي كيف تُفرض الصلاحيات في هذا النظام، وأثبت أن دوراً محدوداً لا يصل إلى بيانات دور أعلى عند معرفة العنوان المباشر
- ماذا يحدث إن انقطعت بوابة الدفع في منتصف عملية، وأين يُسجَّل الطلب؟
- كم سجلاً جرّبتم النظام عليه، وما أبطأ صفحة فيه ولماذا؟
- ما القرار المعماري الذي اتخذته في هذا المشروع وتندم عليه؟
من بنى بفهم يجيب على هذه بتفصيل وأمثلة. ومن نقل بلا فهم يجيب بعموميات أو يصف ما تفعله الأداة. والسؤال الأخير تحديداً لا يمكن تلقينه، لأنه يحتاج ذاكرة عن قرار حقيقي اتُخذ.
البند الذي أنصح بإضافته
اطلب في العقد أن يكون الكود مفهوماً وقابلاً للصيانة من مطور آخر، وأن يُسلَّم مع توثيق للنشر وشرح للبنية. وهذا طلب كان مهماً دائماً وصار أهم، لأن سهولة إنتاج الكود اليوم تعني أن كمية الكود التي لا يفهمها أحد تنمو أسرع من قبل.
واطلب اختبار أداء على حجم بيانات يشبه حجمك بعد سنتين. الكود المُنتَج بسرعة يميل إلى الأنماط التي تعمل على بيانات قليلة وتنهار على كثيرة، وهذا الاختبار يكشفها قبل أن تكتشفها أنت في السنة الثانية.
التكلفة التقديرية لكل نوع مشروع
لتعرف هل العرض الذي وصلك في النطاق أم خارجه. هذه نطاقاتي بالدولار لعام ٢٠٢٦ على افتراض بريف واضح ومتخذ قرار واحد.
| المشروع | النطاق | ما يرفعك فيه |
|---|---|---|
| صفحة هبوط | من ٦٠٠ إلى ٢٠٠٠ | كتابة العرض، والتتبع، واختبار نسختين |
| موقع شركة ثنائي اللغة | من ١٢٠٠ إلى ٤٥٠٠ | أكثر من لغتين، وقسم وظائف، وصفحات فروع |
| متجر إلكتروني مخصص | من ٣٥٠٠ إلى ١٥٠٠٠ | أسعار تعاقدية، ومُهيّئ منتجات، وربط نقاط بيع |
| منصة حجز | من ٤٠٠٠ إلى ٢٠٠٠٠ | موارد متعددة، والدفع، وعدة فروع |
| نظام أعمال | من ٦٠٠٠ إلى ٤٠٠٠٠ | تعدد المستأجرين، والتكاملات، وتطبيق ميداني |
| منصة بالاشتراك | من ١٢٠٠٠ إلى ٦٠٠٠٠ | الفوترة بدورتها الكاملة، وعزل المستأجرين |
| تطبيق جوال | من ٥٠٠٠ إلى ٣٠٠٠٠ | منصتان أصليتان بدل قاعدة كود مشتركة، والعمل دون اتصال |
| تحديث تصميم على هيكل قائم | من ٨٠٠ إلى ٣٥٠٠ | عدد الصفحات، وهل الهيكل يحتاج تنظيفاً |
| فحص نظام قائم وتقرير | من ٣٠٠ إلى ١٢٠٠ | حجم النظام وغياب التوثيق |
والسطر الأخير هو الأرخص والأكثر إغفالاً. فحص بثلاثمئة إلى ألف ومئتي دولار قد يوفّر عليك مشروع إعادة بناء بعشرين ألفاً، وهو أول ما أوصي به لمن عنده نظام ويفكر في استبداله.
وإن كان العرض الذي وصلك أقل من الطرف الأدنى في النطاق بفارق كبير، فاسأل عن الاستثناءات. وإن كان أعلى من الطرف الأعلى، فاسأل عن سبب ذلك تحديداً، وقد يكون سبباً وجيهاً كمتطلب امتثال أو حجم بيانات أو حاجة لفريق على موعد.
كيف تفاوض بشكل صحيح
المفاوضة على السعر وحده أسوأ طريقة للتفاوض في مشروع برمجي، لأن المورّد الذي يخفض السعر بلا تغيير النطاق سيعوّضه بحذف شيء لن تراه حتى الإطلاق.
فاوض على النطاق لا على الرقم
اسأل: ما الذي يمكن حذفه أو تأجيله ليصل السعر إلى نطاقي؟ هذا سؤال يحترمه كل مورّد جيد ويجيب عليه بتفصيل. وأنت تحصل على سعر أقل مقابل شيء أقل، لا على سعر أقل مقابل نفس الوعد.
فاوض على المراحل
اطلب تقسيم المشروع إلى مرحلتين بعقدين منفصلين. تدفع الأولى، وترى النتيجة، وتقرر الثانية بأدلة. هذا يخفض مخاطرتك ويخفض علاوة المخاطرة عند المورّد في الوقت نفسه، فهو مكسب للطرفين لا تنازل من أحدهما.
فاوض على الدفعات لا على الإجمالي
إن كان التدفق النقدي هو قيدك فقل ذلك. كثير من المورّدين يقبلون دفعات أكثر وأصغر بنفس الإجمالي، وهذا يحل مشكلتك بلا خصم يحذف شيئاً من مشروعك.
قدّم شيئاً مقابل الخصم
أشياء تخفض تكلفة المورّد فعلاً ويمكنك تقديمها: محتواً مكتوباً وصوراً جاهزة، وقراراً سريعاً موثقاً في العقد بمهلة ردك، وإذناً بعرض المشروع في معرض أعماله، ومرجعية لعملاء آخرين. وكل واحدة منها تستحق خصماً حقيقياً لأنها تقلل عمله أو تجلب له عملاً.
ما لا تفاوض عليه
الصلاحيات، وسجل من فعل ماذا، والنسخ الاحتياطية، وترحيل البيانات، والشهر الأول بعد الإطلاق. هذه الخمسة إن حُذفت من أجل السعر فستدفعها لاحقاً بأضعاف. اقتطع من الميزات لا من البنية.
ماذا تنظر إليه في معرض أعمال المورّد
معرض الأعمال أقل نفعاً مما يُعتقد، لأن الصور لا تخبرك بشيء عن الكود تحته. لكن هناك ما يمكن قراءته منه.
هل المشاريع ما زالت تعمل
افتح الروابط. المشاريع التي اختفت أو تحولت إلى صفحات معلّقة أو مواقع أخرى ليست بالضرورة إشارة سيئة، فالعملاء يغيّرون اتجاههم. لكن إن كان معظمها لم يبقَ، فاسأل عن السبب.
هل هناك تنوع أو نفس المشروع مكرراً
عشرة مشاريع تبدو متشابهة تماماً تعني غالباً عملاً على قالب واحد. وهذا ليس عيباً إن كان ما تريده هو ذلك القالب، وهو عيب كبير إن كان مشروعك يحتاج شيئاً مختلفاً.
هل هناك أنظمة أو مواقع فقط
موقع تعريفي ونظام أعمال مهارتان مختلفتان. ومن معرضه كله مواقع تعريفية قد يكون ممتازاً في المواقع وبلا خبرة في الأنظمة، والعكس صحيح. فابحث في معرضه عن شيء يشبه مشروعك في النوع لا في الشكل.
هل يذكر ما بناه بالتحديد
العرض الذي يقول "طوّرنا الموقع" أقل نفعاً من الذي يقول ما المشكلة وما بُني وما النتيجة. والمورّد الذي يكتب عن مشاريعه بتفصيل يفكر في عمله.
اطلب حالة تشبه حالتك
بدل تصفح المعرض كله، اسأل: ما أقرب مشروع بنيته لحالة تشبه حالتي، وما الذي كان مختلفاً فيه؟ والجواب يخبرك بخبرته وبصدقه في الوقت نفسه.
مورّد واحد أم تقسيم العمل على اثنين
سؤال يُطرح كثيراً: أستأجر مصمماً ومطوراً منفصلين لأحصل على أفضل كل مجال، أم مورّداً واحداً يفعل الاثنين؟
متى يكون التقسيم صحيحاً
عندما يكون التصميم جزءاً جوهرياً من المنتج وليس وسيلة لعرضه. علامة تجارية تُقارن بمنتجات دولية، أو تطبيق تجربته هي ميزته، أو منصة ستُعرض على مستثمرين. في هذه الحالات مصمم متخصص يضيف ما لا يضيفه مطور عنده حس تصميم معقول.
والشرط الذي يجعل التقسيم ينجح: شخص واحد مسؤول عن النتيجة النهائية بالاسم. وإن لم يوجد فستكون أنت ذلك الشخص، وستجد نفسك تنقل الملاحظات بين الطرفين وتحكم في خلافات تقنية لا تملك أدواتها.
متى يكون التقسيم خطأ
في معظم المشاريع المتوسطة والصغيرة. والسبب أن نقطة التسليم بين المصمم والمطور هي حيث تضيع الأمور: المصمم يرسم شاشة لا تحمل حالة فراغ ولا حالة خطأ، فيضطر المطور لاختراعهما. أو يرسم شاشة لا تتحمل اسماً عربياً طويلاً. أو ينسى كيف تبدو الشاشة على جوال بعرض ٣٦٠ بكسل.
وكل واحدة من هذه تصبح محادثة بين ثلاثة أطراف، وأنت أحدهم، والمصمم انتهى عمله ولا يريد التعديل والمطور لا يريد قرار تصميم. وهذا أكثر ما يؤخر المشاريع المقسّمة.
الترتيب الذي أنصح به
إن قسّمت، فاجعل المطور طرفاً في مرحلة التصميم لا مستقبلاً لها. مراجعة واحدة من المطور على الشاشات قبل اعتمادها توفّر أسابيع، لأنه سيسأل عن الحالات التي لم تُرسم. واكتب في عقد المصمم أنه ملزم بجلستي تعديل بعد بدء التطوير.
وإن لم تقسّم، فاسأل المورّد الواحد عن التصميم تحديداً: اطلب أن ترى شاشات من مشاريعه على الجوال لا على المكتب فقط، وانظر هل حالات الفراغ والخطأ مصممة. ومن يصمم حالة الخطأ هو من فكّر في المستخدم.
والمحتوى طرف ثالث يُنسى
وأضيف تحذيراً: تقسيم العمل على مصمم ومطور وترك المحتوى بلا صاحب هو أشهر سبب لمشروع يبقى جاهزاً وغير مُطلق لأشهر. سمِّ من يكتب المحتوى وبأي تاريخ قبل أن يبدأ أي تصميم، لأن التصميم على نص حقيقي يختلف عن التصميم على نص مؤقت، والفرق بينهما إعادة ترتيب كامل.
جدول مقارنة أنواع المورّدين
ملخص ما سبق في صورة تستطيع العودة إليها.
| المورّد | التكلفة النسبية | الأنسب له | المخاطرة الرئيسية | ما تطلبه منه تحديداً |
|---|---|---|---|---|
| وكالة محلية | الأعلى | ميزانيات كبيرة، مشتريات رسمية، عدة فرق بالتوازي | الدفع مقابل إدارة حساب لا هندسة | أسماء من يكتب الكود في العقد |
| استوديو إقليمي | متوسطة | معظم أنظمة الأعمال والمواقع الجدية | الجودة متفاوتة بشدة بين استوديو وآخر | نظام عامل تدخل إليه، واتصال بعميل سابق |
| مطور مستقل خبير | متوسطة إلى منخفضة | مشروع واضح يسع رأساً واحداً | الطاقة الاستيعابية، وما يحدث إن اختفى | الكود في مستودعك من اليوم الأول، وتوثيق النشر |
| فريق صغير من مستقلين | متوسطة | مشروع يحتاج تصميماً وتطويراً معاً | غياب من ينسّق، فتصبح أنت المنسّق | شخص واحد مسؤول عن التسليم بالاسم |
| منصات أقل عرض سعر | الأدنى | مهام صغيرة موصوفة بدقة ويمكن التخلي عنها | ستدفع مرة ثانية عادة | نطاق مكتوب بدقة لا يحتاج اجتهاداً |
وأعمل بالصيغة الثالثة، فاقرأ الجدول بهذا الاعتبار. والنسخة الصادقة من تحيّزي كتبتها في أول المقال وأكررها: الشخص الخبير هو الجواب الصحيح عندما يسع المشروع رأساً واحداً، والجواب الخاطئ عندما يحتاج فعلاً أربعة أشخاص يعملون بالتوازي على موعد صلب.
من يفعل ماذا: التصميم والتطوير والمحتوى والتسويق
خلط هذه الأربعة سبب شائع لخلافات لا علاقة لها بكفاءة أحد. وهي مهارات مختلفة، ومن النادر أن يجيدها شخص واحد كلها.
التصميم
كيف يبدو النظام وكيف يتحرك المستخدم فيه. والمصمم الجيد يرسم الشاشات وحالاتها، بما يشمل الشاشة الفارغة قبل وجود بيانات وشاشة الخطأ عند الفشل. وهذه الحالات هي الفرق بين نظام يُوصف بالاحترافي وآخر لا.
وما يجب أن تتوقعه: عدداً محدداً من مرات التعديل مكتوباً في العرض. والتعديلات المفتوحة إما تنتهي بفاتورة مفاجئة أو بمصمم متضايق، وكلاهما سيئ.
التطوير
بناء ما صُمّم بحيث يعمل ويصمد. والمطور الجيد سيطرح أسئلة على التصميم، وبعضها قد يبدو إزعاجاً: ماذا يحدث إن كان الاسم طويلاً جداً؟ وماذا يحدث إن كانت القائمة فارغة؟ وماذا إن ضغط المستخدم مرتين؟ هذه أسئلة في مصلحتك.
المحتوى
النصوص والصور، وهي غالباً من ١٥ إلى ٢٠ بالمئة من المشروع والسبب الأول لتأخر الإطلاق. وليست مهارة مطور ولا مصمم، وإن كُتبت منهما فقد تكون ضعيفة. والنسخة العربية تحديداً: الترجمة الآلية مكشوفة فوراً للقارئ العربي وتضر بالثقة أكثر من غيابها.
والقرار الذي أوصي به: اكتب محتواك بنفسك إن استطعت، فأنت تعرف مجالك وستوفّر مالاً وتحصل على نص أفضل. وإن لم تستطع، فاستأجر كاتباً صريحاً كبند مستقل لا تتركه للمطور.
التسويق وتهيئة محركات البحث
وهنا الخلط الأكثر تكلفة. جزء من التهيئة يجب أن يكون داخل البناء بلا بند إضافي: هيكل عناوين منطقي، وعنوان ووصف لكل صفحة في النطاق الصحيح، وترتيب عناوين فرعية بلا قفزات، وبيانات منظمة، وخريطة موقع، وربط صحيح بين النسخة العربية والإنجليزية، وسرعة تحميل مقيسة.
وجزء آخر خدمة مستمرة ومنفصلة: اختيار الكلمات المستهدفة، وكتابة المحتوى الذي يستهدفها، وبناء صفحات لنيّات بحث محددة، ومتابعة النتائج شهرياً.
فإن وجدت في عرض سعر بنداً باسم "تهيئة محركات البحث" فاسأل أي الاثنين هو. إن كان الأول فأنت تُحاسب مقابل أداء العمل بشكل صحيح. وإن كان الثاني فهو بند مشروع ويجب أن يكون شهرياً لا مرة واحدة.
وملاحظة تخص سوقنا: المحتوى العربي الأصلي ما زال أقل تنافسية بكثير من الإنجليزي في معظم المجالات المهنية. منشأة تكتب عشر صفحات عربية حقيقية عن تخصصها تستطيع الوصول إلى نتائج لن تصلها بميزانية إعلانية مضاعفة. وأرخص توفير متاح في هذا السوق، ومعظم المنشآت لا تستخدمه لأنها تنسخ محتوى إنجليزياً وتترجمه.
من تحتاج فعلاً
في مشروع صغير أو متوسط يكفي مطور كفؤ عنده حس تصميم معقول، مع كتابة محتواك بنفسك. وفي مشروع يُعتمد عليه بصرياً، كعلامة تجارية تُقارن بمنتجات دولية، تحتاج مصمماً حقيقياً. وفي مشروع يعتمد على جلب زيارات، تحتاج من يشتغل على المحتوى شهرياً بعد الإطلاق. والخطأ أن تدفع للأربعة في مشروع يحتاج واحداً، أو أن تدفع لواحد في مشروع يحتاج ثلاثة.
المدد الزمنية الواقعية
المدة تكلفة، لأن نظاماً ينطلق متأخراً أربعة أشهر يعني أربعة أشهر من العمل لم يُدعَم. وهذه تقديرات من تاريخ التوقيع على افتراض أن القرارات تصل في يومين وأن المحتوى جاهز.
| المشروع | المدة الواقعية | ما يؤخره عادة |
|---|---|---|
| صفحة هبوط | من ٣ إلى ٧ أيام | انتظار حسم العرض التسويقي |
| موقع شركة | من أسبوعين إلى ٥ أسابيع | توفير المحتوى والصور |
| متجر إلكتروني | من ٤ إلى ١٠ أسابيع | بيانات المنتجات وتسجيل بوابة الدفع |
| منصة حجز | من ٥ إلى ١٢ أسبوعاً | قواعد التوفّر التي لم يكتبها أحد |
| نظام أعمال | من ٨ إلى ٢٠ أسبوعاً | اكتشاف كيف تعمل المنشأة فعلاً |
| تطبيق جوال | من ٦ إلى ١٦ أسبوعاً زائد المراجعة | مراجعة المتجر وتأخر الخادم |
والنمط المشترك: التأخير يأتي من جهة العميل أكثر بكثير من جهة المورّد، ودائماً تقريباً من قرار لا يملكه أحد. فإن أردت مشروعاً ينتهي في وقته، سمِّ شخصاً واحداً يستطيع الموافقة وأعطه الصلاحية.
وتسجيل بوابة الدفع يستحق تحذيراً مستقلاً. فيه أوراق وتحقق وانتظار، ولا علاقة له بجاهزية الكود. وشاهدت مشاريع جاهزة تنتظر ثلاثة أسابيع بلا إطلاق لأن أحداً لم يبدأ طلب البوابة قبل انتهاء البناء. ابدأه في يوم بدء المشروع.
كيف تدير العلاقة أسبوعياً
إيقاع بسيط يمنع معظم المشاكل، وهو ما أعمل به مع عملائي.
مكالمة واحدة أسبوعية قصيرة
عشرون دقيقة ثابتة في موعد ثابت. ما أُنجز، وما سيُنجز، وما هو معطّل في انتظار قرار منك. والنقطة الثالثة هي الأهم ويجب أن تكون صريحة، لأن معظم التأخير في المشاريع ينتظر قراراً لم يعرف العميل أنه مطلوب منه.
رابط تجريبي محدّث دائماً
اطلب بيئة تجريبية تستطيع فتحها في أي وقت لترى آخر حالة. لا صوراً ولا مقاطع. وهذا يمنع المفاجآت ويحوّل الملاحظة من جدال إلى شيء مرئي.
قائمة واحدة للملاحظات
مكان واحد تُكتب فيه كل الملاحظات بأولويتها، لا رسائل واتساب متفرقة ولا بريد. والملاحظة في محادثة تُنسى، وفي قائمة تُنفّذ أو تُرفض بسبب مكتوب.
اختبر بنفسك لا بالوكالة
جرّب النظام بنفسك في كل مرحلة، ولا تكتفِ بتجربة موظف. أنت الذي تعرف الاستثناءات وأنت الذي ستلاحظ أن شيئاً ناقص.
افصل بين العطل والطلب الجديد في كلامك
عادة تحسّن العلاقة كثيراً. عندما تكتب ملاحظة قل هل هي شيء لا يعمل كما اتفقنا، أم شيء جديد تريده. والعميل الذي يفصل بين الاثنين يحصل على تعامل أفضل، لأن المورّد يعرف ما هو واجب عليه وما هو طلب يُسعَّر.
اطلب ملخصاً مكتوباً بعد كل اجتماع
عادة تستغرق دقيقتين وتمنع نصف الخلافات. بعد كل مكالمة يُكتب ملخص بما اتُفق عليه وما بقي معلّقاً ومن مسؤول عن ماذا، ويرسله أحد الطرفين ويؤكده الآخر. ولا يهم من يكتبه، فاكتبه أنت إن لم يكتبه المورّد.
والفائدة ليست في إثبات شيء على أحد بل في كشف الفهم المختلف مبكراً. ففي كثير من المرات كتبت ملخصاً لاجتماع وجاءني التصحيح من العميل، وكان الفرق بين ما فهمته وما قصده فرقاً كان سيكلف أسبوعين لو ظهر بعد البناء.
حدد مهلة ردك أنت أيضاً
بند أنصح بوضعه في العقد: المورّد يرد خلال يوم عمل، والعميل يرد على طلبات القرار خلال يومين. والبند الثاني يحميك أكثر مما تتوقع، لأنه يحوّل تأخيرك إلى شيء مرئي قبل أن يتحول إلى تأخير في التسليم تُلام عليه.
حماية بياناتك أثناء المشروع
بند يُغفل لأن الانتباه يتركز على ما سيُبنى، والمورّد خلال المشروع يحصل على وصول إلى بياناتك الحقيقية إن لم تُنظّم ذلك.
لا تسلّم بيانات حقيقية للتطوير
المورّد يحتاج بيانات ليبني ويختبر، ولا يحتاج بيانات عملائك الحقيقية. والنسخ المجهّلة، التي تُستبدل فيها الأسماء وأرقام الجوال والبريد بقيم مولّدة مع إبقاء البنية والأحجام، تكلّف شيئاً لا يُذكر وتزيل فئة كاملة من المخاطر.
واطلبها صراحة في بداية المشروع. وإن كان هناك مرحلة تحتاج بيانات حقيقية، كترحيل أو فحص مشكلة، فاجعلها محدودة بالوقت وبالوصول وسجّل من رآها.
حسابات باسم المورّد لا كلمات مرورك
لا تعطِ المورّد كلمة مرور حسابك الإداري. أنشئ له حساباً باسمه بالصلاحيات التي يحتاجها، لتستطيع تعطيله في ثانية عند انتهاء المشروع ولتعرف من فعل ماذا من سجل التدقيق.
وهذا ينطبق على كل شيء: الاستضافة، والنطاق، وبوابة الدفع، والتحليلات، والبريد. والحساب المشترك يعني أنك لا تستطيع إنهاء الوصول إلا بتغيير كلمة المرور وإبلاغ الجميع، وهذا لا يحدث.
بند السرية متبادل
اتفاق سرية يغطي بياناتك وبيانات عملائك، ويغطي كذلك ما يراه المورّد من أرقامك وعملياتك. وهو بند عادي لا يُستغرب طلبه، ومن يرفض توقيعه في مشروع يلمس بيانات عملاء يخبرك بشيء.
وأضف نقطة تُنسى: الإذن بعرض المشروع في معرض أعماله. أنا أطلب هذا الإذن صراحة من كل عميل قبل الإضافة، وبعض العملاء يرفضون ولهم حقهم الكامل. وإن كان مشروعك حساساً فاكتب المنع في العقد بدل أن تكتشف اسمك في موقع مورّدك.
عند الانتهاء
قائمة من ثلاثة أسطر تُنفَّذ في نصف ساعة: عطّل حسابات المورّد، واحذف أي نسخ بيانات عنده بإقرار مكتوب، وبدّل أي مفاتيح أو كلمات مرور مشتركة. وهذا إجراء عادي لا تعبير عن شك، واطلبه كجزء من التسليم.
التعامل مع المشتريات الرسمية
قسم لمن يعمل في منشأة كبيرة أو يبيع لجهة حكومية أو شبه حكومية، لأن القواعد تختلف.
المشتريات الرسمية تطلب أشياء لا علاقة لها بجودة البرمجة: سجلاً تجارياً بنشاط مطابق، وشهادات التزام نظامية، وضماناً بنكياً أحياناً، وعقداً نموذجياً لا يقبل التعديل، ودورة دفع طويلة. وهذا يُخرج المطورين المستقلين والاستوديوهات الصغيرة من المعادلة بشكل عملي، لا لأنهم أقل كفاءة بل لأنهم لا يستوفون الشروط الإدارية.
فإن كنت ملزماً بهذه الدورة فاعلم أنك تدفع علاوة إدارية حقيقية، وأن المورّد سيحمّل عليك تكلفة الضمان والتأخير في السداد. واحسب ذلك في ميزانيتك بدل أن تقارن عرضه بعرض مستقل لا يمر في نفس الدورة.
وهناك ترتيب يعمل ويُستخدم كثيراً: مورّد مؤهل إدارياً يتعاقد مع المنشأة، ومطور خبير ينفّذ تحته. وهذا مقبول وشائع، والشيء الذي يجب أن تطلبه هو معرفة من ينفّذ فعلاً واسمه في العقد، وألا تكون تدفع علاوة إدارية مرتين.
كيف تبني علاقة طويلة مع مورّد جيد
إن وجدت مورّداً كفؤاً يتواصل جيداً، فالاحتفاظ به أوفر من البحث مرة أخرى. وهذا ليس كلاماً لطيفاً بل حساب: كل مورّد جديد يحتاج وقتاً لفهم عملك، وأنت تدفع ذلك الوقت.
ادفع في الوقت
أبسط شيء وأكثره أثراً. المورّد الذي يُدفع له في موعده يضع مشروعك في مقدمة أعماله، والذي يطارد دفعاته يضعه في آخرها. وهذا ليس عقاباً بل واقع تدفق نقدي عند أي عمل صغير.
اجمع ملاحظاتك
عشر ملاحظات صغيرة في رسالة واحدة أسبوعياً أنفع من عشر رسائل في يوم. والمورّد يستطيع ترتيب عمله حولها، والمقاطعة المتكررة تكلّف وقتاً لا يظهر في فاتورة لكنه يظهر في سرعة التسليم.
افصل بين العطل والطلب
ذكرته سابقاً وأعيده لأنه أكثر ما يحسّن العلاقة. العميل الذي يقول "هذا لا يعمل كما اتفقنا" و"هذا شيء جديد أريده، كم يكلف؟" يحصل على تعامل مختلف عن العميل الذي يسمي كل شيء عطلاً.
أعطه رؤية لما يأتي
إن كنت تعرف أن عندك مرحلة ثانية بعد ثلاثة أشهر فقل ذلك. المورّد الذي يعرف أن هناك عملاً قادماً يبني بشكل مختلف: يترك المساحة الصحيحة في البنية، ويوثّق أكثر، ويسعّر أفضل لأن المخاطرة أقل.
ارجع إليه بالفحص قبل القرار
إن فكرت في توسعة أو تغيير، اسأله قبل أن تقرر. المورّد الذي يعرف نظامك يستطيع أن يخبرك في ساعة بما سيكلفه قرارك، وهذه الساعة توفّر أحياناً مشروعاً كاملاً.
واحتفظ بقدرتك على المغادرة
العلاقة الطويلة الصحية ليست تبعية. الكود في مستودعك، والحسابات باسمك، والنشر موثّق. وهذا يجعل بقاءك اختياراً لا اضطراراً، والمورّد الجيد مرتاح لذلك، لأن العميل الذي يستطيع المغادرة ولا يغادر هو أفضل شهادة عليه.
إن كانت ميزانيتك أقل من كل العروض
موقف شائع ولا يعني أن المورّدين مبالغون ولا أنك يجب أن تختار الأرخص. وهذه الخيارات الحقيقية مرتبة من الأفضل إلى الأسوأ.
قلّص النطاق إلى نسخة أولى تعمل
الخيار الأفضل دائماً. اسأل كل مورّد: ما أصغر نسخة تحل مشكلتي الأساسية وتدخل في ميزانيتي؟ وستتفاجأ كم ينزل الرقم عند حذف ما يمكن تأجيله. ونصف نظام مبني بإحكام يستطيع أن يكبر، ونظام كامل مبني بسوء يجب أن يُستبدل فتدفع مرتين.
قسّمه إلى مرحلتين بعقدين
ادفع الأولى من ميزانية هذا الربع والثانية من الربع القادم أو من عائد الأولى. وهذا يحل مشكلة التدفق النقدي بلا حذف شيء، وكثير من المورّدين يرحّبون به لأنه يضمن لهم عملاً متصلاً.
استخدم منصة جاهزة مؤقتاً
إن كان ما تحتاجه عاماً، فمنصة جاهزة باشتراك شهري أرخص بكثير من بناء ناقص، وتنطلق هذا الأسبوع. واستخدمها سنة لتعرف بالضبط ما تمنعك من فعله، ثم ابنِ ذلك الجزء تحديداً. هذا يحوّل التخمين إلى معرفة بثمن الاشتراك.
وفّر ما تستطيع توفيره بنفسك
اكتب محتواك، ووفّر صوراً حقيقية، ونظّف بياناتك قبل الترحيل، واتخذ قراراتك في يوم. الأربعة تخفض تكلفة المورّد فعلاً وتستحق خصماً حقيقياً، وهي أفضل من طلب خصم مجرد.
وما لا أنصح به
لا تأخذ العرض الأرخص بفارق كبير أملاً في أنه نفس الشيء بسعر أقل. ولا تحذف الصلاحيات أو النسخ الاحتياطية أو ترحيل البيانات أو الشهر الأول بعد الإطلاق لأجل السعر. ولا تؤجل المشروع كله ستة أشهر توفيراً، لأن تكلفة التأجيل ليست صفراً: هي كل الأشهر التي عملت فيها يدوياً وكل الطلبات التي خسرتها لأن لا طريقة لاستقبالها.
إن كان ما تحتاجه إصلاحاً لا بناءً
قسم أخير لأن كثيراً من القراء في هذا الموقف وهم يظنون أنهم في موقف آخر.
إن كان عندك موقع أو نظام يعمل وتشتكي منه، فحدّد الشكوى بدقة قبل أن تطلب عرضاً. شكله قديم؟ هذا تحديث تصميم بجزء بسيط من إعادة البناء. بطيء؟ هذا تحليل أداء يُقاس بالأيام، والسبب غالباً عدد صغير من الاستعلامات لا حجم الخادم. لا يأتيك منه عملاء؟ هذه مشكلة محتوى وظهور في البحث لا مشكلة كود. كل تعديل يأخذ أسابيع ويكسر شيئاً؟ هذه هي الشكوى الوحيدة التي تبرر إعادة البناء فعلاً.
والمورّد الذي تطلب منه عرضاً لإعادة بناء سيعطيك عرضاً لإعادة بناء. فاطلب منه فحصاً أولاً، بثلاثمئة إلى ألف ومئتي دولار، واطلب أن يكون التقرير فيه جواب صريح على سؤال واحد: ما أرخص شيء يحل شكواي المحددة؟
فعلت هذا الفحص لثلاثة عملاء في قطاع الطيران جاءوا بميزانيات إعادة بناء كاملة، وخرج الثلاثة بنسخ محسّنة من مواقعهم بجزء بسيط من المبلغ. وكان بإمكاني أخذ الميزانية والبناء من الصفر، وكانت النتيجة ستكون جيدة ومكلفة بلا سبب. والمورّد الذي يقول لك إنك لا تحتاج ما تطلبه هو أقوى شهادة على أنه يعمل لمصلحتك، وهو ما يختصر هذا المقال كله.
الأسئلة التي يسألها المورّد الجيد عنك
قلبت المقال في هذا القسم، لأن أدق طريقة لتقييم مورّد هي النظر إلى ما يسألك عنه. فإن لم يسأل معظم هذه، فهو يسعّر تخميناً.
- ما المشكلة التي تحلها، وما يحدث اليوم بدون حل؟
- من يستخدم النظام، وما لا يجوز أن يفعله كل دور؟
- ما أصعب ثلاث حالات في عملك؟
- مع أي أنظمة يجب أن يتكلم، وهل عندك بيانات الدخول إليها؟
- هل تمر الأموال من خلاله، وأي طرق دفع يستخدمها عملاؤك؟
- هل تصدر فواتير في السعودية؟
- كم مستخدماً وكم عملية في الشهر، وكم فرعاً؟
- من يكتب المحتوى العربي؟
- من يملك القرار من جهتك وهل هو متفرغ؟
- ما نطاق ميزانيتك والتاريخ المطلوب وسببه؟
- ما أقل نسخة تستطيع تشغيل عملك بها؟
- هل تخطط للتوسع لبلد ثانٍ أو لبيع النظام لآخرين خلال ثلاث سنوات؟
السؤال الأخير مهم بشكل خاص ويسأله قليلون. تعدد العملات والكيانات القانونية وعزل المستأجرين قرارات معمارية تُتخذ في الأسبوع الأول، وإضافتها بعد سنتين عمل يقارب إعادة البناء. والمورّد الذي يسألك عنه يحميك من فاتورة كبيرة بعد سنتين.
وإن لم يسأل أحد من المتقدمين هذه الأسئلة، فأجب عليها بنفسك وأرسلها إلى الجميع. ستحصل على عروض أدق وستعرف من يقرأ.
الصيانة: كيف تختار من يصون نظامك
قرار يُؤخَذ بإهمال لأنه يأتي بعد الإطلاق والانتباه قد انتقل. وهو يحدد عمر نظامك.
من بناه ليس بالضرورة من يصونه
البقاء مع من بنى أفضل في الغالب، لأنه يعرف النظام ولا يحتاج وقتاً لفهمه. لكن هذا ليس قانوناً. وإن كانت تجربتك معه سيئة في التواصل، أو كان أسعاره بعد الإطلاق غير معقولة، أو اختفى لأسابيع، فالانتقال مشروع ومتاح، بشرط أن تكون قد أخذت الكود والتوثيق والحسابات.
ما يجب أن يغطيه عقد الصيانة
تحديثات أمنية لإطار العمل والاعتماديات، ومراقبة تخبرك إن توقف شيء، ونسخاً احتياطية مع فحص دوري أنها تُستعاد، وإصلاح الأعطال، وعدداً محدداً من ساعات التطوير الصغير شهرياً، ووقت استجابة متفقاً عليه للمشاكل الحرجة.
والبند الأخير هو الذي يستحق الإصرار: ما وقت الاستجابة إن توقف النظام في يوم عمل؟ وإن توقف في عطلة؟ الجواب المكتوب يحوّل العقد من كلام إلى التزام.
ما لا يجب أن تدفعه في الصيانة
إصلاح عيوب في عمل مدفوع أصلاً خلال فترة الضمان. وميزات جديدة تُسمّى صيانة. و"دعم" بلا تعريف. واطلب كشفاً دورياً بما تم فعلاً في العقد الشهري، لأن العقد الذي لا يُنتج كشفاً يتحول بعد أشهر إلى فاتورة لا أحد يعرف مقابل ماذا.
الصيانة المؤجلة فاتورة مؤجلة
البند الذي يحاول الناس حذفه وهو الأغلى عند تجاهله. الاعتماديات تتراكم فيها ثغرات معروفة سواء نظر إليها أحد أم لا، وفاتورة ثلاث سنوات من التحديثات المؤجلة تأتي مرة واحدة، عادة في صورة ترقية لا يمكن تنفيذها على مراحل ولا أحد يستطيع تقدير مدتها.
كيف تنقل مشروعاً إلى مورّد جديد
قسم عملي لمن هو في هذا الموقف الآن، وهو موقف شائع أكثر مما يُعتقد.
اجمع ما تملكه قبل أي محادثة
قبل أن تتكلم مع مورّد جديد، اجمع: الكود، وبيانات الاستضافة والنطاق، ونسخة من قاعدة البيانات، وأي توثيق أو شرح، وقائمة الحسابات الخارجية وأسماء من تملكها. وكلما كانت هذه القائمة أكمل كان السعر أقل والانتقال أسرع.
وإن كان بعضها عند المورّد السابق فاطلبه كإجراء عادي وبصيغة مكتوبة مهذبة. ومعظم المورّدين سيسلّمون ما هو مدفوع. ومن يرفض، فسجّل الطلب كتابة وانتقل بما عندك، ولا تضيّع شهوراً في النزاع.
اطلب فحصاً قبل أي قرار
لا تطلب عرض سعر لإعادة بناء، بل اطلب فحصاً مدفوعاً يحدد: هل الكود سليم وقابل للمتابعة، أو سليم لكن غير موثّق، أو سيئ ويستحق إعادة بناء. والفحص يكلف جزءاً بسيطاً من البناء وهو أفضل مال تنفقه في هذا الموقف.
والنتائج الثلاث مختلفة تماماً في التكلفة. الحالة الأولى تعني أنك تدفع مقابل تعديلات فقط. والثانية تعني أسبوعاً أو اثنين لفهم وتوثيق ثم العمل عادياً. والثالثة تعني مشروعاً جديداً، وحينها اعلم أن إعادة البناء يجب أن تكلف أقل من الأصل لا أكثر، لأن المتطلبات معروفة الآن: عندك نظام عامل يخبرك بالضبط بما يفعله.
انتبه للمورّد الذي يقول إعادة بناء فوراً
إشارة تستحق الشك. المورّد الذي ينظر إلى نظامك ويقول في أول مكالمة إنه يحتاج إعادة بناء كاملة قد يكون صادقاً، وقد يكون يفضّل البناء من الصفر لأنه أسهل عليه وأكبر فاتورة. فاطلب تفصيلاً: ما المشكلة البنيوية تحديداً، وما الذي لا يمكن إصلاحه، ولماذا.
وفعلت هذا الفحص لثلاثة عملاء في قطاع الطيران جاءوا يطلبون مواقع جديدة بميزانيات إعادة بناء كاملة. ووجدت أن الهيكل تحت سليم وأن المشكلة في العرض والسرعة والمحتوى. فخرج الثلاثة بنسخ محسّنة من مواقعهم بجزء من المبلغ المعروض عليهم. والفحص الذي كلّفهم قليلاً وفّر عليهم كثيراً.
انقل على مراحل إن كان النظام يشغّل عملاً حقيقياً
إن كان الاستبدال هو القرار، فهناك طريق وسط يُغفل: اترك النظام القديم يعمل وابنِ الجديد بجانبه، وانقل مجالاً واحداً في كل مرة. أبطأ إجمالاً وأغلى على الورق، لكن العمل لا يتوقف والمخاطرة في كل خطوة صغيرة بما يمكن التعافي منه. ولأي نظام يشغّل عمليات حقيقية هذا ما أوصي به عادة.
ثلاث حالات حقيقية
هذه مواقف مرّت عليّ، أكتبها لأن النمط فيها أنفع من أي قائمة.
العميل الذي دفع مرتين
منشأة طلبت نظاماً واختارت أقل عرض بفارق كبير. وسُلّم شيء يعمل في العرض التجريبي. وبعد أربعة أشهر من التشغيل الحقيقي ظهرت ثلاث مشاكل: البيانات لم تكن معزولة بين الفروع فرأى مدير فرع أرقام فرع آخر، ولوحة الإدارة لم تكن قابلة للاستخدام فعاد الفريق إلى جداول إكسل بالتوازي، والكود كان بلا توثيق ولا تستطيع تعديله بأمان.
والمبلغ الذي دفعته في الإنقاذ تجاوز ما كان سيدفعه في البناء الصحيح من البداية. والسبب أن المنقذ يحتاج فهم ما بُني أولاً، ثم إعادة بناء أجزاء منه وهي مشغولة ببيانات حقيقية لا يجوز فقدانها، وهذا أصعب من البناء على أرض فارغة.
والدرس: الفارق في السعر لم يكن خصماً بل حذفاً. والسؤال الذي كان سيكشفه قبل التوقيع واحد: ما غير المشمول في هذا السعر؟
العميل الذي وفّر بالرفض
عميل مطعم جاء بقائمة طلبات كاملة: طلب إلكتروني، وتطبيق جوال، وبرنامج ولاء، وحسابات عملاء، وتكامل مع المحاسبة. وكان الدافع واضحاً وقابلاً للحساب: عمولة منصات التوصيل من كل طلب.
وما بنيناه كان أصغر بكثير: قائمة بخيارات تعديل تطابق عمل المطبخ، ونطاقات توصيل، وساعات عمل باستثناءاتها، وحالة طلب يراها العميل، وشاشة مطبخ لا تعتمد على شخص يراقب تبويب متصفح. والثلاثة الباقية نوقشت وأُجّلت.
والمشروع سدد ثمنه من العمولة الموفّرة، والميزات المحذوفة أصبحت قابلة للإضافة من التوفير بتمويل من نظام يعمل بالفعل. والترتيب المعاكس، بناء كل شيء أولاً والأمل في أن يسدد، هو كيف تموت مشاريع برمجيات المطاعم.
والدرس: المورّد الذي رفض بنوداً من طلبك قد يكون أنفع من الذي وافق على كل شيء.
العميل الذي احتاج فحصاً لا مشروعاً
ثلاثة عملاء في قطاع الطيران، كل واحد منهم جاء بميزانية إعادة بناء كاملة وطلب موقع جديد. والفحص أظهر أن الهيكل سليم، وأن ما يُشتكى منه فعلاً هو السرعة والعرض والمحتوى.
فخرجوا بنسخ محسّنة لا جديدة، بجزء بسيط من المبلغ. وكان بإمكاني أن آخذ ميزانية إعادة البناء وأبني من الصفر، وكانت النتيجة ستكون جيدة ومكلفة بلا سبب.
والدرس: قبل أن تقرر بناء شيء جديد، ادفع لشخص كفؤ ليخبرك هل تحتاجه. وإن قال لك مورّد إنك لا تحتاج ما تطلبه، فهذه أقوى شهادة على أنه يعمل لمصلحتك.
علامات المورّد الممتاز
كتبت علامات الخطر، والعدل يقتضي الجهة الأخرى. هذه ما أراه في المورّدين الذين يُسلّمون عملاً جيداً باستمرار.
يقلّص طلبك
أقوى علامة إيجابية. المورّد الذي ينظر إلى قائمة طلباتك ويقول إن هذه الثلاثة يمكن تأجيلها وإن هذه تحتاجها فعلاً، ويشرح السبب في كل حالة، يفكر في نتيجتك لا في فاتورته. والذي يوافق على القائمة كلها ويسعّرها يفكر في الفاتورة.
يسأل عن أصعب حالاتك
المورّد الذي يطلب أن ترويه الحالة الاستثنائية التي تعالجونها يدوياً بنى أنظمة حقيقية قبلاً، لأنه يعرف أن المشروع يُقاس بها لا بالمسار المثالي.
يكتب الاستثناءات بلا أن تطلب
العرض الذي يأتي وفيه قسم لما ليس مشمولاً، بلا أن تطلبه أنت، من مورّد يعرف أين تحدث الخلافات ويفضّل منعها.
يعطي خياراً أرخص
المورّد الذي يقول لك إن منصة جاهزة تكفيك، أو إن تحديث تصميم يكفي بدل إعادة بناء، أو إن صفحة واحدة تكفي بدل موقع، يخسر مالاً في هذه المحادثة ويكسب عميلاً لسنوات. وهذا النوع يستحق أن تحتفظ به.
يقول لا أعرف
علامة يستهين بها كثيرون. المورّد الذي يقول إنه لم يعمل مع هذا النظام قبلاً ويحتاج يوماً لفحص واجهته البرمجية قبل التسعير أصدق من الذي يؤكد أن كل شيء ممكن. والثقة الكاملة في كل سؤال ليست خبرة بل بيعاً.
يعطيك ما تحتاجه للانتقال عنه
المورّد الذي يضع الكود في حسابك من اليوم الأول ويكتب توثيق النشر ويسجّل الحسابات باسمك يبني لمصلحتك. وهو يعرف أنه يسهّل عليك تركه، ويفعله لأن العميل الذي يستطيع المغادرة ولا يغادر هو العميل الذي يبقى سنوات.
يتكلم عن الصيانة من البداية
المورّد الذي يذكر الصيانة السنوية وتكلفتها في أول عرض يفكر في عمر النظام. والذي لا يذكرها حتى تسأل إما لم يفكر أو يؤجّل محادثة غير مريحة إلى ما بعد الدفع.
أخطاء العميل التي تخرّب المشاريع
هذا القسم عن جهتك، وأكتبه لأن معظم المشاريع التي خرجت أسوأ من المتوقع لم يكن سببها المورّد.
عدم تسمية متخذ قرار
أكبر خطأ منفرد. المشروع الذي يحتاج موافقة ثلاثة أشخاص يجتمعون أسبوعياً سيتأخر ويغلى، ووقت الانتظار يدفعه العميل إما مباشرة أو في سعر أعلى. سمِّ شخصاً واحداً وأعطه صلاحية حقيقية.
تغيير الاتجاه في منتصف البناء
تغيير قرار جوهري بعد أن بُني عليه ليس تعديلاً بل إعادة عمل. والتغييرات الصغيرة طبيعية ومتوقعة، أما تغيير الشيء الذي يتبعه النظام أو من يستخدمه فمشروع آخر. وإن اضطررت لذلك فاعلم أنك تدفع مرتين، ولا تُلم المورّد على الفاتورة.
إخفاء القيود
الميزانية الحقيقية، والموعد الحقيقي وسببه، والتقنية التي أنت ملتزم بها، ومن يجب أن يوافق. المورّدون يصممون داخل القيود، والقيد المخفي يظهر متأخراً ومكلفاً. وإخفاء الميزانية تحديداً لا يعطيك سعراً أفضل بل يعطيك تصميماً أسوأ.
تجربة النظام في النهاية فقط
العميل الذي يقول سأراه عند الانتهاء يشتري مفاجأة. والملاحظة في الأسبوع الثالث رخيصة، ونفسها في الأسبوع الثاني عشر تعني إعادة عمل تدفع ثمنها إما مالاً أو تأخيراً.
تأجيل المحتوى
السبب الأول لتأخر الإطلاق في مشاريع المواقع. والنصوص والصور ليست خطوة أخيرة بل مُدخَل للتصميم، والموقع الذي يُبنى بنص مؤقت يُعاد ترتيبه عند وصول النص الحقيقي.
مقارنة العروض بالأرقام فقط
تكلّم عنه المقال بالتفصيل، وأعيده هنا لأنه خطأ العميل الأكثر تكلفة. العروض الثلاثة لمشاريع مختلفة، والجدول الذي تبنيه بنفسك يحوّلها إلى شيء قابل للمقارنة.
الاستعانة بمن لا يملك القرار للتفاوض
إرسال موظف للتفاوض على مشروع لا يملك صلاحية قراره يطيل كل شيء ويوصل معلومات ناقصة في الاتجاهين. وإن كان المالك أو المدير هو من سيقرر، فليكن هو من يحضر الاجتماع الأول على الأقل.
أول شهر بعد الإطلاق
الفترة التي تحدد هل سيُستخدم النظام، والأكثر غياباً عن الخطط والعروض.
في الأسبوع الأول يجد الاستخدام الحقيقي ما لم يجده الاختبار، لأن المستخدمين الحقيقيين يفعلون أشياء لم يفكر أحد في تجربتها. وتوقع قائمة. والنظام الذي لا ينتج قائمة في الأسبوع الأول نظام لا يستخدمه أحد.
فاطلب في العقد أن يكون المورّد منخرطاً خلال هذا الشهر وأن يكون ذلك مدفوعاً أصلاً لا مفاوضة جديدة. وأسبوعان من وقت المورّد محتجزان لما بعد الإطلاق أعلى عائد في المشروع كله، وهما أول ما يُحذف عندما تضيق الميزانية.
وخلال الشهر راقب أين يرجع الموظفون إلى الطريقة القديمة. وهذه الإشارة أدق من أي ملاحظة لفظية: إن كان أحدهم ما زال يحتفظ بجدول إكسل، فالنظام ينقصه شيء يحتاجه، ومعرفة ما هو أقيم من أي ميزة في خطة المرحلة الثانية.
وأوقف الطريقة القديمة بتاريخ محدد. التشغيل المتوازي المفتوح يبدو حصيفاً وهو السبب الأشهر لفشل التبني، لأن وجود طريقة احتياطية يعني أن أحداً لن يتعلم الجديدة. شغّل بالتوازي أسبوعين للتحقق ثم أغلق القديم فعلاً.
قائمة تحقق نهائية قبل التوقيع
اطبعها أو انسخها، ومرّ عليها قبل أن تدفع أول دفعة لأي مورّد.
- جرّبت نظاماً عاملاً بنفسه ودخلت إليه بحساب حقيقي
- اتصلت بعميل سابق واحد على الأقل وسألته عن التواصل عند المشاكل
- عندي عرض مكتوب فيه الأدوار والتكاملات بالاسم
- عندي قسم مكتوب بما ليس مشمولاً
- أعرف من يكتب الكود وهل يبقى على المشروع
- أعرف من يكتب المحتوى العربي
- ترحيل بياناتي الحالية بند بسعره، وسيُجرّب قبل التسليم
- الصلاحيات وسجل من فعل ماذا مشمولان لا مؤجلان
- الدفعات مرتبطة بمخرجات أستطيع اختبارها لا بتواريخ
- الكود سيكون في مستودع باسم شركتي من اليوم الأول
- النطاق والاستضافة وبوابة الدفع ستُسجَّل ببريد شركتي
- مدة ضمان الأعطال مكتوبة، وتعريف العطل مقابل الطلب الجديد مكتوب
- سعر الساعة أو اليوم للتغييرات متفق عليه مسبقاً
- تكلفة الصيانة السنوية معروفة وما تغطيه مكتوب
- الشهر الأول بعد الإطلاق مشمول ومدفوع
- أعرف ماذا سأسلّم لمطور آخر إن أردت الانتقال بعد سنتين
- سمّيت شخصاً واحداً عندي يملك القرار وهو متفرغ
البنود الأربعة الأخيرة هي التي يُغفلها معظم العملاء وهي الأرخص عند طلبها مسبقاً والأغلى عند تداركها لاحقاً. والبند الأخير يخصك أنت لا المورّد، وهو يحدد نتيجة المشروع أكثر من أي بند آخر في القائمة.
من أين تبدأ
إن كنت على وشك اختيار مورّد، فأقصر طريق إلى قرار جيد: اكتب مستند الصفحتين، وأضف أصعب ثلاث حالات عندك، وابنِ جدول المقارنة، وأرسله لثلاثة مورّدين واطلب من كل واحد تعبئته وكتابة الاستثناءات. وما سيصلك بعد ذلك يفرز نفسه.
وإن أردت أن أكون أحد الثلاثة، أرسل البريف وسأرد بتقدير، وبما أراه النسخة الأولى الصحيحة، وبما أوصي بتأجيله. وفي الحالات التي يكون الجواب فيها أن تشتري منصة جاهزة أو أن تحسّن ما عندك بدل بناء جديد، أقولها، لأن مشروعاً لا تحتاجه أسوأ لي منه لك.
وإن كنت في منتصف مشروع متعثر، فابدأ بالخطوات الثلاث في القسم المخصص لذلك: انقل التواصل إلى الكتابة، واطلب الكود والحسابات الآن، واقترح دفعات أصغر مرتبطة بمخرجات أقرب. الثلاثة ستخبرك بوضعك الحقيقي في أسبوع.
وأضيف ملاحظة أخيرة تخص الوقت. معظم العملاء يقضون أسبوعاً في جمع العروض ويوماً في قراءتها. والترتيب الصحيح معاكس: اقضِ يوماً في كتابة بريف واضح وأصعب ثلاث حالات، وأسبوعاً في قراءة ما يصلك ومحاورة من أرسله. البريف الواضح يخفض علاوة المخاطرة في كل عرض تستلمه، والمحاورة تكشف من فهم مشكلتك. والساعتان التي تنفقهما في الاتصال بعميل سابق أنفع من عشرة عروض إضافية.