في رأيي ، لم يكشف مقال
"Bosses of Bloodsuckers in the Context ..." عن سبب انهيار فرق الحكم الذاتي ، ولكن السبب في ذلك كان انخفاض سرعة توزيع متطلبات المنتج ، والفشل في فهم أن القائد هو دائمًا جزء من الفريق.
عن طريق تغيير النهج المتبع في تخطيط قسم التصميم أثناء تطوير منتج جديد ، يمكنك زيادة السرعة التي يتم بها توزيع المعلومات ، والتي تعد أكثر أهمية للمشروع من مجرد الحصول على المعلومات.
التصميم الكلاسيكي
في المخطط الكلاسيكي ، تتميز عملية تخطيط العمل وعملية التطوير بجداول زمنية واضحة. عادة ، تتم عملية التخطيط قبل التطوير. في نهاية التخطيط لكل شهر ، يظهر "جدول عمل الشبكة" ، والذي تبدأ بموجبه عملية تطوير المنتج من قبل قسم التصميم. لا توجد أنواع كثيرة من رسومات الشبكة - هذه بشكل أساسي
PERT و
GANTT . عادة ما تكون المصطلحات الواردة في جدول الشبكة تعريفية ولا يتم نسخها احتياطيًا بأي شيء ، مما يخلق مجالًا وهميًا عند القيام بالعمل في عملية التطوير بواسطة قسم التصميم والتطوير. في الواقع ، يتم الاتفاق على الشروط الواردة في جدول الشبكة مع العميل ، ويلتزم المقاول بالالتزام بها ، وإلا فإن فشل المواعيد النهائية للتطوير قد يهدد بإغلاق المشروع ككل. لا أحد يسأل المطورين في المخطط الكلاسيكي ، ويقوم مدير المشروع ببساطة بخفض المواعيد النهائية لكل عمل للمطورين.
من الجانب ، يبدو الأمر كما لو أن مدير المشروع يمنح الجميع نوعًا من أدوات الصيد (أداة) ويقول: "اصطاد سمك الشبوط الصخري. في نهاية الشهر ، سوف أتيت للتحقق من عدد الأشخاص الذين تم القبض عليهم. نحن بحاجة للقبض على 2 طن. " خلال الشهر ، يعقد مدير المشروع اجتماعات يُبلغ فيها عن عدد الأطنان ونوع الأسماك التي اشتعلها. في نهاية الشهر ، يُصدر مدير المشروع جدول شبكة "محدث" جديدًا ، وفقًا للعميل الذي يريد ألا يصطاد سمك الشبوط ، ولكن على سبيل المثال
"الكوسة" . يتمتع "مدير المشروع الحكيم" بفرصة للحصول على مكافأة لشراء بلازما جديدة أو سيارات رياضية متعددة الاستخدامات جديدة. إذا كان محظوظًا وسيكون هناك شخص واحد على الأقل يصطاد "أسماك الكوسة" ، فسوف يدفع مكافأة له وللصياد المحظوظ ، ويفرض غرامة على الآخرين.
يفرض وضع التشغيل هذا على مدير المشروع تولي بعض مهام التطوير لنفسه ، كما أن مطوري هذا المشروع يتأخرون باستمرار عن العمل ، وأحيانًا يتعين عليهم الذهاب في عطلات نهاية الأسبوع ليكونوا قادرين على تطوير واجهات تفاعلية جديدة للمستخدم مع المنتج في الوقت المحدد. كل هذا ، كما ذكرت أعلاه ، يتفاقم أكثر بسبب حقيقة أن متطلبات المنتج النهائي يمكن أن تتغير ، ثم يتم ضبط جدول الشبكة ، ويتم التعديل بطريقة لا تؤثر على المصطلحات الأساسية في المشروع.
في مثل هذا المخطط ، يعتمد كل العمل على العامل البشري ، الذي يلعب دورًا رئيسيًا. يمكن التقليل إلى الحد الأدنى من العامل البشري عن طريق إدخال أنظمة تخطيط وتطوير آلية ، والتي ، في جوهرها ، يقوم العديد من الأشخاص بتنفيذ
CAD ،
CAM ،
CAE ،
PDM ،
ERP ،
CRM ،
PLM ، إلخ في مؤسساتهم.
ومع ذلك ، فإن الأساس في شكل مخطط كلاسيكي ، عندما يكون للتخطيط والتطوير حدود زمنية واضحة ، لا يزال دون تغيير. نتيجةً لذلك ، يتعين على المطورين الاحتفاظ بإصدارات عديدة محدثة من منتج البرنامج والوثائق في كل نظام آلي ، بالإضافة إلى دعم تكامل النظام بشكل مستمر ، وهو ما يمثل مشكلة كبيرة في الظروف التنافسية الحالية لسوق تكنولوجيا المعلومات. يحتاج العميل في النهاية إلى شيء واحد فقط - هو المنتج النهائي أو الإنتاج المُبسَّط. في المخطط الكلاسيكي ، ستكون قائمة الوثائق التي طورها المقاول دائمًا لا لزوم لها ، نظرًا لعدم ثقة العميل أو المقاول تمامًا في أن الهدف سوف يتحقق ، مما يعني أنه من الضروري توثيق العملية إلى الحد الأقصى من أجل تحديد من "يلوم" المواعيد النهائية. حتى إذا تم صياغة الهدف النهائي في البداية على أنه محدد (محدد) ، قابل للقياس ، يمكن تحقيقه ، واقعي وقائم على الوقت ، كنتيجة لذلك ، بعد المطلب الإضافي الأول ، قد يفقد الفنان ثقته قابلية الوصول للهدف النهائي ، وبالتالي سيكون هناك انهيار للمواعيد النهائية وإغلاق المشروع.
كيف إذن التأكد من أن العميل لا يغير المتطلبات في كثير من الأحيان ، وأن المقاول يفي بجميع متطلبات العميل في الوقت المحدد؟
في المخطط الكلاسيكي ، يتم تنفيذ عملية التخطيط بواسطة خبير متمرس في مجال تخطيط المشروع ، والذي يقوم ، بناءً على خبرته ، بتحديد قائمة المهام وشروطها. أعتقد أن كل هذا لم يكن من الممكن أن يقوم به خبير متمرس ، لأن الفريق نفسه يمكنه تحديد الجداول الزمنية لإنجاز المهام ، وكذلك قائمة المهام اللازمة للتنفيذ. لهذا الغرض ، يحتاج الخبير من جانب العميل إلى وصف المنتج بالتفصيل قدر الإمكان في معارفه
التقليدية والموعد النهائي الذي يحتاج إليه المنتج ، وهذا كل شيء! يمكن للفريق ، تحت إشراف مدير المشروع ، أن ينفذ بنفسه تخطيط العمل ، وتحديد المزالق ، وتحلل المهام ، باختصار كل العمل الذي يقوم به خبير متمرس.
"المشكلة" هي أنه في هذه الحالة يعرف كل عضو من أعضاء الفريق الهدف النهائي ، وهو شفاف وفي كل لحظة من الزمن ، يُعرف إلى أي مدى هو بعيد عن الفريق. لن يتمكن "مدير المشروع الحكيم" من إدراج هدفه الضخم في هذا الهدف: "شراء سيارة دفع رباعي حديثة". من أجل تحقيق هدفه الكبير بنسبة 100٪ بنجاح ، يحتاج إلى فصل عمليات التخطيط والتطوير ، وإعطاء قوائم بالمهام على دفعات عند ظهور "مشاكل". في هذه الحالة ، تتمثل مهمة مدير المشروع في تحويل انتباه الفريق إلى الهدف النهائي للمشروع قدر الإمكان ، وتركيز انتباههم على الحل في الوقت المناسب تمامًا للعمل المحدد لجدول الشبكة. بمعنى آخر: "املأ الفريق بالعمل الروتيني".
مخطط العمل المختلف بشكل أساسي هو مخطط العمل باستخدام منهجيات التطوير المرنة ، حيث المبدأ الرئيسي هو:
عمليات التسليم المستمرة المتكررة لمنتج ذي قيمة للعميل.لتحقيق ذلك ، أولاً وقبل كل شيء ، تسمح شفافية عملية التخطيط ، عندما يعرف كل عضو من أعضاء الفريق الهدف النهائي ويشارك في تشكيل مجموعة المهام للأسبوع 1-4 التالي ، وبعد ذلك سيرى العميل الإصدار الأول من المنتج بوظائف جديدة. تقع على عاتق مدير المشروع مسؤولية الحصول على موافقة العميل أو إخطاره ببساطة بإصدار المنتج بوظيفة جديدة ، والتي ستكون جاهزة بعد الانتهاء من التكرار. يجب أن تؤخذ جميع المتطلبات الإضافية القادمة من العميل في الاعتبار عند التخطيط لفريق تجمع المهام في التكرارات التالية.
من أجل عدم الابتعاد عن المسار المؤدي إلى تحقيق الهدف النهائي ، يجمع الفريق يوميًا لمدة 15 دقيقة ، حيث يجيب كل عضو في الفريق على ثلاثة أسئلة:
- ما الذي تم القيام به منذ الاجتماع السابق؟
- ما الذي سيتم القيام به للرالي القادم؟
- ما هي المشاكل؟
في حالة تنفيذ التخطيط بشكل منفصل عن التطوير ، يتم تقديم إجابة السؤال الثاني بواسطة مدير المشروع ، كما هو الحال بالنسبة للإجابة على السؤال الثالث.
في نهاية كل تكرار (سباق) ، يقوم الفريق بعرض المنتج بوظيفة جديدة للعميل. بعد كل عرض ، يجتمع الفريق بشكل منفصل عن العميل لإجراء استعادية. هناك الكثير من الطرق لإجراء الاستعادات ، أود أن أشير إلى استعادية بأسلوب "PLUS / DELTA" ، حيث يعبر كل عضو في الفريق عن 10 نقاط إيجابية (PLUS) وعشر نقاط جعلت الفريق يحيد (DELTA) عن تحقيق الهدف المقصود.
في مخطط العمل باستخدام تقنيات التطوير المرنة ، تلعب الأنظمة الآلية دورًا رئيسيًا ، حيث تتيح لك الحصول على منتج يتمتع بوظائف جديدة أكثر تقدمًا في نهاية التكرار. بعد كل تكرار ، يمكن إرسال المنتج للتطوير التكنولوجي في أنظمة
ERP أو
CRM من أجل البدء في إنتاج منتج نموذج أولي للاختبار في ظل ظروف أقرب ما يكون إلى المنتجات الحقيقية. وبالتالي ، بعد كل تكرار ، يتم تحسين منتج البرنامج وبناء متطلبات وظيفية جديدة. سيعبر العملاء أنفسهم بالفعل في مرحلة التطوير التكنولوجي أو مشروع رائد من خلال التغذية الراجعة في نظام
CRM عن المتطلبات التي لن تفكر فيها. الشيء الرئيسي هو نقل هذه المتطلبات إلى المطورين في الوقت المناسب ، وليس لإخفائها في قاعاتهم المنطقية ، كما يفعل أحيانًا "مدير المشروع الحكيم".
استخلاص النتائج
عادة ما تفشل محاولات بناء عملية التطوير وفقًا للمخطط الكلاسيكي باستخدام منهجيات مرنة ، ورؤية هذا العدد الكبير من مديري المشاريع من أجل "megacels" أو ببساطة تلقائيًا وفقًا للمبدأ الأساسي المتمثل في "فرق تسد" يرفض تطبيق المعرفة الحديثة لإدارة المشروع في الممارسة العملية.