مبنيّ بالإعداد، لا بالبرمجة

غريزة كتابة الكود

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

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

لماذا يهم هذا التمييز

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

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

ماذا يعني هذا لميزانية التخصيص

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

إذا كان فريقك ينظر إلى ميزانية تخصيص ويفترض أن ذلك يعني توظيف مطورين، فهذا الافتراض يستحق الاختبار قبل قبوله كأمر واقع. تحدث في الأمر مع فريق Majorbird.