انطلقنا من أمثلة مواقع العقارات: هل نختار سكريبت جاهزًا أم برمجية مخصصة؟

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

إحنا في 2021 دفعنا 14.000 TL واشترينا سكريبت جاهز. أول سنة ما كان في مشاكل، بس لما عدد الإعلانات تعدى 500 صار وقت الفلترة يوصل 8 ثواني. ولأن الكود كان مشفّر ما قدر أي مهندس من برا يتدخل فيه، فاضطرينا نرمي النظام كله ونبني البنية التحتية من الصفر. غير ضياع الوقت، كلفنا زيادة 85.000 TL.

أغلب اللي تسميه الوكالات "برمجة خاصة" هو في الحقيقة قوالب مسحوبة من عملائها القدامى. يقولون لك نكتب الكود من الصفر ويطلبون 160.000 TL، بس في النهاية لوحة التحكم اللي يسلّمونها ما تختلف عن أي لوحة عادية. لا تحطوا هالميزانيات على الطاولة أبداً قبل ما توضّحوا بند بند في العقد مستودع الكود وبنية السيرفر.

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

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

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

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

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

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

لو كنت مكانك، لسلك هذا المسار.

ما كُتب هنا يطابق تماماً ما عشناه. تدوين الملاحظات لمدة أسبوعين يعطي نتائج أفضل من التخمين لمدة ستة أشهر.

أغلى شيء في النظام الموروث هو التبعيات غير المعروفة. صححوا لي إن أخطأت.

هناك نقطة لم أفهمها. الناس يدافعون عن العادات وليس العمليات. المقاومة تأتي من هناك.

بالتوفيق.

تم الحفظ. عندما نتخذ قرارات دون قياس، نعود لنفس النقطة دائماً.

يجب ربط جدول المدفوعات بمراحل العمل، وليس بالتقويم. مثبت بالتجربة.

ملخص سريع للجدد: كل من يستعجل في برمجية موقع عقارات يتعثر في نفس النقطة.

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

شكرًا، هذا هو الجواب الذي كنت أبحث عنه.

هناك فخ هنا، لا أريد المرور عليه دون ذكره. النظام يستمر بعد التسليم؛ الصيانة بند منفصل.

الناس يدافعون عن العادات وليس العمليات. المقاومة تأتي من هناك. لو كنت مكانك، لسلك هذا المسار.

كنت أفكر في نفس الشيء. الناس يدافعون عن العادات وليس العمليات. المقاومة تأتي من هناك.

صححوا لي إن أخطأت.

لدي اعتراض هنا. إذا لم ينص العقد على ملكية الكود، تفقد قوتك التفاوضية عند المغادرة.

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

نعم، الوضع في موضوع برمجية موقع عقارات هو بالضبط هكذا. وضع عملية لطلبات التغيير لا يبطئ العمل، بل يسرّعه.

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