إدارة المشروع عن طريق إصلاح الوقت والميزانية الثابتة والنطاق المرن (FFF)

أليس من حلم أي صاحب شركة أن يدير منتج تكنولوجيا المعلومات بطريقة تقدم المنتج في الوقت المحدد ، وتتفوق على المنافسين ، وتقوم بذلك بجودة عالية تسعد المستخدمين؟ أرغب في العثور على رصاصة فضية للتحكم ويبدو أنها موجودة. ليست فضية وليست رصاصة كبيرة ، ولكنها طريقة موثوقة ومُختبرة جيدًا للإدارة ، والتي يمكن تسميتها FFF: إصلاح الوقت والميزانية ، Flex Scope.



لماذا ومتى تختار FFF؟ دعنا نلقي نظرة.

1. ثلاث مجموعات

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





تركيبة محددة تخلق ظروف عمل معينة ، لها إيجابيات وسلبيات:

1. سعر ثابت
   
   
   
   
   • تم إصلاح ثلاث نقاط من مثلث المشروع: الوقت والمال ومقدار العمل.
   • يتحمل المقاول المخاطر الرئيسية ، ونتيجة لذلك ، تنعكس هذه المخاطر في التقييم. بالإضافة إلى ذلك ، يتم إنشاء مخاطر للعميل ، لقد كتبت عن هذا في مشاكل المقالة 12 عند العمل على مهمة فنية في أحد منتجات تكنولوجيا المعلومات .
   • إضافة كبيرة لهذا النهج هي معلمات المشروع المحددة مسبقًا قبل بدء العمل. في كثير من الأحيان تحتاج الشركة / الحكومة إلى تحديد المدة والمال ومقدار العمل في العقد.
   • . , . , .
   • .
2. Time and Materials (T&M)
   
   
   
   
   • , - .
   • .
   • , .
   • , . , , .
   • .
   • ( , Product Owner'), , , , .
3. Fix Time and Budget, Flex Scope (FFF)
   
   
   
   
   • : , .
   • .
   • , , .
   • , .
   • , , . .
   • : , / , .
   • , .. . , , , , , , .

– , . , «», , , . . , , SonarQube. Podlodka.

2.

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



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



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

لقد كتبت المزيد عن هذه المشكلة في مقالة رضا العملاء للمبرمجين: جميع المبرمجين متفائلون . يوجد ارتباط للتقرير 36 من فاديم ماكيشفيلي ، حيث يقترح ببساطة مضاعفة النتيجة بـ 3. باستخدام استعارة وضع وتمرير المسار ، يتم كتابته في المقالة لماذا تستغرق مشاريع تكنولوجيا المعلومات 2-3 مرات أطول مما هو مخطط لها؟ ...

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



العامل الثالث هو عدم وجود معايير لتحديد تحقيق الاكتمال عند وصف نطاق العمل. لا يمكن إنهاء كتابة المعارف التقليدية ، بل يمكن إيقافها فقط. لقد كتبت عن هذا بالتفصيل في المقالة متى حان الوقت للتوقف عن كتابة الشروط المرجعية .

يجب أن أحفظ أن كل هذا صحيح إذا كنت تعمل في منطقة معقدة نوعًا ما: وفقًا لإطار عمل Cynefin ، هذه هي المناطق المعقدة والمعقدة. إذا أصبح مشروعك واضحًا وفي نفس الوقت كان قصيرًا نوعًا ما ، فمن المرجح أنك ستقدر حجم العمل بدقة شديدة.

في المجموع ، لدينا أن أصل المشكلة يكمن في تقدير غير دقيق لنطاق العمل والاستحالة العملية لجعل هذا التقدير دقيقًا ، لذلك:

• تضحي مشاريع السعر الثابت بالجودة الداخلية للنظام ، لأنه يكاد يكون من المستحيل الوصول إلى تقدير بثلاث قمم ثابتة. أو ، في نفس مشاريع السعر الثابت ، يعيدون موازنة العديد من المخاطر لتغطية أي أخطاء في التقييم على الإطلاق ، وهو أمر غير فعال.
• T&M , . Product Owner'.
• FFF , , « » , T&M.

3. ?

إذا كان من المستحيل تقدير نطاق العمل بدقة كافية ، فربما لا يحدث ذلك على الإطلاق؟ هناك مثل هذه الحركة # NoEstimates. باختصار ، نحن ننظم عملية التطوير بطريقة تؤدي إلى تنفيذ المهام بأكبر قدر ممكن من الكفاءة من مرحلة الفكرة إلى طرحها في الإنتاج ، مع الحفاظ على الجودة الداخلية العالية. يعرضون تنظيم العملية باستخدام Kanban مع تتبع مقاييس معالجة التدفق والاهتمام الخاص لتحسين عملية تقديم ميزات جديدة. تعتبر التقييمات السابقة لأوانها ضارة ، وتقييم الأعمال المتراكمة والاستعداد لها مضيعة للوقت.

أين تتعلم المزيد عن # NoEstimates:

1. يتحدث ديفيد أندرسون كثيرًا عن هذا ، على سبيل المثال ، في حديثه The Alternative Path to Enterprise Agility .
2. تحدث Askhat Urazbayev في AgileDays في خطابه # NoEstimates: تطوير غير تقييمي .
3. كتب رون جيفريز عن هذا في مقالة بعض الأفكار حول التقدير .
4. كتب دينيس ستيبونوف عن هذا على Habré في مقالة حول تقديرات المصطلحات في تطوير البرمجيات .

أنا كلاهما مع هذا النهج. أنا أحبه كمهندس وكقائد. لكن الحياة مرتبة بحيث يحتاج أصحاب الميزانية إلى تقدير ، على الأقل في المراحل الأولى من العمل ، على الأقل تقدير تقريبي. في Byndyusoft ، ننتقل أحيانًا إلى # NoEstimates ، ولكن فقط بعد علاقة طويلة جدًا مع العميل وهذا لا يحدث دائمًا.

4. FFF - توازن المرونة والقدرة على التنبؤ

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



كانت المرة الأولى التي رأيت فيها وصف FFF في الحصول على حقيقة بواسطة 37 إشارة في فصل Fix Time and Budget ، Flex Scope . في الوقت الحالي ، في شركتي ، هذا هو النهج الأكثر شيوعًا للعمل ، سواء العملاء ونحن راضون عنه.

5. الجودة الداخلية للنظام

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



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



إذا كنت ترغب في العمل وفقًا لـ FFF ، فضع معايير الجودة في العقد لإصلاحها بالتأكيد.

6. تحفيز العميل والمقاول

يعطي عمل FFF الدافع الصحيح من جانب العميل والمقاول. على عكس السعر الثابت ، حيث يتواصل العميل والمقاول من خلال واجهة العقد ، وعلى عكس T&M ، حيث يمكن للعميل أن يفقد الحدود وينفق أكثر من اللازم ؛ في FFF ، يجب على الجميع الاستثمار في الاتصالات و "العيش" في المشروع من أجل القيام بأهم شيء وفي نفس الوقت تلبية شروط العقد.

7. اختر FFF

السعر الثابت و T&M لهما مزايا في سياقات معينة:

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

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



الروابط:

1. كيف وما هي الاختصاصات التي يجب كتابتها عند العمل على Agile .
2. مبدأ إدارة المشروع في مكتب تصميم Artyom Gorbunov.