كيف تكون المبادئ الثابتة مسؤولة عن نجاح المشروع؟

مقدمة
ربما لا تتسم أي صناعة أخرى بالتغيير بقدر ما تتسم به صناعة البرمجيات. وفي حين تمر كل شريحة من شرائح المجتمع، وخاصة الصناعة، بالتغيير، فإن وتيرة وحجم التغيير في صناعة البرمجيات تتقدم بخطوات كبيرة على كل الشرائح الأخرى.
إن حجم التغيير هذا قد يكون مزعجاً، فعندما يعتقد المرء أنه اكتشف سر النجاح، فإن التغيير يسحب البساط من تحت قدميه، ويصبح لزاماً عليه أن يبتكر صيغ النجاح من جديد. وفي مثل هذه السيناريوهات المضطربة، كيف يستجيب القادة للتغييرات وينجحون؟ وما هي وصفة النجاح التي يتبعونها؟
تتناول هذه المقالة كيف لا ينجرف القادة وراء التغييرات بل يستجيبون لها بذكاء وبطريقة مدروسة. فهم يمسكون بالثور من قرنه، إذا جاز التعبير، ويحكمون التغييرات بدلاً من أن يمليها عليهم التغيير. أحد أسرار نجاحهم هو أنهم يرسخون أنفسهم في مبادئ ثابتة لا تتغير ويستجيبون للتغييرات بناءً على هذه المبادئ الثابتة. ستساعدك أفضل شهادة PMP في إتقان جميع مبادئ وأساسيات إدارة المشاريع.
ما هي هذه المبادئ الثابتة لصناعة البرمجيات؟ تسلط هذه المقالة الضوء على خمسة مبادئ مؤثرة لا تتغير وأدت إلى نجاح مؤكد في تقديم البرمجيات.
ما هي المبادئ الثابتة؟
تحدث التغييرات في صناعة البرمجيات في جميع الجوانب تقريبًا، سواء كانت التكنولوجيا، أو منهجيات تطوير البرمجيات، أو نماذج دورة الحياة، أو نموذج الأعمال، أو أنواع العقود، يمكنك تسمية الجانب ويمكنك رؤية التغييرات.
على وجه التحديد، هناك 5 أنواع من التغييرات تؤثر بشكل كبير على نجاح مشروع البرمجيات وهي: تغييرات المتطلبات، وتغييرات نموذج دورة الحياة، وطرق التقدير التي تصبح قديمة، وطرق جدولة المشروع التي تصبح غير فعالة وظهور مخاطر جديدة.
إن كل تغيير يجلب معه تحديات جديدة، ومجرد احتضان التغيير قد يؤدي إلى خلق مشاكل جديدة في حين يحل بعض المشاكل القديمة. إن الشعارات مثل “لا تقاوم التغيير، بل احتضنه بدلاً من ذلك!” أو اعتبار الانفتاح على التغيير فضيلة لا تكفي للنجاح في خضم التغيير.
على سبيل المثال، عندما تصبح إحدى منهجيات التقدير قديمة بسبب تكنولوجيا جديدة، فماذا نعني بعدم مقاومة التغيير أو احتضان التغيير؟
إن الفرق تصبح ببساطة أكثر كفاءة من الناحية الفنية في التكنولوجيا الجديدة ولكنها تتراجع إلى طريقة تقدير خام وغير منظمة بدلاً من إنشاء طريقة تقدير جديدة. ومع ذلك، يستجيب القادة للتغييرات بشكل مختلف. فهم يتراجعون وينظرون إلى التغيير من مستوى أعلى، ويدركون أن المبدأ الأعلى لم يتغير ويعيدون تطبيق هذا المبدأ الأعلى على الموقف المتغير ويظلون فعالين.
بالعودة إلى مثال التقدير، عندما تصبح طريقة التقدير الحالية قديمة مع تغير التكنولوجيا، فإنهم ينظرون إلى الإجراء الفوقي لإنشاء طريقة التقدير نفسها (والتي لا تتغير) وإنشاء منهجية تقدير جديدة تعتمد على المنتج القابل للتسليم للتكنولوجيا الجديدة بدلاً من الرجوع إلى طرق التقدير الخام وغير المنظمة.
وبالتالي، فإنهم يحافظون على دقة التقدير ونجاح المشروع على الرغم من التغيير. وعلى هذا المنوال، فيما يلي المبادئ الخمسة التي لا تتغير في صناعة البرمجيات:
1) مبدأ تغيير المتطلبات: تشجيع التغييرات التي تحدث نتيجة لعوامل خارجية ولكن تثبيط أو القضاء على التغييرات التي تحدث نتيجة لعوامل داخلية. لا يتغير هذا المبدأ بغض النظر عن ظهور طرق جديدة لإدارة المتطلبات.
2) مبدأ نماذج دورة الحياة: لا تتغير المراحل الخمس لأي دورة حياة، ويجب عليك إنشاء نموذج دورة حياة خاص بك عندما تواجه موقفًا جديدًا. وعلى الرغم من ظهور طرق جديدة لدورة الحياة، فإن المراحل الخمس، وهي المتطلبات، ومواصفات الحل، وتصميم الحل، وتنفيذ الحل، واختبار الحل، لا تتغير. ويمكن للمرء دائمًا تصميم هذه المراحل الخمس لإنشاء دورة حياة جديدة.
3) مبدأ منهجيات التقدير: لا يتغير الإجراء المتبع في إنشاء منهجيات تقدير تعتمد على النتائج؛ بل يتم إنشاء طريقة تقدير جديدة تعتمد على النتائج عندما تتغير التكنولوجيا. تصبح منهجيات التقدير الراسخة قديمة عندما تتغير التكنولوجيا، ولكن الطريقة الأساسية لإنشاء منهجيات تقدير جديدة لا تتغير. وبالتالي، فإن إنشاء منهجية تقدير جديدة باستخدام هذه الطريقة الأساسية أمر ضروري للحفاظ على دقة التقدير.
4) مبدأ إدارة الجدول الزمني: تكون جداول المشروع فعّالة عندما يتم تنسيق تقسيم العمل مع نموذج دورة الحياة ويتضمن ما لا يقل عن 90% من المهام التي يقوم بها الفريق على أرض الواقع. ومع تغير نماذج دورة الحياة، تصبح الأساليب القديمة في وضع جداول المشروع غير فعّالة وتتخلى الفرق إما عن وضع جدول زمني فعّال أو وضع جداول زمنية غير مستخدمة. ومع ذلك، فإن تنسيق الجداول الزمنية مع نماذج دورة الحياة الجديدة يضمن فعالية الجداول الزمنية ويؤدي إلى الاستخدام الأمثل للموارد.
5) مبدأ إدارة المخاطر: من الضروري تحديد أولويات المخاطر التي تم تحديدها والتخطيط للتخفيف منها والطوارئ بغض النظر عن حجم وتعقيد المشروع. قد تختلف أنواع المخاطر مع تغير بيئة المشروع، لكن المبدأ الأساسي لتحديد أولويات المخاطر والتخفيف منها والتخطيط للطوارئ لا يتغير. مع تغير أنواع العقود ونماذج الأعمال ونماذج دورة الحياة والتقنيات، قد تتغير أنواع المخاطر، لكن المبدأ الأساسي لإدارة المخاطر لا يتغير ويجب تنفيذه بالكامل لزيادة فرص نجاح المشروع.
لماذا هذه المبادئ الخمسة فقط؟ ألا توجد مبادئ أخرى مهمة؟ حسنًا، قد يكون هناك العديد من المبادئ التي لا تتغير ولا بد من تطبيقها لتحقيق نجاح المشروع، ولكن هذه المبادئ الخمسة هي أهم المبادئ الحاسمة لنجاح المشروع والأكثر تحديًا أيضًا.
هناك مبادئ تتعلق بإدارة أصحاب المصلحة وتصميم المنتج والاختبار وإدارة الفريق وما إلى ذلك، ولكن التعامل مع كل هذه المبادئ ربما يكون مناسبًا لدليل مستخدم كامل حول مبدأ عدم التغيير وليس لمقال. ومن ثم فقد تم اختيار خمسة مبادئ مهمة للغاية للتوضيح في هذه المقالة.
نموذج المصنع هو نموذج لتقديم خدمات البرمجيات ودورة حياة تطوير البرمجيات هي جزء منه فقط، وتوضح هذه المقالة فقط جزء دورة الحياة من نموذج المصنع. وكما هو موضح في الرسم البياني 1، يتضمن نموذج المصنع إصدارات متكررة يتم جدولتها مسبقًا ويتم قبول المتطلبات حتى بعد التوقيع على وثيقة المتطلبات وبدء المراحل اللاحقة.
ومع ذلك، هناك تاريخ نهائي لتدفق المتطلبات وبعده يتم تخصيص المتطلبات الواردة للإصدار التالي. ونظرًا لأن الإصدارات أقصر ويتطلع العملاء إلى المستقبل، فعادةً ما يكونون على استعداد للانتظار حتى الإصدار التالي بدلاً من الضغط لإدراج المتطلبات في الإصدار الحالي.
هذا نموذج هجين، يتميز بخصائص Agile، وهي الإصدارات الأقصر والانفتاح لقبول المتطلبات حتى بعد الموافقة على RS. ولكنه يتميز أيضًا بخصائص تقليدية مثل الربط الضيق لمراحل دورة الحياة ضمن إصدار واحد وتجميد المتطلبات بعد فترة المتطلبات. هناك العديد من هذه النماذج الهجينة التي يستخدمها قادة الصناعة بفعالية.
3) مبدأ منهجيات التقدير:
لا يتغير الإجراء المستخدم لإنشاء منهجيات تقدير تعتمد على النتائج النهائية؛ بل يتم إنشاء طريقة تقدير جديدة تعتمد على النتائج النهائية عندما تتغير التكنولوجيا.
مع ظهور التقنيات الجديدة، فإن إحدى العواقب المترتبة على ذلك هي أن مناهج التقدير الراسخة أصبحت عتيقة. على سبيل المثال، عندما تم إنشاء طريقة تقدير نقاط الوظيفة لتطبيقات COBOL، أصبحت مستخدمة على نطاق واسع. كانت الوحدات التي يتم تقسيم وظائف التطبيق إليها، مثل “الملفات المنطقية الداخلية” و”أنواع السجلات” وما إلى ذلك، طبيعية لتطبيقات COBOL.
ومع ذلك، مع ظهور تطبيقات الخادم والعميل القائمة على واجهة المستخدم الرسومية، أصبح هذا النموذج ملائمًا للقوة وتراجع المقدرون إلى إجراء تقديرات أولية غير منظمة. تحدث هذه الظاهرة في كل مرة يحدث فيها تغيير في التكنولوجيا. تتبع الجماهير طريقة تقدير أولية غير منظمة ولكن القادة يطورون منهجيات جديدة بأنفسهم.
لقد أجرينا بحثًا حول دقة التقديرات من خلال مطالبة مجموعات من الأشخاص بتقدير نفس المواصفات باستخدام كل من الطريقة الخام والطرق المنظمة، وتُظهر النتائج اختلافات صارخة في الدقة. يوضح الرسم البياني 2 أدناه التباين بين التقديرات التي تم إجراؤها باستخدام منهجيات غير منظمة وشبه منظمة ورسمية (منظمة بالكامل):
رسم توضيحي للمبادئ الخمسة
1) مبدأ تغيير المتطلبات:
تشجيع التغييرات التي تحدث بسبب عوامل خارجية ولكن تثبيط أو القضاء على التغييرات التي تحدث بسبب عوامل داخلية.
حسنًا، تعد تغييرات المتطلبات أمرًا شائعًا في مشاريع البرمجيات وتختلف طريقة إدارة تغييرات المتطلبات وفقًا لمنهجيات تطوير البرمجيات ونماذج دورة الحياة. وفي حين أصرت مدرسة الفكر السابقة القائمة على CMMi على تحديد المتطلبات والموافقة عليها في وقت مبكر من دورة الحياة والحفاظ على التغييرات إلى الحد الأدنى لاحقًا، ذهبت مدرسة Agile إلى حد آخر قائلة إنها تشجع تغييرات المتطلبات وكلاهما على حق من وجهة نظرهما الخاصة.
في حين أن تغييرات الحد الأدنى من المتطلبات جيدة لاستقرار المشروع من حيث التوافق مع الخطة، فإن التشجيع على تغييرات المتطلبات يمكن أن يكون جيدًا لنجاح الأعمال حيث يمكن أن تكون سيناريوهات الأعمال ديناميكية ويجب أن تواكب تكنولوجيا المعلومات ديناميكيات الأعمال.
لذا، فمن الواضح أن هناك موجة Agile الآن وهي تغير الطريقة التي ننظر بها إلى تغييرات المتطلبات. ولنرى كيف يتفاعل الجمهور مع هذا التغيير وكيف يستجيب القادة. أولئك الذين “يحتضنون” التغيير ببساطة، ويتبعون منهجيات Agile على ظاهرها، ويقبلون أن المتطلبات يمكن أن تستمر في التغير وتتحمل العواقب.
على سبيل المثال، يدخل بعض موردي تكنولوجيا المعلومات في عقود بسعر ثابت لمشاريع Agile بناءً على فهم أولي لنطاق المشروع، وبسبب التوسع التدريجي في نطاق المشروع، يستمر العميل في تقديم المتطلبات في كل إصدار، مما يؤدي إلى تضخم نطاق المشروع إلى الحد الذي يجعل المشروع يتخطى الجدول الزمني ويتجاوز التكاليف بسهولة. وقد يؤدي هذا إلى خسائر للمورد، وإذا لم يتم التعامل معه بشكل جيد، فقد يؤدي إلى عدم رضا العميل وخسارة العمل أيضًا.
ومع ذلك، يتخذ قادة الفكر خطوة إلى الوراء وينظرون إلى سبب تغير المتطلبات ويخرجون باستجابات تضع في الاعتبار مصلحة العميل ومصلحتهم الشخصية. وقد بحث ليفينجويل وآخرون[1] في سبب تغير المتطلبات وصنفوا الأسباب إلى مجموعتين تسمى العوامل الداخلية والعوامل الخارجية.
تتعلق العوامل الداخلية بمن نستخرج منه المتطلبات، وكيف نستخرجها. وإذا لم نستخرج المتطلبات من أصحاب المصلحة المناسبين وإذا لم نستخدم تقنيات الاستنباط الصحيحة، فإن ذلك يؤدي إلى متطلبات غير واضحة وغير مكتملة مما يؤدي إلى تغييرات لاحقة. ويمكن تجنب مثل هذه التغييرات من خلال الاستخدام المناسب لتقنيات الاستنباط والتوثيق.
ولهذا السبب، يسرد BABoK (مجموعة المعرفة لتحليل الأعمال)[2] أكثر من 30 تقنية لاستنباط وتحليل وتوثيق المتطلبات. ولابد من استخدام هذه التقنيات بشكل فعال للقضاء على التغييرات التي تحدث بسبب عوامل داخلية.
من ناحية أخرى، ترتبط العوامل الخارجية بالتغيرات التي تطرأ على ظروف السوق، والمنافسة، ومتطلبات الامتثال القانوني. والتغييرات ضرورية لنجاح المشاريع التجارية ولا يمكن التنبؤ بها بسهولة.
إن تأجيل مثل هذه التغييرات قد يكون له تأثير سلبي خطير على أهداف العمل، وبالتالي يجب استيعاب مثل هذه التغييرات في الإصدار الحالي بأسرع ما يمكن. يتبع القادة الذين ينجحون في مشاريع Agile هذا المبدأ، ويصرون على الوضوح المسبق في النطاق على مستوى عالٍ ثم يسمحون بالتوسع التدريجي في النطاق على الإصدارات لمزيد من التفاصيل.
وهذا يعني أنهم يستخدمون مجموعة كبيرة من التقنيات المناسبة لاستنباط وتوثيق المتطلبات من أصحاب المصلحة المناسبين مقدمًا حتى يتمكنوا من الحصول على متطلبات واضحة وكاملة وبالتالي القضاء على التغييرات التي تحدث بسبب عوامل داخلية.
ومع ذلك، فإنهم لن يصروا على “تجميد” المتطلبات، بل سيسمحون بالتطوير التدريجي لتفاصيل هذه المتطلبات لاستيعاب التغييرات التي تحدث بسبب عوامل خارجية. وبالتالي، فإنهم يحققون المصلحتين التقدير والتخطيط المناسبين للتسليم الفعّال والفعالية من حيث التكلفة من خلال الوضوح المسبق واكتمال المتطلبات رفيعة المستوى، وكذلك ضمان التوافق السريع مع سيناريو العمل المتغير من خلال التطوير التدريجي للمتطلبات التفصيلية.
2) مبدأ نماذج دورة الحياة:
المراحل الخمس لأي دورة حياة لا تتغير ويجب عليك إنشاء نموذج دورة الحياة الخاص بك عندما تواجه موقفًا جديدًا.
تستمر نماذج دورة الحياة في الظهور وفي كل مرة يظهر فيها نموذج جديد لدورة الحياة، فإنه يؤثر على جداول المشروع وتقارير الاتصال وخطط زيادة وخفض الفريق وخطط الجودة بشكل أساسي. ومع ذلك، وكما يشير بعض خبراء الصناعة مثل كارل ويجرز [3]، فإن نماذج دورة الحياة هذه لا تختلف كثيرًا وقد ينجرف الجمهور وراء الضجيج المحيط بنموذج دورة الحياة الجديد ولكن القادة يستجيبون بشكل مختلف.
يدرك القادة أن كل نموذج جديد لدورة الحياة يحمل معه حلاً لبعض المشاكل القائمة، ولكنه يحمل معه أيضاً مجموعة جديدة من المشاكل. ومن ثم، فإنهم يقبلون النماذج الجديدة بشكل انتقائي وغالباً ما يتكيفون مع نموذج دورة الحياة الجديد من خلال تصميمه بما يتناسب مع مصلحتهم. ويمكنهم القيام بهذا التصميم على أساس فهم أن المراحل الخمس لنموذج دورة الحياة لا تتغير.
ظهرت نماذج تطوير البرمجيات تحت العديد من الأسماء بدءًا من الشلال، وV، وRAD، والأساليب التطورية، والتكرارية، والتزايدية، واللولبية، وRUP وأخيرًا الأساليب الرشيقة بالكامل مثل Scrum وXP وKanban. تحدد نماذج دورة الحياة بشكل أساسي كيفية نسج المراحل الخمس مثل المتطلبات والمواصفات الوظيفية والتصميم والتنفيذ والاختبار. إن حقيقة أن أي مشروع تطوير، وليس فقط مشاريع البرمجيات، ينطوي على جميع المراحل الخمس هي مبدأ ثابت كما هو موضح أدناه:
تعريف المشكلة:
يمكن تسمية هذه المرحلة بالتناوب باسم تحديد النطاق أو تحديد المتطلبات وما إلى ذلك، وهي تحدد احتياجات العميل التي ينبغي ترجمتها إلى منتجات قابلة للتسليم. أي مشروع موجود لأن هناك احتياجات العميل وبالتالي لا يمكن الاستغناء عن هذه المرحلة.
مواصفات الحل:
تُعرف هذه المرحلة أيضًا باسم مرحلة المواصفات الوظيفية أو مرحلة التحليل أو مرحلة تحديد الميزات وما إلى ذلك، وهي تحدد الحل المقترح لتلبية احتياجات العميل. أي مشروع هو تنفيذ لحل لتلبية احتياجات العميل ولا يمكن الاستغناء عن تعريف الحل.
تصميم الحل:
تُعرف هذه المرحلة أيضًا باسم التصميم أو التصميم منخفض المستوى وما إلى ذلك، وهي تحدد “كيف” سيتم تنفيذ الحل. أي حل غير تافه يحتاج إلى تصميم، وبهذا المعنى، فإن هذه المرحلة لا غنى عنها أيضًا.
تنفيذ الحل:
تُسمى أيضًا مرحلة التنفيذ أو مرحلة البناء أو مرحلة الترميز، حيث يتم تنفيذ الحل المصمم في هذه المرحلة. وهي المرحلة التي تنتج المنتجات النهائية الفعلية وبالتالي فهي لا غنى عنها.
الاختبار:
تتضمن هذه المرحلة أنواعًا متعددة من الاختبارات وتختبر الحل المطبق وفقًا للمتطلبات المحددة. لا يمكن إصدار أي منتج دون اختباره وهذه المرحلة لا غنى عنها أيضًا.
وبما أن هذه المراحل لا غنى عنها، فلنلق نظرة على كيفية نسجها في نماذج دورة الحياة المختلفة. يتضمن نموذج الشلال تسلسلًا محكمًا بين المراحل الخمس. أي أنه لا يمكنك تخطي أي مرحلة والعمل على مرحلة دون إكمال المرحلة السابقة. يقسم النموذج التدريجي النطاق إلى زيادات متعددة ولكنه يحافظ على التسلسل المحكم بين المراحل داخل كل زيادة.
ومع ذلك، لا يقسم Scrum النطاق إلى عدة مراحل تسمى “Sprints” فحسب، بل يزيل أيضًا التسلسل الضيق بين المراحل الخمس. على سبيل المثال، يمكن للمرء كتابة التعليمات البرمجية لميزة ما دون تصميم معتمد لها.
وبالتالي، يوفر نموذج Agile مزيدًا من الحرية والمرونة للمطورين مقارنة بالنموذج التدريجي أو نموذج الشلال الكامل. وفي حين تبدو هذه الحرية جذابة، إلا أنه إذا لم يكن الفريق متعدد المهارات وذوي الخبرة الكافية، فقد يحتوي المنتج الناتج على أكواد غير مترابطة ويصبح غير قابل للصيانة. أيضًا، إذا لم يكن الفريق متعدد المهارات، فقد لا يؤدي نموذج Agile إلى الاستخدام الأمثل للموارد.
في ظل هذه الخلفية، وبينما تتبنى الجماهير نموذج Agile بشكل ميكانيكي وتتحمل عواقب الفوضى وقلة الاستخدام (مع تحقيق بعض الفوائد أيضًا)، فإن القادة يستجيبون بشكل مختلف. فقد يتبنون Agile بشكل كامل إذا كان ذلك مناسبًا، ولكن إذا لم يكن الأمر كذلك، فإنهم يخلقون نماذج هجينة مصممة خصيصًا.
لقد طبقت أغلب المشاريع العملاقة الناجحة التي عُرضت في مؤتمرات معهد إدارة المشاريع (PMI) نماذج هجينة تضمنت عناصر من المرونة ولكنها فرضت أيضًا قدرًا معينًا من الانضباط. وتسرد النسخة الأخيرة من دليل إدارة المشاريع (PMBoK) نماذج دورة الحياة الهجينة باعتبارها اتجاهًا في إدارة المشاريع [4].
ولتوضيح نموذج هجين، يمكن اعتبار نموذج المصنع الذي كان أحد النماذج الهجينة العديدة التي تم تنفيذها في شركة Wipro Technologies ونشر كدراسة حالة في جامعة هارفارد [5] مثالاً.
نموذج المصنع هو نموذج لتقديم خدمات البرمجيات ودورة حياة تطوير البرمجيات هي جزء منه فقط، وتوضح هذه المقالة فقط جزء دورة الحياة من نموذج المصنع. وكما هو موضح في الرسم البياني 1، يتضمن نموذج المصنع إصدارات متكررة يتم جدولتها مسبقًا ويتم قبول المتطلبات حتى بعد التوقيع على وثيقة المتطلبات وبدء المراحل اللاحقة.
ومع ذلك، هناك تاريخ نهائي لتدفق المتطلبات وبعده يتم تخصيص المتطلبات الواردة للإصدار التالي. ونظرًا لأن الإصدارات أقصر ويتطلع العملاء إلى المستقبل، فعادةً ما يكونون على استعداد للانتظار حتى الإصدار التالي بدلاً من الضغط لإدراج المتطلبات في الإصدار الحالي.
هذا نموذج هجين، يتميز بخصائص Agile، وهي الإصدارات الأقصر والانفتاح لقبول المتطلبات حتى بعد الموافقة على RS. ولكنه يتميز أيضًا بخصائص تقليدية مثل الربط الضيق لمراحل دورة الحياة ضمن إصدار واحد وتجميد المتطلبات بعد فترة المتطلبات. هناك العديد من هذه النماذج الهجينة التي يستخدمها قادة الصناعة بفعالية.
3) مبدأ منهجيات التقدير:
لا يتغير الإجراء المستخدم لإنشاء منهجيات تقدير تعتمد على النتائج النهائية؛ بل يتم إنشاء طريقة تقدير جديدة تعتمد على النتائج النهائية عندما تتغير التكنولوجيا.
مع ظهور التقنيات الجديدة، فإن إحدى العواقب المترتبة على ذلك هي أن مناهج التقدير الراسخة أصبحت عتيقة. على سبيل المثال، عندما تم إنشاء طريقة تقدير نقاط الوظيفة لتطبيقات COBOL، أصبحت مستخدمة على نطاق واسع. كانت الوحدات التي يتم تقسيم وظائف التطبيق إليها، مثل “الملفات المنطقية الداخلية” و”أنواع السجلات” وما إلى ذلك، طبيعية لتطبيقات COBOL.
ومع ذلك، مع ظهور تطبيقات الخادم والعميل القائمة على واجهة المستخدم الرسومية، أصبح هذا النموذج ملائمًا للقوة وتراجع المقدرون إلى إجراء تقديرات أولية غير منظمة. تحدث هذه الظاهرة في كل مرة يحدث فيها تغيير في التكنولوجيا. تتبع الجماهير طريقة تقدير أولية غير منظمة ولكن القادة يطورون منهجيات جديدة بأنفسهم.
لقد أجرينا بحثًا حول دقة التقديرات من خلال مطالبة مجموعات من الأشخاص بتقدير نفس المواصفات باستخدام كل من الطريقة الخام والطرق المنظمة، وتُظهر النتائج اختلافات صارخة في الدقة. يوضح الرسم البياني 2 أدناه التباين بين التقديرات التي تم إجراؤها باستخدام منهجيات غير منظمة وشبه منظمة ورسمية (منظمة بالكامل):
نظرًا لأن الرسم البياني أعلاه يقارن نتائج التقدير التي أجراها نفس الأشخاص على نفس المواصفات مع كون طريقة التقدير هي المتغير الوحيد، فيمكننا أن نستنتج أن طريقة التقدير تلعب دورًا رئيسيًا في تحديد دقة التقديرات. يؤدي استخدام طرق التقدير شبه المنظمة والمنظمة بالكامل إلى تحسين دقة التقدير بشكل كبير.
ومن ثم، يستخدم القادة الإجراء الثابت لتصميم أساليب تقدير جديدة والتوصل إلى أسلوب تقدير جديد بأنفسهم عندما تتغير التكنولوجيا. ويتم هذا الإجراء على النحو التالي:
تحديد مقياس حجم التطبيق.
تحديد الوحدات التي تنقسم إليها المواصفات.
تحديد العوامل التي تؤثر على تصنيف تعقيد الوحدات المقسمة
تحديد الصيغة للوصول إلى الحجم بناءً على عدد وتعقيد الوحدات المقسمة
تحديد طريقة تحديد الجهد من الحجم باستخدام معايير الإنتاجية.
يشرح هذا المؤلف في إحدى الأوراق السابقة [6] كيف يمكن مقارنة المنهجيات المختلفة على طول خطوط الإجراء المشترك المحدد أعلاه ويقارن نقاط الوظيفة ونقاط حالة الاستخدام ونقاط MVC وطرق WBS المنظمة في تنسيق مشترك كما هو موضح في الرسم البياني 3 أدناه:
لقد ابتكر المؤلف وزملاؤه منهجين لتقدير النتائج المفتوحة القائمة على التسليم، وهما نقاط MVC [6] ونقاط الواجهة [7]، بهدف تقدير تطبيقات الويب ومشاريع تكامل تطبيقات المؤسسات. كما رأينا العديد من المنهجيات غير المنشورة لتقدير تطبيقات مستودعات البيانات وتطبيقات تخطيط موارد المؤسسات المستخدمة داخليًا في مؤسسات تكنولوجيا المعلومات الرائدة، واستخدام هذه الطرق يحسن بشكل كبير من دقة التقدير.
4) مبدأ إدارة الجدول الزمني:
تصبح جداول المشروع فعالة عندما يتم تنسيق تقسيم العمل مع نموذج دورة الحياة ويتضمن ما لا يقل عن 90% من المهام التي يقوم بها الفريق على الأرض.
عندما تتغير نماذج دورة الحياة، تتغير أيضًا طريقة تقسيم العمل. وقد تم توضيح ذلك في مقالات سابقة لهذا المؤلف [8][9] أن محاذاة هيكل تقسيم العمل مع نموذج دورة الحياة هو عامل حاسم يحدد ما إذا كان سيتم استخدام الجدول الزمني في المشروع أم لا. عندما تتغير نماذج دورة الحياة ولا تعمل الطرق القديمة لهيكل تقسيم العمل، تتخلى الجماهير عن ممارسات الجدولة ولكن القادة يغيرون هيكل تقسيم العمل ويستمرون في ممارسات الجدولة لضمان الاستخدام الأمثل للموارد.
على وجه التحديد، أدى وصول منهجيات Agile إلى جعل الطرق القديمة لهيكل تقسيم العمل عتيقة. وكما هو موضح في الرسم البياني 4، تنظر طرق Agile إلى تقدم المشروع من حيث الميزات القابلة للاستخدام بالكامل بينما تنظر الطرق التقليدية إلى تقدم المشروع من حيث العمل المنجز.
وبناءً على ذلك، يتغير هيكل تقسيم العمل أيضًا. ويرغب هيكل تقسيم العمل للمشروع التقليدي في الجدول 1 أدناه
كما هو واضح في الجدول 1، يتم تنظيم هيكل تقسيم العمل على طول مراحل دورة الحياة. ونظرًا لأن هذا لا يعمل مع نماذج Agile، فإن الاتجاه الشائع هو التخلي عن الجداول الزمنية وتنفيذ العمل بطريقة مخصصة. ومع ذلك، يقوم القادة بنقل هيكل تقسيم العمل ليتوافق مع وجهة نظر Agile لتقدم المشروع كما هو موضح في الجدول 2 ويستمرون في استخدام جداول المشروع لتحسين استخدام الموارد.
هل أنت مستعد للتفوق في إدارة المشاريع؟ يوفر لك برنامج التدريب على PRINCE2 Practitioner عبر الإنترنت طريقة مرنة ومريحة لتحقيق الإتقان. سجل اليوم واتخذ الخطوة التالية في حياتك المهنية!
“الطول = “402 بكسل؛”>
5) مبدأ إدارة المخاطر:
من الضروري تحديد أولويات المخاطر التي تم تحديدها والتخطيط للتخفيف منها والتدابير الطارئة بغض النظر عن حجم وتعقيد المشروع.
مع حدوث التغييرات في كافة جوانب تنفيذ المشروع، تظهر مخاطر جديدة للغاية، والميل الشائع هو عدم تحديد المخاطر، بل التمسك بالمخاطر القديمة وتحمل العواقب. ومع ذلك، يتمسك القادة بالمبدأ الثابت المتمثل في تجنب المخاطر.