ماذا أفعل الآن؟ التخطيط لتغييرات التصميم

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

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

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

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

أمرٌ آخر كثيرًا ما أراه يُغفَل هو أن الحل الأمثل وقت اتخاذه قد لا يكون أمثلًا لو أُعيد اتخاذ القرار ذاته اليوم. ولا يعني ذلك بأي حال من الأحوال قصورًا في التصميم الأصلي، غير أنني رأيت كثيرًا من الناس يتعاملون معه وكأنه كذلك. أكثر الحالات شيوعًا التي أصادف فيها هذا السلوك هي النفور من استخدام RAID 5 في تصاميم التخزين الحديثة، في حين يُفضَّل RAID 6 وRAID 10 لأسباب وجيهة. لكن هذا النفور من RAID 5، الذي بات شائعًا منذ عام 2009 تقريبًا، لم يكن موجودًا دائمًا؛ فمن منتصف التسعينيات وحتى نهاية العقد الأول من الألفية الثالثة لم يكن RAID 5 مجرد خيار مقبول، بل كان في أحيان كثيرة الحل الأمثل لاحتياجات الأعمال والمتطلبات التقنية (إذ تصاعد النفور منه تدريجيًا لا فجأةً). بيد أن كثيرين ينظرون إلى RAID 5 اليوم باعتباره خيارًا رديئًا بصورة مفهومة، ثم يسقطون هذا الحكم على أنظمة صُمِّمت ونُفِّذت منذ زمن بعيد، أحيانًا منذ نحو عقدين. وهذا لا معنى له ولا أساس له إلا الاستجابة العاطفية. فكون RAID 5 الخيارَ الأمثل لسيناريو معين عام 2002 لا يعني البتة أنه سيظل الأمثل عام 2015. وبالمثل، فإن رداءة RAID 5 كخيار عام 2015 لا تنتقص أو تلغي حقيقة أنه كان خيارًا ممتازًا في كثير من الحالات قبل سنوات.

سُئلت مرارًا عمّا ينبغي فعله حين تُتّخذ قرارات تصميمية أقل من المثالية. «ماذا أفعل الآن؟»

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

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

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

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

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

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

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

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

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

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

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

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