هل طناك طيار على متن الطائرة؟ مستند تقني

هام: تمت ترجمة هذه المقالة ترجمة آلية، راجع إقرار إخلاء المسؤولية. يرجى الاطلاع على النسخة الإنجليزية من هذه المقالة. هنا للرجوع إليها.

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

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

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

إثبات المبدأ

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

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

والرد عادة هو الصمت وتعبير مرتبك.

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

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

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

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

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

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

  1. تحدث مع عميل حقيقي، موجود بالفعل.

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

  2. دعنا نثبت ذلك.

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

  3. يمكنك الحصول على بعض التدريب في هذا.

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

أين يوجد الإصدار التجريبي عندما تحتاج له؟

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

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

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

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

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

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

الخاتمة

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

  1. أولاً، تأكد من أن أهدافك واضحة.

  2. بعد ذلك، تأكد من فهم الإدارة لما تحتاجه ودعمها لك فيما يتعلق بالأموال والموارد والوقت لتحقيق تلك الأهداف.

  3. وأخيراً، تأكد من وضع خطة للمشروع وإدارته مثل أي مشروع آخر في قائمة مشاريعك.

حول الكاتب

كريس فانديرلويس هو رئيس ومؤسس شركة HMS Software ومركزها كندا، مونتريال، وهي شريك معتمد من قِبل Microsoft. حاز على شهادة البكالوريوس في الاقتصاد من جامعة ماكجيل، ويتمتع بخبرة تزيد عن 30 عاماً في مجال أتمتة أنظمة التحكم في المشاريع. وهو عضو منذ فترة طويلة في معهد إدارة المشاريع (PMI)، وساعد في تأسيس فصول مونتريال وتورونتو وكيبيك لمجموعة مستخدمي المشاريع من Microsoft‏ (MPUG). من المنشورات التي كتب كريس مقالات فيها Fortune وHeavy Construction News ومجلة Computing Canada وPMI’s PMNetwork وProject Times. يدرّس كريس إدارة المشاريع المتقدمة في جامعة ماكجيل ويتحدث الكثير من الأحيان في أنشطة جمعية إدارة المشاريع في جميع أنحاء أمريكا الشمالية وحول العالم. شركة HMS Software هي ناشر نظام ضبط الوقت الموجه نحو المشاريع TimeControl، وهي شريك في حلول مشاريع Microsoft منذ عام 1995.

يمكن الاتصال بكريس فانديرلويس عبر البريد الإلكتروني على العنوان: chris.vandersluis@hms.ca

إذا كنت ترغب في قراءة المزيد من المقالات ذات الصلة بإدارة مشاريع المؤسسة بقلم كريس فانديرلويس، فراجع مدونته EPM Guidance على (http://www.epmguidance.com/?page_id=39).

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

هل كانت المعلومات مفيدة؟

رائع! هل لديك أي ملاحظات أخرى؟

كيف يمكننا تحسين ذلك؟

نشكرك على ملاحظاتك!

×