
التسليم شيء والانتهاء شيء آخر
هناك لحظة يعرفها كل من اشترى نظاماً مخصصاً: يُسلَّم النظام، ويتصافح الفريقان، وتُلتقط صورة للشاشة الأولى وهي تعمل، ثم يأتي صباح اليوم التالي فيجلس موظفون حقيقيون أمام الشاشة ويدخلون بيانات حقيقية لأول مرة. في تلك اللحظة بالذات يتوقف البرنامج عن كونه عرضاً تجريبياً أنيقاً ويصير أداة عمل، ومن هنا تبدأ الأسئلة التي لم تخطر ببال أحد في أي اجتماع سابق، مثل لماذا لا يقبل الحقل رقم الهاتف بهذا الشكل، ولماذا يعطي تقرير الأمس مجموعاً يختلف عن الدفتر القديم.
وهذه الأسئلة طبيعية تماماً، بل إن لها شكلاً يمكن التخطيط له قبل وقوعه. فالشهر الأول بعد التشغيل الفعلي يأتي عادة بـ 25 إلى 40 رسالة دعم، ثم يهبط الرقم إلى نحو 16 رسالة في الشهر الثاني، وإلى 9 تقريباً في الشهر الثالث، ليستقر من الشهر الرابع عند 4 إلى 8 رسائل شهرياً حين يكون الموظفون قد دُرِّبوا كما ينبغي. أي أن شهراً أول صاخباً ليس دليلاً على فشل المشروع، بل هو الشكل المعتاد لفترة الاستقرار، والمقلق حقاً هو العكس تماماً: صمت تام في الشهر الأول، لأنه في أغلب الحالات يعني أن أحداً لم يبدأ استخدام النظام أصلاً.
ولا بد أن نتفق على معنى الضمان قبل أن نمضي، لأن أكثر سوء الفهم بين العميل والمورد يبدأ من هذه النقطة. أغلب عقود البناء تتضمن مدة ضمان تتراوح بين 30 و 90 يوماً، تُصلَّح خلالها مجاناً الأشياء التي بُنيت خطأً، أي ما لا يعمل كما نص عليه الاتفاق المكتوب. أما ما لا يغطيه الضمان فثلاثة أنواع يحسن قولها بوضوح من اليوم الأول: الطلبات الجديدة التي لم تكن ضمن النطاق، وأخطاء الإدخال التي يرتكبها الموظفون، والتغييرات التي تفرضها عليك جهة خارجية مثل بوابة دفع تغير طريقة الربط. هذه الثلاثة عمل جديد، ودفع ثمنها ليس استغلالاً، بل هو الوصف الصحيح لما جرى.
ويبقى السؤال الذي كُتب هذا المقال كله من أجله: بعد انتهاء الضمان، لا بد أن تكون هناك جهة مسؤولة عن هذا النظام كل شهر، ولسنوات. من تكون تلك الجهة، وكم تكلف؟ نحن في لينكي سوفت نسلّم الأنظمة ثم نبقى نشغّلها بعد التسليم، ولذلك سنكتب الأرقام هنا كما نراها في عقودنا وفواتيرنا، لا كما تُكتب عادة في صفحات التسويق.
أربعة أنواع من العمل لا تتوقف أبداً
كلمة الصيانة واسعة إلى حد أن من يشتريها لا يعرف ما الذي اشتراه، ولذلك نفضل تقسيمها إلى أربعة أعمال بلغة عادية: إصلاح ما تعطل، ومجاراة العالم الخارجي، وتحسين ما يطلبه الناس، ومنع المشكلات قبل أن تصل.
ولكل نوع مثال يعرفه صاحب متجر أو مديرة عيادة من دون شرح: تقرير يومي يطبع مجموعاً خاطئاً هو إصلاح عطل، وبوابة دفع تعلن إيقاف طريقة الربط القديمة هي مجاراة للعالم الخارجي، وموظفة الاستقبال التي تطلب حقلاً ثانياً لرقم هاتف بديل هي تحسين، وقاعدة بيانات كبرت بهدوء حتى صار البحث فيها بطيئاً هي وقاية لم تُنفَّذ في وقتها.
وهنا المفاجأة التي تقلب حسبة الميزانية عند أغلب العملاء: إصلاح الأعطال لا يشغل سوى ثلث الشهر تقريباً. فالشهر النموذجي في عقد صيانة ينقسم إلى نحو 40 بالمئة لإبقاء النظام يعمل، أي التحديثات والمراقبة والنسخ الاحتياطي والترقيعات الأمنية، و 30 بالمئة للإصلاحات وأسئلة المستخدمين، و 20 بالمئة لتحسينات صغيرة، و 10 بالمئة للتقارير والتخطيط. أي أن الجزء الأكبر هو مجاراة ووقاية، وهو بالضبط العمل الذي لا يلاحظه أحد حين يُنجَز على أكمل وجه.
ولهذا التقسيم أثر مباشر على المفاوضة نفسها، لأن العميل الذي يظن أن الصيانة تعني الأخطاء سيستنتج منطقياً أن نظاماً مبنياً جيداً لا يحتاج إليها تقريباً، ثم يفاجأ بفاتورة السنة الأولى ويشعر أنه دفع مرتين عن الشيء نفسه. ولو عرف من البداية أن ثلثي العمل ليسا أعطالاً أصلاً، لصار الحديث عن الرقم أهدأ على الطرفين.
العالم يتغير وإن لم تلمس سطراً واحداً
هذه هي الفكرة المركزية في المقال كله: البرمجيات تتآكل وهي واقفة في مكانها، لأن كل ما حولها يتحرك. المتصفحات تصدر تحديثاً كل أربعة أسابيع تقريباً، وأنظمة تشغيل الهواتف تصدر إصداراً رئيسياً مرة كل سنة، فما كان يعمل بلا شكوى في مارس قد يظهر مكسوراً في نوفمبر من دون أن يكتب أحد سطراً واحداً في برنامجك.
وأقسى مثال على ذلك قاعدة المتاجر التي تباغت كل عميل تقريباً: متجرا التطبيقات يرفعان الحد الأدنى لمتطلبات البناء مرة كل سنة، ونتيجة ذلك أن تطبيقاً تُرك بلا لمس من 12 إلى 18 شهراً يحتاج عادة إلى 20 إلى 60 ساعة عمل قبل أن يُقبل نشره من جديد، حتى لو لم تتغير فيه شاشة واحدة. ومن يملك تطبيقاً للهواتف ينبغي أن يعتبر هذه الساعات بنداً سنوياً ثابتاً في الميزانية لا مفاجأة تُناقَش كل مرة.
أما المحرك الذي يعمل عليه نظامك، وأقصد به البرنامج الأساسي الذي تُنفَّذ فوقه شيفرة موقعك، فله عمر دعم يتراوح بين سنتين وثلاث، وبعدها يتوقف مطوروه عن إصدار الترقيعات الأمنية له. لذلك خطط لترقية محرك واحدة كل سنتين إلى ثلاث بكلفة تقارب 15 إلى 60 ساعة بحسب حجم النظام، وتنفيذها في موعدها المجدول أرخص كثيراً من تنفيذها في حالة ذعر بعد إعلان ثغرة، لأن الفارق بين الحالتين هو الفارق بين عمل مخطط له وعمل ليلي بلا وقت كافٍ للاختبار.
ثم هناك الخدمات الخارجية التي يعتمد عليها نظامك، وأشهرها بوابات الدفع وشركات الشحن ومزودو الرسائل النصية. هؤلاء يوقفون طرق الربط القديمة من وقت لآخر، ويرسلون عادة إشعاراً قبل 6 إلى 12 شهراً على البريد الإلكتروني المسجل في الحساب، وهذه الجملة الأخيرة هي بيت القصيد: لا بد من وجود شخص يقرأ ذلك البريد فعلاً ويتصرف بناءً عليه، وإلا اكتشفت الأمر يوم يتوقف الدفع في وقت الذروة.
وأرخص بند في القائمة كلها هو أشدها قسوة عند الإهمال، وأعني شهادة الأمان التي تجعل عنوان موقعك يظهر بجانبه قفل. الشهادة المجانية تدوم 90 يوماً وتجدد نفسها تلقائياً، والمدفوعة تدوم سنة في العادة، والتحقق من التجديد لا يستغرق سوى دقائق. ومع ذلك فإن شهادة واحدة منتهية تُخرج الموقع كله من الخدمة أمام كل زائر في اللحظة نفسها، بلا تدرج ولا إنذار مسبق يراه العميل.
كم تكلف الصيانة فعلاً، والحسبة مكتوبة أمامك
القاعدة التقريبية المستقرة في السوق أن الرعاية السنوية تكلف من 15 إلى 25 بالمئة من كلفة البناء الأصلية. ولأن النسب وحدها لا تُدفع منها فواتير، فلنُجرِ الحسبة كاملة: نظام كلف بناؤه 30,000 دولار يحتاج عادة من 4,500 إلى 7,500 دولار سنوياً، أي ما يعادل 375 إلى 625 دولاراً في الشهر، وهو رقم يستطيع أي صاحب عمل أن يقارنه براتب موظف أو بإيجار مساحة صغيرة ويقرر.
وموقعك داخل هذا النطاق تحدده أربعة أسئلة بسيطة: كم خدمة خارجية يتحدث إليها نظامك، وهل تمر أموال من خلاله، وهل له تطبيق هواتف، وكم شخصاً يستخدمه يومياً. فنظام داخلي لا يتصل بشيء ويستخدمه عشرة موظفين يقع قرب حافة 15 بالمئة، بينما متجر يقبل الدفع وله تطبيق ويخدم آلاف الزوار يقع قرب 25 بالمئة، وقد يتجاوزها قليلاً في مواسم الذروة.
وإلى جانب وقت البشر هناك تكاليف تشغيل صريحة يجب ألا تختفي في أي عرض سعر: الاستضافة من 40 إلى 200 دولار شهرياً لنظام شركة صغيرة، والنطاق من 10 إلى 40 دولاراً سنوياً، وحساب المطور لدى آبل 99 دولاراً سنوياً، وحساب جوجل 25 دولاراً تُدفع مرة واحدة فقط. وبعد توزيع البنود السنوية على شهور السنة، تقع كلفة الآلات وحدها بين 50 و 215 دولاراً شهرياً قبل أن يعمل إنسان دقيقة واحدة.
وأنفع ما تفعله بهذه النسب أن تحولها إلى ساعات تستطيع السؤال عنها بالاسم، فاشتراك بقيمة 500 دولار شهرياً يشتري في أغلب الأسواق ما بين 4 و 10 ساعات من وقت مهني ماهر، لا أكثر. لذلك اسأل أي مورد سؤالاً واحداً مباشراً: كم ساعة يتضمنها سعرك شهرياً، وماذا يحدث للساعات غير المستعملة في نهاية الشهر؟ الإجابة عن هذين السؤالين تكشف جودة العرض أكثر من كل ما كُتب فيه من وصف.
من يبقي النظام حياً: أربعة خيارات بلا مجاملة
الخيار الأول: الفريق الذي بناه، باشتراك شهري. وهو أسرع الخيارات لأن الفريق يعرف النظام من الداخل ولا يحتاج أسابيع ليفهم ما بناه بيده، فيصير زمن الإصلاح ساعات بدل أيام. أما ضعفه الصريح فهو أنك مرتبط بمورد واحد، ولذلك اشترط في العقد أن تستطيع الخروج ومعك كل شيء، أي الشيفرة والوثائق والحسابات، حتى لا يتحول انصرافك يوماً إلى مفاوضة.
الخيار الثاني: مبرمج مستقل تحت الطلب. يكلف عادة نحو 12,000 دولار سنوياً مقابل توافر حقيقي لا مجاملة، وسعر ساعته أقل مما تدفعه لشركة، لكن المخاطرة أوضح كذلك: شخص واحد يمرض ويسافر وقد ينتقل إلى عمل آخر، ومعرفة النظام كلها تخرج معه من الباب في اليوم نفسه. وهو خيار جيد لنظام غير حرج، بشرط أن تكون وثائقك مكتوبة بحيث يستطيع غيره أن يكمل من حيث توقف.
الخيار الثالث: موظف داخلي. الكلفة الحقيقية لمبرمج متوسط الخبرة تقع في كثير من الأسواق بين 35,000 و 90,000 دولار سنوياً بعد احتساب كل شيء لا الراتب وحده، وهذا منطقي فقط حين يتغير النظام أسبوعياً ويكون في قلب الطريقة التي تكسب بها الشركة مالها. أما لتعديلين في الشهر فهو إنفاق كبير على طاقة معطلة أغلب الوقت.
الخيار الرابع: لا شيء، ثم الاتصال بأحد عند العطل. ولنقلها بصراحة: هذا خيار حقيقي ومقبول لأداة داخلية صغيرة يستخدمها بضعة أشخاص ولا يتوقف العمل بتوقفها يوماً أو يومين. ولنقلها بالصراحة نفسها: هو خيار سيئ لأي نظام يقبض أموالاً، لأن عملية الإنقاذ تكلف دائماً أكثر من سنة الرعاية التي وُفِّرت، ويُضاف إليها ثمن الأيام التي كان فيها الباب مغلقاً في وجه العملاء.
وحين يكون النظام تطبيق ويب إدارياً يعمل عليه الفريق كل يوم، نرى عملياً أن الاشتراك مع الفريق الباني في السنة الأولى ثم إعادة التقييم في نهايتها هو الترتيب الأقل كلفة والأقل مخاطرة، لأن السنة الأولى وحدها هي التي تكشف حجم العمل الحقيقي، وبعدها تستطيع أن تقرر بأرقام لا بتوقعات.
حزمة التسليم التي يجب أن تملكها قبل الفاتورة الأخيرة
هذه قائمة تصلح للطباعة ووضعها أمامك حتى توقيع الاستلام، وكل بند فيها يُسلَّم لك مكتوباً لا شفهياً:
- النطاق وسجلاته مسجلة في حساب باسم شركتك، لا في حساب المصمم أو الوكالة.
- حساب الاستضافة أو السحابة مملوك للشركة ومدفوع من بطاقتها.
- الشيفرة البرمجية في مستودع باسم شركتك، والمستودع هو المخزن الإلكتروني الذي تُحفظ فيه الشيفرة مع سجل بكل تعديل جرى عليها منذ أول يوم.
- بيانات الدخول إلى قاعدة البيانات محفوظة في مدير كلمات مرور للشركة.
- قائمة مكتوبة بكل رخصة مدفوعة، مع تاريخ تجديدها والحساب الذي تُدفع منه.
والبند الذي يسقط منه أكثر أصحاب الأعمال الصغيرة هو الحسابات الخارجية، أي الدفع والبريد والرسائل النصية والخرائط، فكل واحد منها يجب أن يُسجَّل ببريد إلكتروني باسم الشركة لا ببريد شخصي لمبرمج مهما كانت الثقة به. والسبب أن هذه الحسابات تحوي أموالك وبيانات عملائك، ولأن استعادة حساب دفع مسجل باسم شخص غادر قد تستغرق أسابيع لا ساعات.
واطلب كذلك وثيقتين مكتوبتين بلغة بسيطة: كيف يُنشر تغيير على النظام الحي خطوة بخطوة، وماذا تفعل حين يتوقف الموقع في التاسعة مساءً. والمعيار الذي نحكم به على الوثيقتين واحد ولا ثاني له: هل يستطيع محترف غريب لم ير النظام من قبل أن ينفذهما كما هما مكتوبتان؟ إن كانت الإجابة لا، فما بين يديك ملاحظات لا وثائق.
والحسبة التي تجعل هذا البند غير قابل للتفاوض بسيطة إلى حد المفاجأة: إعداد حزمة تسليم كاملة يستغرق من 8 إلى 16 ساعة في نهاية المشروع، بينما فريق جديد يستلم نظاماً بلا حزمة يحتاج من 40 إلى 120 ساعة لقراءة النظام وفهمه قبل أن يجرؤ على تغيير سطر واحد بأمان. ولمن أراد التوسع، لدينا مواد أخرى عن التسليم وما ينبغي أن يتضمنه العقد قبل توقيعه.
النسخ الاحتياطي والأمان اشتراك، لا عملية شراء تنتهي
خلف كل سياسة نسخ احتياطي سؤالان اثنان فقط، ولا حاجة لأي مصطلح تقني لفهمهما: كم من العمل تحتمل خسارته، وكم من الوقت تحتمل أن تكون مغلقاً؟ فإن كانت إجابتك يوم عمل واحد وساعتين، فأنت تحتاج نسخة يومية تلقائية إلى جانب نسخة محفوظة خارج الخادم الرئيسي، لأن النسخة التي تعيش على الجهاز نفسه تختفي معه في اللحظة التي تحتاجها فيها.
والقاعدة الأهم في هذا الباب أن النسخة الاحتياطية ليست نسخة احتياطية حتى يستعيدها أحد فعلاً، ولذلك نفذ استعادة حقيقية كل ثلاثة أشهر واحسب زمنها بالساعة، فاستعادة قاعدة بيانات أصغر من 5 غيغابايت تستغرق عادة من 10 إلى 40 دقيقة. وفي الأنظمة التي نستلمها من فرق أخرى نجد أن نحو واحدة من كل أربع مهام نسخ احتياطي غير مكتملة أو متوقفة بصمت منذ شهور، ولهذا صار اختبار الاستعادة الفصلي عندنا أهم من جدول النسخ نفسه.
أما الشيفرة الخارجية فتُشرح بلغة صاحب المتجر هكذا: تطبيق الويب العادي يحمل بداخله من 300 إلى 1,200 قطعة برمجية جاهزة كتبها آخرون، بعد حساب القطع غير المباشرة التي تجرها القطع الأولى معها. وعلى مدى سنة واحدة، توقع أن يحتاج 5 إلى 20 منها تحديثاً أمنياً، من بينها 1 إلى 3 يجب ترقيعها خلال 24 إلى 72 ساعة من الإعلان عنها لأنها تمس ثغرة يمكن استغلالها فعلاً من الخارج.
ويبقى الجانب البشري، وهو مصدر أغلب الاختراقات الحقيقية لا الشيفرة: فعّل تسجيل الدخول بخطوتين لكل من يملك صلاحيات إدارية، واحذف حساب الموظف يوم مغادرته لا بعد شهر من رحيله، وراجع قائمة من يملك صلاحية الإدارة مرتين في السنة. وهذه الثلاثة مجانية تقريباً وتغلق باباً أوسع مما تغلقه أدوات الأمن السيبراني المكلفة، ولمن أراد تفصيلاً أوسع لدينا مقالات في الأمان وحده.
أزمنة الاستجابة: ما تطلبه وما لا يستحق أن تدفع ثمنه
قبل الحديث عن الأرقام لا بد من تعريف درجات الخطورة بلغة العميل لا بلغة الفريق التقني، وأوضح تعريف هو بالأمثلة: توقف صفحة الدفع حالة حرجة، وتقرير يومي يعرض عموداً خاطئاً حالة كبيرة، وزر مائل قليلاً عن مكانه حالة بسيطة. ومن دون هذا التصنيف مكتوباً في العقد سيصير كل شيء عاجلاً في عين العميل وكل شيء عادياً في عين المورد، وهو خلاف لا ينتهي.
والأهداف الواقعية التي تصلح لأن تُكتب في اتفاق: ساعة واحدة لأي شيء يوقف المال، وأربع ساعات أو اليوم نفسه للمشكلة الكبيرة، ويومان إلى ثلاثة أيام عمل للعمل الشكلي. ولاحظ أن هذه أزمنة استجابة لا أزمنة إصلاح، والفرق جوهري: الاستجابة تعني أن إنساناً حقيقياً بدأ العمل وأعطاك تقديراً للوقت، أما زمن الإصلاح فيعتمد على المشكلة نفسها ولا يستطيع أحد أن يعد به مسبقاً.
وهنا نقول ما لا يقوله عادة من يبيع الصيانة: أغلب القراء لا ينبغي أن يشتروا تغطية على مدار الساعة. فهي تكلف عادة 2.5 إلى 3 أضعاف تغطية ساعات العمل، والسبب منطقي وبسيط، وهو أنها تحتاج مناوبة من ثلاثة أشخاص على الأقل حتى تكون حقيقية لا مجرد وعد في ورقة. وعيادة تغلق أبوابها في السادسة مساءً محقة تماماً إن اشترت تغطية ساعات العمل ورقم طوارئ لنهاية الأسبوع، ثم وفرت الفارق لتحسينات ينتفع بها موظفوها كل يوم.
وأخيراً، الشيئان اللذان يجعلان الدعم يعمل فعلاً ليسا في السعر أصلاً: شخص واحد مُسمّى من كل طرف، وقناة واحدة متفق عليها. فالدعم الموزع على محادثات شخصية وثلاثة أرقام هواتف ينتهي دائماً إلى أن أحداً ليس مسؤولاً، ثم يضيع طلب مهم بين رسالتين ويُكتشف بعد أسبوعين حين يسأل عنه أحد بالصدفة.
التغييرات الصغيرة التي تقرر بقاء النظام مستخدَماً
هذه النقطة وحدها تحدد العائد على المشروع كله: البرنامج الذي يقاوم الطريقة التي يعمل بها الموظفون يُهجر بهدوء، فيعودون إلى الجداول والورق ويبقى النظام يعمل بلا مستخدمين. والنظام الذي لا يستخدمه أحد يكلف في الاستضافة تماماً ما يكلفه نظام يحبه الجميع، فالفارق كله في العائد لا في الفاتورة.
وشكل السنة الأولى واضح مما نراه مرة بعد مرة: توقع من 30 إلى 60 طلب تغيير، لكن 10 إلى 15 منها فقط هي التي تغير فعلاً مقدار استخدام النظام، والباقي تفضيلات شخصية أو تحسينات لطيفة لا أثر لها في الأرقام. ولهذا فإن ميزانية تغيير فصلية من 10 إلى 20 ساعة تكفي لأغلب ما يهم، بشرط أن تُنفق على الطلبات الصحيحة لا على أعلى الأصوات في الاجتماع.
وحتى تميز الصحيح من غيره، قِس ثلاثة أرقام يفهمها أي مدير من دون شرح: كم موظفاً يسجل الدخول أسبوعياً، وكم سجلاً يُنشأ في النظام، وكم يستغرق إنجاز مهمة شائعة اليوم مقارنة بالطريقة القديمة. فإن نزل عدد الداخلين شهراً بعد شهر، فالمشكلة ليست في طلبات التغيير بل في شيء أساسي لم يلاحظه أحد بعد.
ونصيحة عملية أثبتت جدواها عندنا مرة بعد مرة: جلسة تدريب مُعادة في الأسبوع السادس، ودليل من صفحتين يُسلَّم لكل موظف جديد. فأغلب تذاكر الدعم في الشهر الثاني ليست أعطالاً أصلاً، بل أشخاص شُرح لهم مرة واحدة يوم التسليم ثم نسوا، وساعة تدريب واحدة تعالج عدداً منها دفعة واحدة بكلفة أقل بكثير من الرد عليها رسالة رسالة. ويمكنك الاطلاع في دراسات الحالة على أنظمة تحسنت بعد الإطلاق أكثر مما تحسنت قبله.
حين يكون الخيار الأرخص هو الصحيح
لأداة داخلية مستقرة يستخدمها خمسة أشخاص ولا تمر بها أموال، فإن خطة خفيفة لإبقاء الأضواء مضاءة بنحو 3,600 دولار سنوياً هي الشراء الصحيح، وأي شيء أكبر منها هدر صريح. وهذه الخطة تعني عملياً أربعة أشياء لا خامس لها: مراقبة، ونسخاً احتياطياً مختبراً، وترقيعات أمنية، وعدداً صغيراً من الساعات للطوارئ.
ومن الحكمة كذلك أن تستبدل جزءاً من نظامك المخصص بمنتج جاهز حين يكون الجاهز أفضل فعلاً، كالمحاسبة أو التسويق بالبريد الإلكتروني، لأن كل وظيفة تخرج من نظامك المخصص تنزل من فاتورة صيانته إلى الأبد. والقاعدة التي نكررها على عملائنا: ابنِ خصيصاً ما يميز عملك عن غيرك، واشترِ جاهزاً ما يفعله الجميع بالطريقة نفسها.
وفي المقابل هناك مواضع يكون فيها التوفير خسارة صافية: كل ما يحمل إيراداً، وكل ما يخزن بيانات خاضعة لتنظيم مثل سجلات المرضى أو بيانات الدفع، وكل ما يراه عميلك بعينه. هذه تستحق تغطية كاملة من دون تردد، لأن كلفة يوم سيئ واحد فيها تتجاوز كلفة سنة صيانة كاملة، والحساب لا يحتاج أكثر من ضرب متوسط مبيعات اليوم في عدد أيام التوقف المحتملة.
واحذر رد الفعل المكلف: حين يبدو النظام قديماً أو ثقيلاً، فإن تحسيناً بـ 20 إلى 40 ساعة يتفوق عادة على إعادة بناء كاملة، ولا يوضع خيار إعادة البناء على الطاولة إلا حين تتجاوز كلفة تشغيل النظام القديم كلفة بناء نظام جديد. ونحن في لينكي سوفت نقول للعميل صراحة حين يكون الخيار الأصغر هو الصحيح، لأن مشروعاً ينجح بميزانية أقل أفضل لنا من مشروع كبير يندم صاحبه عليه بعد سنة.
سنتك الأولى، وما تضعه في العقد
الإيقاع الذي نوصي به بسيط ويمكن نسخه كما هو: تغطية مكثفة في الأسابيع الأربعة الأولى، ثم جلسة تدريب مُعادة ودفعة الإصلاحات الأولى في الشهر الثاني، ثم أول اختبار استعادة حقيقي وأول تحسينات صغيرة في الشهر الثالث، ثم مراجعة للقطع البرمجية الخارجية ولسرعة النظام في الشهر السادس، ثم حديث عن خارطة الطريق في الشهر التاسع، وأخيراً في الشهر الثاني عشر تجديد للعقد مع فحص لإصدارات المحرك ونظام التشغيل ومدة الدعم المتبقية لكل منهما.
وخمسة بنود تستحق الإصرار عليها في العقد مهما كان حجمه:
- شخص مُسمّى من كل طرف، باسمه ورقمه، حتى لا يكون العنوان صندوق بريد عاماً.
- أهداف استجابة مكتوبة حسب درجة الخطورة، مع تعريف كل درجة بمثال من عملك أنت.
- تقرير شهري قصير يذكر ما أُنجز والساعات التي استُهلكت، صفحة واحدة تكفي.
- وضوح مصير الساعات غير المستعملة، هل تُرحَّل إلى الشهر التالي أم تسقط، والاثنان مقبولان إن كُتبا.
- بند خروج يتضمن تسليماً كاملاً خلال مدة محددة، فوجوده وحده يجعل العلاقة أصح ما دامت قائمة.
وخلاصة المقال في جملة واحدة: السؤال لم يكن يوماً هل يحتاج نظامك إلى رعاية، فهو يحتاجها حتماً، وإنما من المسؤول عنها وكم قررت أنت أن تنفق على تلك المسؤولية. والفرق بين شركة تدفع 400 دولار شهرياً بهدوء وأخرى تدفع فاتورة إنقاذ عاجلة بسعر الطوارئ وأبوابها مغلقة ليس فرقاً في الحظ، بل في قرار اتُّخذ أو أُجِّل قبل عام.
وإن أردت أن نراجع معك ما تملكه اليوم ونقول لك بصراحة أي الخيارات الأربعة يناسبك، فأخبرنا بحجم نظامك وعدد مستخدميه وما إذا كانت تمر به مدفوعات عبر صفحة التواصل، وسنرد عليك بنطاق ساعات وسعر تقريبي من دون إلزام. وإن أحببت القراءة أكثر قبل ذلك، فأمامك مقالات أخرى عن الصيانة وما بعد الإطلاق.