إدارة مشاريع التيتانيك ومقارنتها بمشاريع البرمجيات

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

(عند الإشارة إلى السفن مجتمعةً سأكتفي بتسميتها الأولمبيات لأن الثلاث مجتمعةً كانت سفن خط الأولمبيك لشركة White Star Line. الشهرة الفردية واللاحقة للتيتانيك لا صلة لها هنا. كما أنني أتخذ هنا موقفًا مفاده أن المعلومات العامة المتعلقة بسفن الأولمبيك وتاريخها ومصيرها معلوماتٌ شائعة لدى القارئ ولن أتناولها مجددًا.)

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

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

أولًا، يجب أن نحدد أصحاب المصلحة في مشروع الأولمبيات. شركة White Star Lines ذاتها (الشركة الراعية والمستثمر الرئيسي) ومديرها جوزيف بروس إسماي، وشركة Harland-Wolff (بناة السفن المتعاقدون) ومصمموها الرئيسيون ألكساندر كارلايل وتوماس أندروز، وطواقم السفن وفي مقدمتهم القبطان إدوارد جون سميث، والحكومة البريطانية كما سنرى لاحقًا، والأهم من ذلك كله الركاب.

كما هو الحال في أي مجموعة من أصحاب المصلحة، هناك أدوار مختلفة تُمارَس. فشركة White Star من ناحية هي الراعي والمستثمر وستكون مشابهةً في مشروع برمجيات حديث لعميل راعٍ أو مدير أو قسم. وشركة Harland-Wolff كانت المصمّمين والبنّاءين وكانت أقرب ما تكون لـ“أعضاء الفريق” الهندسيين في فريق برمجيات حديث، أي المطورين أنفسهم. وطاقم السفن كان مسؤولًا عن التشغيل بعد اكتمال المشروع وكان مقارنًا لفريق العمليات التكنولوجي الذي يتولى تشغيل البرنامج النهائي بعد الاكتمال. أما الركاب فكانوا كالمستخدمين النهائيين اليوم، يأملون في الاستفادة من كل من المنتج الهندسي (السفينة أو البرنامج) والخدمة المبنية فوق ذلك المنتج (خدمة العبّارة أو الخدمات المُدارة لتكنولوجيا المعلومات.) (“أولمبيك”)

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

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

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

يمكننا أن نذهب خطوةً أبعد ونقارن خدمة عبّارة White Star عبر الأطلنطي بكثير من موردي البرمجيات كخدمة الحديثين كـMicrosoft Office 365 وSalesforce وG Suite. ففي هذه الحالات تمتلك الشركة المعنية فريق هندسة أو تطوير منتجات يبتكر المنتج الجوهري ثم فريقًا ثانيًا يأخذ ذلك المنتج الداخلي ويُشغّله كخدمة. يُعد هذا نموذجًا تجاريًا متناميًا الأهمية بصورة متزايدة في مجال تطوير البرمجيات حيث تكون الشركة ذاتها التي تُنشئ البرنامج هي المُشغّل النهائي له، لكن لعملاء خارجيين. ولعل صلة الأولمبيات بالبرمجيات الحديثة وتكنولوجيا المعلومات في تزايد لا في تناقص.

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

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

مقارنة ممتازة اليوم هي شركة British Airways وكيفية تعاملها مع كل رحلة تُشرف عليها وهي تعبر الأطلنطي. بوصفها الناقل الرئيسي للحركة الجوية فوق شمال الأطلنطي، المسار الذي كانت الأولمبيات مقرر لها اجتيازه، يجب على British Airways الحفاظ على سمعة التميز في السلامة. حتى في عام 2017، لا تزال الرحلة فوق شمال الأطلنطي رحلةً متقلبة ومعقدة.

قبل إقلاع أي رحلة لـBritish Airways، يجب على الطيارين والطاقم مراجعة دليل مهمة من ثلاثمئة صفحة يخبرهم بكل ما يجري بما في ذلك تفاصيل عن الطائرة والطاقم والطقس وما إلى ذلك. هذه العملية مكثفة لدرجة أن British Airways ترفض حتى الإقرار بأنها رحلة، بل تُسمي رسميًا كل رحلة فوق الأطلنطي “مهمة”؛ تحديدًا لترسيخ الإدراك لدى الجميع المشاركين بخطورة المخاطر في مثل هذا المسعى. يُدركون بوضوح أهمية تغيير طريقة تفكير الناس في رحلة كهذه، ويعلمون ما الذي يمكن أن يحدث حين يبدأ الناس في افتراض أن كل شخص آخر قد أتمّ عمله وأنهم يمكنهم التساهل في عملهم. لا يريدون لأحد أن يصبح لا مُبالًا أو يبدأ بالشعور بأن الرحلة، وإن أُنجزت عدة مرات يوميًا، باتت في أي وقت أمرًا اعتياديًا. (Winchester)

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

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

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

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

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

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

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

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

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

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

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

أنشأ بنّاؤو السفن، Harland and Wolff، نموذجًا بحجم خمسة عشر قدمًا للأولمبيك للاختبار وهو مفيد إلى حد ما، لكنه بالطبع أخفق في محاكاة الفعل الهيدرولوجي الذي ستُنتجه السفينة بحجمها الكامل لاحقًا وأخفق في التنبؤ ببعض الآثار الجانبية الأكثر خطورة لحجم السفينة الجديد عند اقترابها من سفن أخرى مما أدى إلى أول حادثة في المجموعة وما كاد يكون ثانيًا. يبدو أن البنّاءين قد بذلوا كل جهد للاختبار والتعلم في كل مرحلة متاحة لهم طوال عملية التصميم والبناء. (Kozak-Holland)

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

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

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

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

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

كانت شركة White Star Lines ببساطة “أكبر من أن تفشل” وأُبقيت طافيةً، إذا جاز التعبير، من قِبَل الحكومة قبل أن تُدمج قسرًا في شركة Cunard بعد سنوات. قد يكون هذا المفهوم، العلم بأن الحكومة لن تقبل مخاطر فشل الشركة، قد حُسب أو أُخذ في الاعتبار في ذلك الوقت، لكننا لا نعلم. ما نعلمه مع ذلك هو أن هذا يُؤخذ في الاعتبار اليوم في المشاريع الكبرى جدًا. ومثال على ذلك يجري حاليًا هو مقاتلة F-35 من تصنيع Lockheed Martin التي هي متجاوزة للميزانية بشكل دراماتيكي وفائتة لتاريخ تسليمها ولم يعد يُعتبر أنها ستكون مفيدة في مهمتها، لكنها أُسندت لسنوات من قبل رعاة حكوميين مختلفين يرون المشروع بالغ الأهمية، حتى في حالة الإخفاق في التسليم، للاقتصاد الوطني لدرجة لا تُجيز السماح للمشروع بالانهيار الكامل. مع تزايد شيوع هذه الظاهرة، من المرجح أن نشهد مشاريع أكثر تأخذها في الاعتبار في مراحل تحليل المخاطر. (Ellis)

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

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

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

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

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

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

المراجع والمصادر المستشهد بها:

Miller, Scott Alan.  Project Management of the RMS Titanic and the Olympic Ships, 2008.

Schwaber, Ken. Agile Project Management with Scrum. Redmond: Microsoft Press, 2003.

Kuntz, Tom. Titanic Disaster Hearings: The Official Transcripts of the 1912 Senate Investigation, The. New York: Pocket Books, 1998. Audio Edition via Audible.

Kozak-Holland, Mark. Lessons from History: Titanic Lessons for IT Projects. Toronto: Multi-Media Publications, 2005.

Brown, David G. “Titanic.” Professional Mariner: The Journal of the Maritime Industry, February 2007.

Esposito, Dino. “Cutting Edge – Don’t Gamble with UX—Use Wireframes.” MSDN Magazine, January 2016.

Sadur, James E. Home page. “Jim’s Titanic Website: Titanic History Timeline.” (2005): 13 February 2017.

Winchester, Simon. “Atlantic.” Harper Perennial, 2011.

Titanic-Titanic. “Olympic.” (Date Unknown): 15 February 2017.

Titanic-Titanic. “Guarantee Group.” (Date Unknown): 15 February 2017.

Brander, Roy. P. Eng. “The RMS Titanic and its Times: When Accountants Ruled the Waves – 69th Shock & Vibration Symposium, Elias Kline Memorial Lecture”. (1998): 16 February 2017.

Brander, Roy. P. Eng. “The Titanic Disaster: An Enduring Example of Money Management vs. Risk Management.” (1995): 16 February 2017.

Ellis, Sam. “This jet fighter is a disaster, but Congress keeps buying it.”. Vox, 30 January 2017.

ملاحظات إضافية:

Mark Kozak-Holland originally published his book in 2003 as a series of Gantthead articles on the Titanic:

Kozak-Holland, Mark. “IT Project Lessons from Titanic.” Gantthead.com the Online Community for IT Project Managers and later ProjectManagement.com (2003): 8 February 2017.

قراءة إضافية:

Kozak-Holland, Mark. Avoiding Project Disaster: Titanic Lessons for IT Executives. Toronto: Multi-Media Publications, 2006.

Kozak-Holland, Mark. On-line, On-time, On-budget: Titanic Lessons for the e-Business Executive. IBM Press, 2002.

US Senate and British Official Hearing and Inquiry Transcripts from 1912 at the Titanic Inquiry Project.