جاذبية ثلاثة الصلبان ، أو لماذا من الصعب جدا الانتهاء من المشاريع في الوقت المحدد

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

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

"يمثل الخيال الديناصورات ، الماموث والنمور ذات الذراعين الساعي في محاولة لتحرير أنفسهم من الراتنج. بغض النظر عن مدى قوة أو رشاقة الوحش ، في النهاية سيكون مقدر للموت. في العقد الماضي ، كانت مثل هذه الحفرة تُبرمج أنظمة كبيرة ... " [1 ، صفحة 16] بهذه الصورة المدهشة ، يبدأ الكتاب الكلاسيكي لكاتب فريدريك بروكس ، وشهد النور لأول مرة في عام 1975 البعيد. كتاب كلاسيكي آخر ، نُشر في نفس عام 1987 القديم ، لا يبدأ بشكل أفضل: "وفي ذلك الوقت ، يموت المشروع في مكان ما" [2 ، صفحة 23]. بعد مرور سنوات ، تدخل البشرية ألفية جديدة ، لكن في عام 2014 ، بدأت أكثر الكتب مبيعًا بنفس القصة الأبدية: "في 3 مارس 2010 ، قرر مكتب التحقيقات الفيدرالي تعليق خطته الواسعة والواعدة لتحديث إدارة المعلومات ... حاول المكتب تحديث نظام الكمبيوتر الخاص به منذ أكثر من عشر سنوات ، ويبدو أن كارثة حلت بهم " [٣ ، صفحة ١٤].

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

وفقًا لدراسات CHAOS من مجموعة Standish-Group [4]

لماذا تقدم التقدم في علم الإدارة (المجسدة في 6 طبعات من PMBoK وعشرات الكتب الكثيفة الأخرى) لمدة 40 عامًا (!) لم يفض أبدًا إلى تحسن في جودة الإدارة نفسها (ما لم يكن ، بالطبع ، من خلال جودة الإدارة يُفهم احتمال الوصول إلى نقطة معينة)؟ للتعامل مع هذه المشكلة ، نبدأ مع المشكلة الرئيسية لأي مشروع ، والتي تم تحديدها من خلال كتاب بروكس الشهير.

المشكلة الأولى: تعقيد المنتج الذي يتم إنشاؤه

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

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

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

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

"يتم إنشاء المشاريع المتميزة من قبل المصممين المتميزين. إنشاء البرامج عملية إبداعية. يمكن لمنهجية قوية أن تعمل على تمكين العقل الخلاق وتحريره ، لكنها لا تستطيع أن تلهم أو تلهم شخصًا مشغولًا بالعمل الشاق ... لذلك ... أعتقد أن الجهد الوحيد والأكثر أهمية الذي يمكننا القيام به هو تطوير طرق لتثقيف المصممين المتميزين " [1 ، ص. 185-186]

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

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

عند نقطة التقاطع ، أو قبله بفترة وجيزة ، يصبح من الواضح أن المشروع يتطلب في الواقع الكثير من المال والوقت أكثر مما كان الغرض منه في الأصل:

المشروع التالي ، المسمى "Sentinel" ، بدأ مكتب التحقيقات الفيدرالي على الفور ، في عام 2005. يبلغ سعر الإصدار 451 مليون دولار ، وسيتم تشغيل نظام Sentinel بشكل كامل في عام 2009 ... في مارس 2010 ، تأخرت شركة لوكهيد مارتن ، المقاول في نهاية العام عن طريق إكمال نصف المشروع فقط وإنفاق 405 مليون دولار. لاستكمال ، وفقًا لخبراء مستقلين ، سيستغرق الأمر من ست إلى ثماني سنوات أخرى ، و 350 مليون دولار إضافية. [3 ، صفحة 17-18].

لكن دعني! إذا كنا نعرف ، منذ عام 1975 ، أن تعقيد المشاريع ينمو ، على سبيل المثال ، من الناحية التربيعية ، - ما الذي يمنع الميزانية والفريق من الزيادة من الناحية التربيعية بالطريقة نفسها؟ لماذا تستمر جميع الأجيال الجديدة من المديرين في قيادة المشاريع بنجاح متوقع بنسبة 30 ٪ ، عندما يمكنك فقط إضافة الأموال ؟

الآن ، حان الوقت للانتقال إلى الكتاب التالي.

المشكلة الثانية: تعقيد التعاون

كما نعلم بالفعل ، فإن Peopleware الأكثر مبيعًا على مستوى العالم ("التوظيف" المترجم إلى اللغة الروسية باسم "العامل البشري") ، والذي ظهر بعد مرور اثني عشر عامًا على شهر الأسطوري ، يبدأ ببيان معدل الوفيات المرتفع للمشاريع. "حوالي 15 في المائة من المشاريع لم تنته بأي شيء ... في حالة المشاريع الكبيرة ، كانت الصورة أسوأ ، فقد استوعب الانهيار خمسة وعشرون في المئة من المشاريع التي تراوحت مدتها بين خمسة وعشرين عامًا من العمر" [2 ، صفحة 24]. وقد كتب هذا في عام 1987 (كان الاتحاد السوفياتي لا يزال على قيد الحياة !) ، بالرجوع إلى دراسة 1981 (كان بريجينيف لا يزال على قيد الحياة) ؛ وماذا لدينا اليوم؟

وفقًا لتقرير CHAOS 2015 [5]

يتكلف المطور المتوسط ​​اليوم 100 ألف دولار سنويًا ، مضيفًا النفقات العامة ، وحصلنا على أن 25 عامًا من الأفراد تتراوح بين 3 و 6 ملايين دولار. كما ترون ، لم يتغير الموقف منذ تلك السنوات الطويلة: 26 ٪ من المشاريع المتوسطة الحجم و 43 ٪ من المشاريع الكبيرة تتوقع الفشل ، وليس هناك شيء يمكننا القيام به حيال ذلك. ولكن لماذا يحدث هذا؟ سأل Demarco و Lister المطورين عن أسباب الفشل ، وهنا ما حصلوا عليه ردا:

في الغالبية العظمى من الحالات ، لم يكن هناك سبب واحد للفشل من مجال التكنولوجيا. في معظم الأحيان ، دعا المشاركون في استطلاعات الرأي لدينا "السياسة"

ليس الأمر على الإطلاق تعقيد المنتج الذي يتم تطويره ، وليس نقص الموارد ، كما قد يتوقع المرء عند النظر إلى Brooks Cross! "السياسة" ، هي العلاقة بين الأشخاص داخل وخارج الفريق (ما فضل ديماركو وليستر تسميته "علم الاجتماع") - وهذا ما حاله ، حسب المطورين ، دون النجاح أكثر من أي شيء آخر.

فكر في هذه الحقيقة : هؤلاء الأشخاص (المطورين ، والرؤساء ، والعملاء) الذين كانوا أكثر اهتمامًا بالنجاح من أول وهلة ، واتحدوا من أجل المشروع ، رتبوا "السياسة" فيه ، والتي أدت إلى انهيار المشروع! "قابلنا العدو وهو نحن" [6] ؛ وكشف المشروع ثاني أسوأ عدو - فريقه.

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

التين. 2 من المادة بوتنام ، مايرز [7]

بعد تجميع الخصائص العددية لـ 491 مشروعًا لتطوير البرامج من 35 إلى 95 ألف سطر من الشفرات ، توصل بوتنام ومايرز إلى نتائج يكاد يكون من المستحيل تصديقها. تم الانتهاء من المشاريع ذات الحجم المماثل من قبل فرق من أعداد مختلفة في نفس الوقت تقريبًا ، ولم تكن الفرق ذات الأعداد الكبيرة بحاجة إلى وقت أقل ، ولكن إلى وقت أكثر . تحول قانون Brooks ("إضافة مطورين - إبطاء المشروع") إلى العمل ليس فقط في مواجهة تعطل المشروع ، ولكن منذ البداية ، بدءًا من إضافة المبرمج التاسع. إذا قدمت نفس النتائج من حيث أشهر الشهور سيئة السمعة ، فستحصل على جدول زمني أكثر تعبيرًا. كم من المال (في الرواتب الشهرية) مطلوب لحل نفس المشكلة من قبل فرق من أعداد مختلفة:

التين. 3 من المقال بوتنام ، مايرز [7]

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

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

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

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

فلماذا؟ هل هناك حقا تقاطع آخر على الطريق إلى الإدارة الفعالة للمشروع؟

المشكلة الثالثة: صعوبة التخطيط الجديد

للوهلة الأولى ، العقبة الثالثة أمام الإدارة المثالية للمشروع هي الطبيعة غير العادية للطريقة الصحيحة لتوجيه العملية الإبداعية. تم وصف إحدى هذه الطرق ، المعروفة الآن باسم Scrum ، في مقال [8] في عام 1986 ، حتى قبل إصدار Peopleware. في غضون بضع سنوات ، في عام 1993 ، استخدم Jeff Sutherland العناصر الفردية لـ Scrum في مشروعه ، وكان مسروراً بالنتيجة:

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

ومع ذلك ، تم نشر وصف مفصل للأفكار الرئيسية لـ Scrum بعد عشرين عامًا فقط ، في اليوم الآخر ، في عام 2014 [3]. طوال هذا الوقت ، كان سكروم موجودًا كمنهجية شبه طائفية ، ينتقل حرفيًا من المعلم إلى الطالب ، واكتسب شعبية بشكل حصري من خلال الكلام الشفهي. الشيء هو أن المفهوم الرئيسي لـ Scrum ، والذي يتبع مباشرة من فلسفته ، لم ينسجم مع أي منطق تحكم معقول:

هذا ما أكرره باستمرار للقيادة: "لا يمكنني تحديد الموعد النهائي إلا عندما أرى مدى فعالية الفريق" (3 ، ص 28).

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

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

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

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

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

بالحكم على العنف الذي يهاجم فيه ساذرلاند في كتابه "مخططات جانت" ، لا يمكن للمرء:

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

إنهم يدفعون ثمن الكذب عليهم - هذا هو الشيء! ( « ») , . , , (« !»). :

, , , , [3, .23]

: ( ) ( ), . «», , :

( , ), , « », . : «, , , ».

— ! [9]

, « » . , , . « - » , . (« ») . , - .

? ? — . () — . — .

. , «» . , ( «»). , . , — , . , .

• [1] . « - », , -, 2007
• [2] ., . « : », , -, 2005
• [3] , . «سكروم. », ., , , 2016
• [4] de.wikipedia.org/wiki/Chaos-Studie
• [5] CHAOS REPORT 2015
• [6] We have met the enemy
• [7] Putnam, Myers «Familiar Metric Management — Small is Beautiful-Once Again», 1998
• [8] , « : » (1986),
• [9] .. « !», ., 1966