لا يمكنك افتراض ذلك!

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

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

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

ومن أكثر الطرق شيوعًا لتحقيق ذلك عدم دعم أي نظام تشغيل حديث، مما يُهمّش فعليًا برنامج المورد ذاته (على سبيل المثال، كأن يقتصر الدعم اليوم على Windows XP والإصدارات الأقدم فحسب). ومثال آخر هو دعم المنتجات غير المرخصة للغرض المستهدف (كاشتراط استخدام منتج مثل Windows 10 كخادم). ومن أكثر الحالات شيوعًا تحريم الافتراض.

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

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

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

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

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

أليس ذلك مهمًا؟

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

هذا ما نُسمّيه في الأوساط الهندسية "عدم تطابق الاستيعاب"، بين احتياجاتنا (أنظمة إنتاجية) والطريقة التي يبدو أن المورد يتعامل بها مع هذه الأنظمة (أنظمة هواة أو ترفيهية). إذا كنا بحاجة إلى الاعتماد على هذا المنتج في أعمالنا، فنحن بحاجة إلى مورد متفهّم لمتطلبات الأعمال ولديه عقلية إنتاجية. إذا كان المنتج غير موجّه للأعمال أو غير جاهز للأعمال، يجب أن ندرك ذلك. وعلينا التساؤل لماذا نشعر بأنه ينبغي لنا استخدام خدمة في بيئة إنتاجية نعتمد عليها ونحتاج إلى دعمها، إذا لم تكن مُصمَّمة للاستخدام بهذه الطريقة.

هل يُقدَّم الدعم؟ هل يجري الاختبار؟

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

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

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

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

 

هل لا يزال قيد التطوير؟

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

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

 

كيف يمكن تقديم الدعم إذا لم تكن المنصة مدعومة؟

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

هل تنقص مهارات ومعارف الصناعة؟

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

المشكلة الكبرى

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

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

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