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

نعمل في تجارة التغليف بالجملة في دوسلدورف، وعددنا 15 شخصاً. أنفقنا قبل عامين 42.000 EUR على برنامج تكامل مماثل. قبل ذلك، كان ثلاثة من موظفينا يقضون ساعتين يومياً في مطابقة الفواتير وقوائم التعبئة يدوياً. بعد تشغيل البرنامج، كسبنا حوالي 30 ساعة عمل تشغيلية أسبوعياً، وانخفضت أخطاء تلبية الطلبات إلى الصفر تقريباً. في حالتنا، استرد الاستثمار تكلفته خلال 14 شهراً.

كتابة البرمجيات من الصفر أكثر ربحية دائماً للوكالات من تكييف نظام جاهز. الخطر الأكبر ليس عدم اكتمال المشروع، بل انقطاع دعم الوكالة بعد انتهائه أو رفع سعر ساعة الصيانة إلى مستوى 150 EUR. هل استنفدتم جميع ميزات API وهياكل webhook في البرامج القياسية؟ تأكدوا من استحالة ربط أدوات SaaS الحديثة المتاحة في السوق ببعضها قبل اللجوء إلى الأكواد المخصصة.

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

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

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

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

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

صحيح.

حدث معنا هذا. الكود بدون وثائق تثبيت لا يُعتبر ملكك حتى لو كان بين يديك.

أتمنى أن يفيدك هذا.

قضيت وقتًا طويلاً في هذا المجال. تسير الأمور على ما يرام في الأشهر الثلاثة الأولى، وتظهر المشاكل في الشهر الرابع.

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

لدي سؤال، ولا أريد الخروج عن صلب الموضوع. لا تترددوا في السؤال، فالسائل يدفع ثمناً أقل دائماً.

الطريق الذي يبدو رخيصاً غالباً ما يكلف غالياً لاحقاً. يجب فتح بيانات الوصول باسم المؤسسة، وليس بحسابات شخصية.

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

أتابع الموضوع.

تم الحفظ.

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

إذا كان هناك من يفعلها بطريقة أخرى، فأنا فضولي لمعرفة ذلك.

مررت بهذا الطريق، دعني أشرح. كلما كان التراجع عن القرار أصعب، كان يجب اتخاذه ببطء أكبر.

القرار المتسرع يصبح قراراً يُصحح بعد ستة أشهر. لو كنت مكانك، لسلك هذا المسار.

ظهرت ثلاث وجهات نظر مختلفة، وكلها تكمل بعضها. الناس يدافعون عن العادات وليس العمليات. المقاومة تأتي من هناك.

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

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

هذا كل شيء، أرجو المعذرة إذا أطالت.