7 عوامل للفشل المضمون

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

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

فيما يلي 7 عوامل نموذجية تكاد تضمن الفشل.

العامل الأول: تجاهل العامل البشري

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

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

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

العامل 2: فكر بشكل كبير جدًا أو صغير جدًا

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

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

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

العامل الثالث: الاعتماد على التقديرات والتخطيط 100٪

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

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

العامل 4: يتم تجاهل مثلث PM السحري باستمرار

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

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

العامل الخامس: توثيق كل شيء

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

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

العامل 6: فقط لا يوجد تنظيم مشروع متوازن

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

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

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

العامل 7: سخن الضفدع ببطء

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

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

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

لذلك يمكن أن يكون ذلك ممكنا

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

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