في عالم التقنيات الحديثة لتقنية المعلومات ، عندما تبلغ العديد من التطبيقات من Google Play و Appstore يوميًا عن التحديثات ، فإن الاستماع من فريق المشروع لتنفيذ نظام تخطيط موارد المؤسسات "سيستغرق المشروع من 9 (متفائل) إلى 12 شهرًا (واقعيًا)" أمر شائع جدًا. وعلاوة على ذلك ، هناك مشاريع أكثر تعقيدا. في واحدة من الشركات التي عمل فيها صديقي ، استمرت فقط مرحلة إنشاء وتوقيع تصميم العمليات لمدة 6 أشهر. تبين أن حجم وثيقة التصميم مثير للإعجاب ، ويمكن أن ينقذ في شكل مطبوع حياة محارب من الصين القديمة (يقولون إنهم استخدموا الورق كمواد لدروعهم). لقد مرت أيام الصين القديمة ، ولكن هذه المجموعة من الورق تواصل اليوم إنقاذها ، إن لم يكن الحياة ، ثم على الأقل النظم العصبية للاستشاريين في مرحلة تشغيل النظام. لكن ما لا يحفظه مستند التصميم هو حدوث تحول في توقيت إطلاق المشروع والمشاكل المتعلقة بجودة النظام بحلول وقت التشغيل التجاري. دعنا نحاول معرفة سبب حدوث ذلك وما إذا كان ذلك ممكنًا بطريقة مختلفة.
تخيل أنك تطلب إصلاح شقتك الجديدة. قبل بدء العمل ، يطلب منك فريق المقاول توقيع وثيقة نصية ، غالبًا بدون رسوم توضيحية ، حول كيفية اعتناء شقتك بالإصلاح ، بما في ذلك جميع التفاصيل: المقابس والمفاتيح والأثاث وما إلى ذلك. يحذر قائد الفريق من أن التغييرات أثناء مرحلة القبول تكون أكثر احتمالًا المجموع سيؤدي إلى تكاليف إضافية. لهذا السبب ، فأنت تتعامل مع المهمة بمسؤولية وتنفق الكثير من الوقت وتوقع المستند في النهاية. حسنًا ، لنفترض أنك تغادر لمدة ستة أشهر من البلاد. وثق تمامًا في فريق التنفيذ للقيام بالإصلاح بنفسك دون أي رقابة أو مراقبة من جانبك. بعد ستة أشهر ، عد إلى المنزل وشاهد أن الشقة الجاهزة لا تلبي تمامًا توقعاتك. ثم تطلب من فريق المشروع إعادة بعض التفاصيل ، على سبيل المثال ، قم بتحريك المقابس بالقرب من الثلاجة. يقول فريق المشروع إن نقل المقابس سيكون مكلفًا للغاية ويستغرق الكثير من الوقت ، لأنه يتعين عليك تجويف الحائط ، وهناك بلاط ، وما إلى ذلك. تذهب إلى غرفة النوم ، وتقوم بتشغيل مكيف الهواء المثبت بالفعل ، وتفهم أنه سينفجر في الليل مباشرةً . اطلب من الفريق تحريكه ، لكن تحصل على نفس الإجابة كما في المقابس. ومع ذلك ، هذه مسألة مبدئية بالنسبة لك وأنت تقول أنك لن تبدأ في العيش في الشقة حتى يكون مكيف الهواء هو المكان الذي تحتاج إليه ، لأنه في شقتك الحالية هو المكان الذي تحتاجه بالضبط ، ولا ترى النقطة في التحرك ، إذا كانت سوف تتفاقم راحة حياتك اليومية. نتيجة لذلك ، يمكنك الاتصال في شقة بعد 3 أشهر من الخطة الأصلية مع زيادة في الميزانية بنسبة 20 ٪.
المشكلة الرئيسية ، في رأيي ، هي أننا نحاول التنبؤ وإصلاح جميع التفاصيل في مرحلة التصميم قبل بدء العمل. تأخرت مرحلة التصميم ، لأنه نادراً ما يستطيع مستخدمو الأعمال تكريس أنفسهم تمامًا للمشروع ، وعليهم التعامل مع العمليات التجارية اليومية. بحلول وقت توقيع التصميم ، تراكمت لديهم تراكم واسع النطاق إلى حد ما من المهام المعلقة وأنها لم تعد جاهزة للمشاركة في المشروع حتى مرحلة الاختبار. لقد أمضوا بالفعل الكثير من الوقت في التخطيط لجميع التفاصيل ويرغبون في رؤية نظام مكتمل ومُضبط. ومع ذلك ، فإن النتيجة النهائية لا تلبي التوقعات. أحد أسباب ذلك موضح أدناه:
في شركتنا ، نجرب بنجاح تجربة جديدة لمشروعات لتنفيذ وتكرار أنظمة ERP. علاوة على ذلك ، في مشاريع النسخ المتماثل ، يسمح لك النهج بإكمال المشروع بشكل أسرع من الخطة المعتادة بمراحل متتالية من التصميم والتطوير والاختبار (ويعرف أيضًا باسم Waterfall).
لقد انتقلنا من هذا:
إلى هذا:
نسمي هذا النهج مختلطًا (Waterfall - Agile) لأننا نستخدم كل من عناصر Agile (أعمال الركض) و Waterfall (تبدأ العملية التجارية فقط بعد الانتهاء من المشروع بأكمله). يرجع التسارع إلى حقيقة أننا ، أولاً ، نعمل مع مستخدمي الأعمال بالتوازي (العمل على تصميم الأعمال المستقبلية والتخصيص ، وتطوير التطبيقات الحالية) ، وثانياً ، نحن "ننقل المآخذ" أقرب إلى الثلاجة المستقبلية قبل وضع البلاط ومجموعة المطبخ تجميعها. كلما زاد حجم المشروع ، زاد الوقت ومكاسب الجودة مقارنةً بنهج Waterfall الكلاسيكي.
عينة المشروع في المريخ باستخدام نهج المخلوطة
الخصائص الرئيسية للمشروع:
- 5½ فترات (22 أسبوعًا) من البداية إلى الإطلاق
- فريق مشروع كامل - 40 شخصًا (من مستخدمي الأعمال ومستشاري تقنية المعلومات والمطورين)
- 4 فرق وظيفية ضمن فريق المشروع - المالية ، المشتريات ، اللوجستيات والمبيعات ، إدارة مراقبة الجودة
- 4 دورات من اختبار الأعمال مع 93 ٪ من البرامج النصية الناجحة في المحاولة الأولى. 5 ورش عمل بدوام كامل
في مرحلة ما قبل المشروع ، قدرنا أننا سنفعل المشروع في 30 أسبوعًا. في الواقع ، باستخدام نهج Agile ، فعلنا كل شيء في 22 أسبوعًا. لمدة 4 أشهر من التشغيل بعد الإطلاق ، تلقينا طلب تغيير واحد من الشركة.
عوامل النجاح الرئيسية
فرق تكنولوجيا المعلومات الداخلية. في أقرب وقت ممكن ، قم بالترتيب مع فرق تقنية المعلومات الرئيسية التي ستشارك في التنفيذ. حشد الدعم الإداري للدخول في حوار مع مقاول خارجي.
المقاول الخارجي. يجب أن يشمل فريق المشروع التابع للمقاول مهنيين مدركين تمامًا للنظام نفسه ومبادئ تنفيذ Agile. المبتدئين لا ينبغي أن يكون. إجراء مقابلات انتقائية مع الفريق قبل توقيع العقد.
يجب أن تتاح
لفريق العمل الفرصة والرغبة في المشاركة بانتظام في المشروع خلال جميع مراحل التطوير. هذا لا يعني أن العمل يجب أن يعمل أكثر. نقوم بإعادة توزيع وقتهم من مرحلة التصميم والاختبار المعتادة في كل جزء من عملية التطوير.
بعض الأسئلة المتداولة
السؤال 1: تطلب الدائرة التجارية توقيع عقد مع مقاول ذو قيمة ثابتة قبل البدء في التطوير. ولكن كيف يمكن تقييم التكلفة إذا لم يكن هناك تصميم مكتمل وموقع؟
الإجابة 1: نحن نوقع عقد الفريق الثابت مع المقاول - نصلح الفريق ووقت تنفيذ المشروع ، على سبيل المثال ، 8 أشهر. هذا ليس هو نفسه وقت المواد ، كما نسجل مدة ومجموع العمل. في الوقت نفسه ، نبقى مرنين في تغيير / إضافة متطلبات العمل إذا لم تزداد مدة المشروع والفريق.
السؤال 2: ماذا لو أضاف مستخدمو الأعمال باستمرار متطلبات جديدة أثناء مراجعة وتخطيط كل سباق؟
الإجابة 2: في هذه الحالة ، نطلب منك تحديد أولويات المتطلبات وإزالة تلك التي لها أدنى أولوية ولا تتناسب مع المواعيد النهائية للمشروع. أي أضف واحدة جديدة بدلا من شيء موجود. كل هذه التغييرات / المتطلبات الجديدة ستكون في انتظارنا في أي حال في مرحلة القبول ، بغض النظر عن النهج. لكن في حالة القبول الوسيط في نهاية كل سباق ، لدينا المزيد من الفرص لإدارة هذه المتطلبات ، بينما عندما نقبل مباشرة قبل الإطلاق ، فإننا نخاطر بتوقيت الإطلاق وجودة النظام (الجودة بحكم التعريف هي مراسلات النتيجة النهائية لتوقعات المستخدم ، وليس تصميم النص).
إذا كنت مهتمًا بهذا المقال ، لديك أسئلة ، أو كنت ترغب فقط في مشاركة رأي حول ما ورد أعلاه ، فسأكون ممتنًا إذا كنت تشارك التعليقات في المنشور أو في رسالة شخصية. الرسوم التوضيحية والمحتوى الإيديولوجي للمقال بمشاركة أنجلينا عبد الله
أنجلينا . عبدولاييفا.