هل يستحق إنشاء نظام تذاكر دعم فني مفتوح المصدر لفريق من 8 أشخاص العناء أم سيكون وجع رأس؟

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

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

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

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

معكم كل الحق في التخلص من صندوق البريد المشترك، فإدارة الإيميلات مع 8 أشخاص فوضى عارمة. لكن هناك باقات أساسية للأنظمة الجاهزة، والخطط التي تكلف 12-15 EUR للشخص ستفي بالغرض تماماً. خصصوا ميزانية 100-120 EUR شهرياً لـ 8 أشخاص وريحوا رؤوسكم.

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

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

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

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

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

بالتأكيد. وإذا أردت إضافة شيء: عند اتخاذ القرار، اكتب أسوأ سيناريو أيضًا، وليس الأفضل فقط.

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

شكرًا لكتابة هذا.

عانيت من نفس الشيء.

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

أغلى شيء في النظام الموروث هو التبعيات غير المعروفة. إذا كتبت النتيجة هنا، فستفيد الآخرين أيضاً.

أخذت ملاحظة، شكرًا لك. أكثر ما أهدر وقتنا كان عدم وضوح من يتخذ القرار.

محاولة فعل هذا بمفردك هي أغلى الطرق.

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

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

لدي اعتراض هنا. يجب ربط جدول المدفوعات بمراحل العمل، وليس بالتقويم.

هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.

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

كل عبارة "سننظر في ذلك لاحقًا" في الاجتماع تعني عملًا غير مُسعّر. هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.

عشنا تقريباً نفس التجربة العام الماضي. كلما كان التراجع عن القرار أصعب، كان يجب اتخاذه ببطء أكبر.

مثبت بالتجربة.