في الأجزاء السابقة
في
الجزء الأول أعلنت سلسلة من المقالات حول عمل المحلل في المشروع التمهيدي. سرد المشاكل والحلول والمبادئ التي تحتاج إلى تذكرها عند بدء مشروع تكنولوجيا المعلومات.
في
الجزء الثاني ، تحدثت عن المشاكل المتكررة للمشروع الأولي.
ناقشنا في
آخر مشاركة الجزء الأول من المبادئ الأساسية:
- تصميم أنظمة تكنولوجيا المعلومات وتصنيف منتجات تكنولوجيا المعلومات.
- مستويات نموذج V ودورة حياة النظام.
- نظرة على النظام كأصل مالي.
في هذه المذكرة ، سوف ننتهي بوصف "كيف" ، لمواصلة مناقشة ما يجب فعله إذا لم يعمل بشكل صحيح.
ما ستتعلمه من هذه الملاحظة:
- على مخروط عدم اليقين ومراحل التصميم.
- حول كيفية عمل التقييم.
- حول النطاق الكامل لمهام مرحلة ما قبل المشروع والقيم المحققة في نفس الوقت.
- حول كيفية الحصول على موارد كافية لمشروع ما قبل.
إذا كنت لا ترغب في الانتظار للأجزاء التالية من الدورة ، فيمكنك
مشاهدة فيديو تقريري ، الذي يتم على أساسه كتابة هذه السلسلة من المقالات.
دورة حياة النظام ومخروط عدم اليقين
مخروط اللايقين هو أحد المفاهيم المركزية للتصميم وإدارة المشاريع الحديثة. جوهر المفهوم: كلما قلنا من المعلومات ، كلما زاد عدم اليقين الذي يمكن التعبير عنه في شكل انتشار في شروط وتكلفة المشروع.
تزيل كل مرحلة من مراحل بناء النظام جزءًا من عدم اليقين. عند المرور بالمراحل النموذجية للمشروع ، ينخفض عدم اليقين بشكل كبير:
- عندما يكون لدينا فكرة تم التعبير عنها في موجز نصف صفحة ، يمكن أن يصل انتشار التكلفة والعائد إلى عدة أوامر من حيث الحجم.
- عندما تكون هناك متطلبات عمل ، بينما يتم تطوير خطة العمل أو نموذج العمل ، فإننا نخفض الفارق في التكلفة / العائد إلى الطلب.
- لتقليل الانتشار ، تحتاج إلى اتخاذ قرارات رئيسية حول مظهر وتصميم النظام. هذه الدراسة تقلل الفارق إلى نصف الترتيب. على الرغم من حقيقة أن المبعثر لا يزال كبيرًا ، فإن تحليل العلاقة بين العوائد والتكاليف يعطي القرار الرئيسي - سواء كنا سنبني نظامًا أو نبحث عن شيء أكثر ربحية.
- من خلال تحديد الشروط التي سيتم بناء النظام في ظلها (من سيقوم بذلك وفي أي إطار زمني) ، يمكننا تقليل انتشار التكلفة إلى القيم التي يمكن التعامل معها من خلال طرق إدارة المشروع ، ووضع الاحتياطيات ومعالجة المخاطر. يتم تسجيل الشروط المحددة في بيان العمل.
- يوفر التصميم الفني فقط تقديرًا دقيقًا تقريبًا مع وجود خطأ مقبول للنشاط التجاري.
ما يلي من هذا:
- من وجهة نظر تخصيص الموارد ، يجب أن يكون لدينا الوقت لتقليص المشروع قبل أن ننفق جزءًا كبيرًا من التكلفة إذا لم يعد مربحًا. يجب أن تشغل المراحل من الملخص إلى التصميم الفني جزءًا صغيرًا من التكلفة الإجمالية للنظام.
- عليك أيضًا أن تفهم أنه لا يمكنك التوصل إلى فكرة ووضع التكلفة على الفور. عندما يتم إخبارك أن هناك 20 مليونًا هنا وهذا أمر مؤكد ، أن لديك موجزًا قصيرًا فقط - لا تصدق ذلك ، لا.
- يجب القيام بمتطلبات العمل والتطوير المفاهيمي ، لأنها تزيل عدم اليقين ، ولكن هذا قد لا يصدأ إذا لم يبدأ المشروع. ونتيجة لذلك ، يجب أن تكون المراحل رخيصة الثمن قدر الإمكان ، ولكنها تخفف من عدم اليقين بطريقة الجودة.
كيف يعمل التقييم؟
هناك اعتقاد خاطئ شائع يمنع البدء العادي للعمل قبل المشروع: إذا لم نتمكن من تقديم تقييم دقيق بسرعة ، فلا ينبغي لنا أن نهتم بالمتطلبات على الإطلاق. هذا ليس صحيحا. مجموع التقديرات غير الدقيقة أكثر دقة - حقيقة من نظرية الاحتمالات.
في هذه الحالة ، يجب أن تعطي الدراسة السابقة للتصميم تقسيمًا للنظام وخطة العمل إلى عدة عشرات من الأجزاء المماثلة ، ويجب أن يتم التقييم لكل جزء عن طريق القياس أو بطريقة أكثر دقة. سيكون مجموع التقييمات سبريد أقل من كل تصنيف فردي.
إذا كانت جودة الدراسة المفاهيمية لا تسمح لنا بالحصول على تقسيم النظام إلى أجزاء مقبولة للتقييم ، فعندئذ لا نقوم بتقليل تشتت التقييم ولا فائدة من التواصل مع هذه الدراسة.
مراحل المشروع من وجهة نظر أسلوب التقييم هي كما يلي:
- عندما تكون هناك فكرة تم التعبير عنها في موجز نصف صفحة ، فإننا قادرون على التقييم عن طريق القياس.
- عندما نضع متطلبات العمل أو خطة العمل أو نموذج العمل ، يمكننا تسليط الضوء على المعلمات الرئيسية للنظام وإجراء تقييم عن طريق القياس باستخدام عامل واسع النطاق.
- يوفر المفهوم تقسيمًا إلى عدة عشرات من الأجزاء والأعمال ، مما يسمح لك بتلخيص التقديرات التي تم إجراؤها عن طريق القياس وحساب خطة إدارة المخاطر الرئيسية.
- إن الاختصاصات تحل محل تقييم أجزاء النظام عن طريق القياس مع التزامات الموردين حسب نوع العمل. يتم تحويل تقديرات الأجزاء التي تم إجراؤها عن طريق القياس إلى تقديرات الخبراء. يتم تمرير مخاطر الخطأ في التقييم إلى الموردين.
- يسمح التصميم الفني بتقسيم النظام إلى مئات وآلاف الأجزاء ، ويتم تقييم كل جزء منها بخبرة أو باستخدام إحصائيات حول تنفيذ المشاريع السابقة.
إذا لم يتم وضع الجوهر الموضح أعلاه في عمل ما قبل التصميم ، فمن الأفضل عدم القيام بذلك. لتحقيق انخفاض حقيقي في عدم اليقين ، من الضروري ليس فقط زيادة سمك حزمة الوثائق للنظام ، ولكن أيضًا لضمان وضع المتطلبات والحلول القابلة للقياس والممكنة هناك.
فكرة شائعة أخرى هي: "متطلبات الأعمال لا يجب أن تكون قابلة للقياس". تذكر - هذه كذبة!
ما تحتاج إلى تحقيقه في المشروع التمهيدي
وقد ذكر ذلك في الأجزاء السابقة من حيث المشاكل. الآن كرر بإيجاز المهام التي يجب تعيينها وإكمالها في أي مشروع سابق:
- افهم الوقت والتكلفة من أجل التخطيط للتكاليف واتخاذ قرار بالذهاب / عدم الذهاب. من المستحسن التنبؤ بالتأثير والعودة لتسريع هذا القرار.
- لبيع النظام:
- أظهر للعميل فهمًا لأهدافه.
- اعرض للمستخدمين الحل لمشاكلهم.
- إكمال المزايدة على الميزانية بنجاح (فهي موجودة دائمًا).
- لإنشاء أساس للقبول (عقد لحجم وجودة النتيجة مهمة فنية) ، لا تنس أن تضع في الخطة التحقق من صحة النظام الناتج من وجهة نظر التبرير العملي لتوقعات جميع الأطراف.
- حدد الموارد: الأنواع والمراحل والجداول الزمنية وأحجام العمل ومصادر الموارد لتأكيد تقديرات فناني الأداء وتحديد تكلفة النظام.
إذا لم يتم تعيين هذه المهام بشكل صريح ولم يتم التخطيط لحلها ، فمن الأفضل عدم إضاعة الوقت على الإطلاق - لا يمكن لهذا المشروع أن ينجح إلا عن طريق الصدفة.
لماذا قد لا تعمل (أو لا تستطيع)
نتيجة لجميع الاعتبارات السابقة ، لدينا 3 شروط متضاربة:
- يجب إجراء التحليل المسبق بسرعة.
- يجب أن يتم تحليل بريديزاين بثمن بخس.
- يجب أن يتم تحليل ما قبل التصميم بشكل نوعي.
يفهم أولئك المطلعون على قاعدة مثلث التصميم أن هذا لا يحدث.
هناك بعض الصعوبات الإضافية:
- قد يظهر تحليل ما قبل المشروع عائدًا منخفضًا على الحل المقترح ، ولن يكون هذا مثيرًا للاهتمام للعميل والراعي.
- يمكن أن يؤدي التحليل السابق للمشروع إلى زيادة حجم المشروع أو التكلفة الإجمالية للملكية بالنسبة للافتراضات الأولية ، وسيصبح هذا مرة أخرى غير مهم بالنسبة للعميل والراعي.
- يمكن أن يقلل تحليل ما قبل المشروع من حجم المشروع فيما يتعلق بالافتراضات الأولية ، وهذا غالبًا لا يثير اهتمام المقاول الخارجي.
فيما يتعلق بكل هذه الصعوبات ، أريد أنا وأنت أن نفهم شيئًا واحدًا: مشاكل ما قبل المشروع غير قابلة للحل إذا لم نكن إلى جانب الراعي ولا ننظر إلى مشروع تكنولوجيا المعلومات كأصل مالي.
في التعليقات على المقال قبل الأخير ، تم التعبير عن الرأي: “يجب فتح المشروع التمهيدي في أقرب وقت ممكن ، ولكن يجب أن يوضع في الاعتبار أن نطاق المشروع التمهيدي محدود بفعاليته. يعتبر مثل هذا المشروع المسبق فعالا ، وبعد ذلك سيتم إطلاق المشروع. هذا هو المؤشر الرئيسي الرئيسي لفعالية المشروع السابق. " (ج)
WizardryIBهذه وجهة نظر شائعة إلى حد ما بين مديري المشاريع ، لأنه إذا تم تكليفك بشيء ما ، يجب عليك قتل نفسك ، والضغط على فريق حتى آخر قطرة ، وتحويل ذراعيك إلى الموردين قبل كسرها ، واغتصاب العميل ، ولكن تحقيق الهدف.
من ناحية أخرى ، إذا أغلق مدير المشروع مشروعه الخاص ، فسيقلل من مكان عمله.
النهج الصحيح هو التخلص من الأصول السيئة في أقرب وقت ممكن. تتمثل مهمة المحلل والمدير في المشروع التمهيدي في القيام بذلك.
كيفية الحصول على ميزانية لمشروع ما قبل
من أجل السير في الطريق إلى إزالة بناءة ومتسقة لعدم اليقين حول مشروع تكنولوجيا المعلومات ، من الضروري توضيح مع العميل والراعي الموقف العام فيما يتعلق بالموقف من المشروع كأصل مالي.
تظهر الصورة النسبة الطبيعية لعدم اليقين والاستثمار والعائدات.
طالما أن عدم اليقين كبير ، يجب علينا استثمار القليل وتقليله.
بمجرد أن يصبح عدم اليقين بشأن نسبة الاستثمارات والمزايا مستوى مقبولًا ، يمكنك استثمار الجزء الأكبر من الموارد للعودة. في نهاية كل مرحلة ، يجب اتخاذ قرار صادق: العمل على المشروع أو إغلاقه.
للقيام بذلك ، في نهاية كل مرحلة ، يجب أن يكون هناك تقييم لنسبة الاستثمارات والعائدات على مستوى الدقة الطبيعي للمرحلة الحالية.
يحتاج العميل إلى إظهار المستوى الحالي من عدم اليقين ، والتقييم المعقول الحالي للمنافع والتكاليف. إذا تجاوزت الفوائد التكلفة ، فمن المنطقي مناقشة المزيد من إزالة عدم اليقين.
قد يكون الخطاب على النحو التالي: "نرى توقعات بفوائد تتجاوز بشكل كبير تكلفة النظام ، دعنا ننفق جزءًا صغيرًا من القيمة أو الفوائد المتوقعة لتحسين التقديرات والبت في بدء النظام".
توصياتي (المتوسطة جدًا) بشأن نسبة تكلفة أجزاء من المشروع السابق:
- يجب ألا يكلف كل شيء يحدث قبل البناء أكثر من 10-30 ٪ من المشروع.
- يجب أن يكلف المشروع المسبق حجمًا أقل - وهذا هو 1-3 ٪ من التكلفة المتوقعة للنظام.
- في المراحل المبكرة ، طالما لا توجد متطلبات عمل ، قد لا تكون هناك قيمة متوقعة ويجب صدها من العائد المحسوب - يمكنك أن تأخذ 0.1-0.2٪ طوال عمر النظام في الميزانية لإنشاء متطلبات الأعمال (مع الأخذ في الاعتبار أنه لا يبدأ لكل مشروع مقترح).
على سبيل المثال ، إذا قمنا ببيع نظام يكلف ~ 100 مليون (عن طريق القياس). هذا منطقي إذا كان العائد على تشغيلها على الأقل ~ 300-500 مليون ، بالنظر إلى الدقة المنخفضة لجميع التقديرات.
في هذه الحالة ، يمكن اعتبار التكاليف التالية عادية:
- متطلبات الأعمال - 0.5-1 مليون روبل.
- المفهوم هو 1-3 مليون روبل.
- المشروع الفني - 10-30 مليون روبل.
الانحرافات في أي اتجاه ممكنة هنا. لكن المبدأ العام هو هذا: يجب أن تكون الموارد المستثمرة مرتبطة بالربح المتوقع واحتمال استلامها ، اعتمادًا على المستوى الحالي من عدم اليقين.
ملخص موجز
هنا نكمل مراجعة المشروع التمهيدي الصحيح ونكرر أهم شيء:
- يجب اعتبار المشروع كأصل مالي محفوف بالمخاطر.
- يجب أن يكون مستوى عدم اليقين معروفًا للجميع ويناقش بين جميع الأطراف المعنية.
- يجب أن تكون تكاليف التحليل مرتبطة بالفائدة المتوقعة واحتمال تلقيها.
- في سياق التطوير ، من الضروري تحقيق جودة المتطلبات الكافية لتقييم التكلفة والشروط مع الدقة الكامنة في المرحلة الحالية.
- على وجه الخصوص ، يجب أن تكون متطلبات العمل قابلة للقياس بالفعل.
- من الضروري تذكر القائمة الكاملة لمهام مرحلة ما قبل المشروع ، حيث يؤدي حذف كل منها إلى زيادة احتمال فشل المشروع بأوامر من الحجم.
تظهر الحياة أنه لأسباب مختلفة ، ليس من الممكن دائمًا مراعاة هذه المبادئ. في بعض الحالات ، يمكن حفظ مشروع تالف قبل إطلاقه ، أو على الأقل تحسينه قليلاً. سنتحدث عن هذا في الأجزاء التالية من السلسلة.