लुभाना तीन पार, या परियोजनाओं को समय पर खत्म करने के लिए इतना कठिन क्यों है

एक क्रॉस (+) का मतलब था कि मैसेंजर चरणों में गंतव्य तक जा सकता है, दो क्रॉस (++) का मतलब एक लिनेक्स, तीन क्रॉस (+++) - एक तत्काल सरपट है। इसलिए, सेना में सरपट को अनौपचारिक रूप से तीन पारियों के आकर्षण कहा जाता था, और बाद में इस अभिव्यक्ति ने रूसी भाषा में प्रवेश किया, जिसका अर्थ है अधिकारियों से आदेशों का सबसे तेजी से निष्पादन। [विकिपीडिया]

टार पिट (अंग्रेजी, टार पिच ) - 1) एक अघुलनशील समस्या, 2) एक बिटुमेन लेक (एक जगह जहां भूमिगत कोलतार सतह पर आता है, प्राकृतिक डामर का एक खंड बनाता है)। [अंग्रेजी-रूसी शब्दकोश] बिटुमेन में पकड़े गए जानवर बाहर नहीं निकल सकते हैं, इसलिए ऐसी झीलें प्रागैतिहासिक कंकाल [विकिपीडिया] उत्खनन के लिए एक शानदार स्थान हैं।

“कल्पना डायनासोर, स्तनधारी और कृपाण-दांतेदार बाघों को राल से मुक्त करने की कोशिश करती है। जानवर कितना भी मज़बूत या फुर्तीला क्यों न हो, आखिर में उसे मौत के घाट उतार दिया जाएगा। पिछले दशक में, इस तरह के एक टार पिट में बड़ी प्रणालियों की प्रोग्रामिंग की गई है ... " [1, p.16] इस हड़ताली छवि के साथ, फ्रेडरिक ब्रूक्स द्वारा क्लासिक किताब शुरू होती है, सबसे पहले 1975 में प्रकाश देखा गया था। उसी प्राचीन 1987 में प्रकाशित एक और क्लासिक पुस्तक, कोई बेहतर शुरुआत नहीं करता है: "और उस समय यह परियोजना कहीं मर रही है" [2, p.23]। साल दर साल, मानव जाति एक नई सहस्राब्दी में प्रवेश करती है, लेकिन 2014 में एक और बेस्टसेलर एक ही शाश्वत इतिहास के साथ शुरू होता है: "3 मार्च, 2010 को, संघीय जांच ब्यूरो ने सूचना प्रबंधन को आधुनिक बनाने के लिए अपने बड़े पैमाने पर और आशाजनक योजना को निलंबित करने का फैसला किया ... ब्यूरो ने अपने कंप्यूटर सिस्टम को अपडेट करने की कोशिश की। दस से अधिक वर्षों के लिए, और ऐसा लगता है कि एक तबाही ने उन्हें विचलित कर दिया है ” [3, पी। 14]।

ब्रूक्स के 44 साल बाद, हम एक स्पष्ट विवेक के साथ, दोहरा सकते हैं: अब, जब आप इन पंक्तियों को पढ़ते हैं, तो अगली परियोजना, अपने पूर्ववर्तियों की तरह, उसी टार पिट में डूब रही है। परियोजना प्रबंधन में सफलता की संभावना एक सिक्के को उछालने से कम है, और यह बहुत अधिक नहीं लगता है:

स्टैंड-ग्रुप [4] से CHAOS अध्ययनों के अनुसार

प्रबंधन विज्ञान में प्रगति क्यों हुई है, 40 वर्षों में (पीएमबीओके और अन्य दर्जनों मोटी किताबों के 6 संस्करणों में सन्निहित) (40?) कभी भी प्रबंधन की गुणवत्ता में सुधार नहीं हुआ (जब तक कि निश्चित रूप से, प्रबंधन की गुणवत्ता को किसी दिए गए बिंदु पर पहुंचने की संभावना समझा जाता है)। इस मुद्दे से निपटने के लिए, हम किसी भी परियोजना की मुख्य समस्या से शुरू करते हैं, जिसे पूरे ब्रूक्स पुस्तक में पहचाना जाता है।

पहली समस्या: बनाए जा रहे उत्पाद की जटिलता

यदि आप पहले आईटी विशेषज्ञ से पूछते हैं - "पौराणिक पुरुष-महीने में मुख्य बात क्या है?" - उत्तर होने की संभावना है: "यह कि सभी मानव-महीने अलग-अलग हैं, नए श्रमिक पुराने समान नहीं हैं।" यहां तक ​​कि ब्रूक्स "कानून" को पुस्तक की शुरुआत में तैयार किए गए प्रावधान कहते हैं ("यदि परियोजना समय सीमा को पूरा नहीं करती है, तो अधिक श्रम जोड़ने से इसमें और भी अधिक देरी होगी")। लेकिन यह केवल एक अनुभवजन्य अवलोकन है, जो सभी को ज्ञात है कि कम से कम एक बार "क्रॉसिंग पर घोड़ों को बदल दिया"; सवाल यह है कि कैसे एक परियोजना की योजना बनाई जाए जब सभी मानव-महीने अलग-अलग हों?

"पौराणिक पुरुष-महीना" इसलिए बेस्टसेलर बन गया, जो इस प्रश्न का उत्तर देता है। यहां बताया गया है कि ब्रूक्स एक मूल डिजाइन समस्या की अपनी समझ कैसे तैयार करता है:

"... इकाई की इस जटिलता से सॉफ़्टवेयर डेवलपमेंट स्टेम की क्लासिक कठिनाइयाँ और बढ़ते आकार के साथ इसकी गैर-रेखीय वृद्धि। जटिलता टीम के सदस्यों के बीच संचार की प्रक्रिया में कठिनाइयों का कारण बनती है, जिससे उत्पाद में त्रुटियां होती हैं, विकास की लागत से अधिक हो जाती है, कार्य अनुसूचियों के निष्पादन में देरी होती है। जटिलता का कारण है। गणना की कठिनाइयों, और विशेष रूप से कार्यक्रम के सभी संभावित राज्यों की समझ, और इसलिए इसकी अविश्वसनीयता पैदा होती है ... संरचना की जटिलता कठिनाई का कारण बनती है कार्यक्रमों के विकास और नए कार्यों को जोड़ने के दौरान ताकि कोई दुष्प्रभाव न हो ... " [1, पी। 167]

परियोजना और किसी भी अन्य उत्पादन के बीच मूलभूत अंतर यह है कि इसमें बनाई गई परियोजना पहली बार निर्मित होती है [हम जानते हैं कि "साइट पर यात्राओं के काउंटर को खराब करने" जैसे कई कार्यों को "प्रोजेक्ट" भी कहा जाता है, लेकिन हम वास्तविक परियोजनाओं के बारे में बात कर रहे हैं]। किसी भी वास्तविक चीज़ की तरह, इस नए उत्पाद (इसमें कोई फर्क नहीं पड़ता कि यह सॉफ़्टवेयर या "हार्डवेयर" है) में बड़ी संख्या में ऐसे घटक होते हैं जो सबसे अप्रत्याशित इंटरैक्शन (नकारात्मक - थैलिडोमाइड और सकारात्मक - वायग्रा) दोनों में सक्षम होते हैं। यह देखना बहुत मुश्किल है कि यह सब एक साथ कैसे चलेगा, और इसके लिए "बेहतर दिमाग" की आवश्यकता होती है, न कि "मानव-मास":

“बकाया परियोजनाएं उत्कृष्ट डिजाइनरों द्वारा बनाई गई हैं। कार्यक्रम बनाना एक रचनात्मक प्रक्रिया है। एक मजबूत कार्यप्रणाली रचनात्मक दिमाग को सशक्त और मुक्त कर सकती है, लेकिन यह किसी ऐसे व्यक्ति को उत्तेजित या प्रेरित नहीं कर सकती है जो थकाऊ काम में व्यस्त है ... इसलिए ... मेरा मानना ​​है कि एकमात्र और सबसे महत्वपूर्ण प्रयास हम उत्कृष्ट डिजाइनरों को शिक्षित करने के तरीके विकसित कर सकते हैं " [1] , पी। 185-186]

ब्रूक्स की मूल स्थिति से (डिजाइनिंग रचनात्मकता है , और रचनात्मक प्रक्रिया को भीड़ द्वारा नहीं किया जा सकता है), "पौराणिक मानव-माह" की पूरी वास्तविक सामग्री सीधे इस प्रकार है: "आर्किटेक्ट्स की तानाशाही", और "दूसरी परियोजना के प्रभाव" की आवश्यकताओं, और सिफारिश "पहले संस्करण को दूर फेंकने की योजना" । लेकिन यह ब्रूक्स की सबसे अधिक भूल गई थीसिस का भी अनुसरण करता है - कि परियोजना प्रबंधन में "कोई चांदी की गोली नहीं है ! " परियोजनाओं की जटिलता उद्देश्यपूर्ण है, इसे नई प्रोग्रामिंग भाषाओं (यहां तक ​​कि ग्राफिक वाले) की मदद से या कृत्रिम बुद्धिमत्ता से दूर नहीं किया जा सकता है। हर बार नए सिरे से जटिलता का सामना करना पड़ता है, और यदि डिजाइनर की प्रतिभा इसके लिए पर्याप्त नहीं है, तो परियोजना सफल नहीं होगी।

ब्रूक्स परियोजना का मुख्य दुश्मन निर्मित उत्पाद की जटिलता है । नए कोड की प्रत्येक पंक्ति के साथ, तकनीकी दस्तावेज के प्रत्येक पृष्ठ के साथ, यह जटिलता बढ़ती है, और गैर-स्पष्ट रूप से बढ़ती है। और उसी समय, प्रबंधक के पास अपने निपटान में कम संसाधन होते हैं - दोनों समय शेष परियोजना के अंत तक और धन बजट के अंत तक छोड़ दिया जाता है:

चौराहे के बिंदु पर, या इसके तुरंत पहले, यह स्पष्ट हो जाता है कि परियोजना को वास्तव में मूल उद्देश्य से बहुत अधिक धन और समय की आवश्यकता है:

अगली परियोजना, जिसे "प्रहरी" कहा जाता है, एफबीआई ने 2005 में तुरंत शुरू किया। इस मुद्दे की कीमत $ 451 मिलियन है, और प्रहरी प्रणाली 2009 में पूरी तरह से चालू हो जाएगी ... मार्च 2010 में, ठेकेदार लॉकहीड मार्टिन ने परियोजना के केवल आधे हिस्से को पूरा करके और 405 मिलियन खर्च करके वर्ष के लिए देर कर दी थी। स्वतंत्र विशेषज्ञों के अनुसार, इसे पूरा करने में छह से आठ साल और अतिरिक्त $ 350 मिलियन लगेंगे। [३, पी। १ 3-१7]।

लेकिन मुझे करने दो! यदि, 1975 के बाद से, हम जानते हैं कि परियोजनाओं की जटिलता बढ़ रही है, उदाहरण के लिए, द्विघात रूप से, - क्या बजट और टीम को चतुराई से एक ही तरीके से बढ़ने से रोकता है? प्रबंधकों की सभी नई पीढ़ी 30% की अनुमानित सफलता के साथ परियोजनाओं का नेतृत्व करना क्यों जारी रखती है, जब आप सिर्फ पैसा जोड़ सकते हैं ?

अब, अगली पुस्तक पर आगे बढ़ने का समय आ गया है।

दूसरी समस्या: सहयोग की जटिलता

जैसा कि हम पहले से ही जानते हैं, विश्व प्रसिद्ध बेस्टसेलर Peopleware ("स्टाफिंग" रूसी में "ह्यूमन फैक्टर" के रूप में अनुवादित), जो पौराणिक मानव-माह के बारह साल बाद दिखाई दिया, परियोजनाओं की उच्च मृत्यु दर के एक बयान के साथ शुरू होता है। "लगभग पंद्रह प्रतिशत परियोजनाएं कुछ भी नहीं समाप्त हुईं ... बड़ी परियोजनाओं के मामले में, तस्वीर और भी बदतर है, पतन पच्चीस प्रतिशत परियोजनाओं का था जिसकी अवधि पच्चीस व्यक्ति-वर्ष से लेकर थी" [2, p.24] यह 1987 में लिखा गया था (यूएसएसआर अभी भी जीवित था !), 1981 के अध्ययन के संदर्भ में (ब्रेझनेव अभी भी जीवित था); और आज हमारे पास क्या है?

CHAOS रिपोर्ट 2015 [5] के अनुसार

आज औसत डेवलपर की लागत प्रति वर्ष $ 100K है, ओवरहेड को जोड़ने पर, हमें लगता है कि 25 व्यक्ति-वर्ष लगभग 3-6M डॉलर है। जैसा कि आप देख सकते हैं, उन लंबे समय से स्थिति नहीं बदली है : मध्यम आकार की परियोजनाओं का 26% और बड़ी परियोजनाओं का 43% विफलता की उम्मीद करता है, और इसके बारे में हम कुछ भी नहीं कर सकते हैं। लेकिन ऐसा क्यों हो रहा है? डेमारको और लिस्टर ने डेवलपर्स से विफलताओं के कारणों के बारे में पूछा, और यहां उन्हें जवाब में क्या मिला:

“अधिकांश मामलों में, प्रौद्योगिकी के क्षेत्र से विफलता का एक भी कारण नहीं था। अक्सर, हमारे चुनावों में भाग लेने वालों को दुर्घटना के कारण के रूप में "राजनीति" कहा जाता है

यह विकसित किए जा रहे उत्पाद की सारी जटिलता पर नहीं है, और संसाधनों की अपर्याप्तता के रूप में नहीं है, क्योंकि किसी को ब्रूक्स क्रॉस को देखते समय उम्मीद की जा सकती है! "राजनीति", टीम के अंदर और बाहर के लोगों के बीच का रिश्ता (जिसे डेमार्को और लिस्टर ने "समाजशास्त्र" कहना पसंद किया) - यह वही है, जो डेवलपर्स के अनुसार, सफलता को सबसे अधिक रोका।

इस तथ्य के बारे में सोचें: उन्हीं लोगों (डेवलपर्स, बॉस और ग्राहक), जिन्होंने पहली नज़र में, सफलता के लिए सबसे अधिक दिलचस्पी थी, परियोजना की खातिर एकजुट होकर, इसमें "राजनीति" की व्यवस्था की, जिससे परियोजना ध्वस्त हो गई! "हम दुश्मन से मिले, और वह हम हैं" [6]; इस परियोजना का दूसरा सबसे बड़ा दुश्मन है - उनकी अपनी टीम।

यह स्पष्ट रूप से स्पष्ट है कि जितने अधिक लोग एक परियोजना में शामिल होते हैं, उतना ही अधिक समय उन्हें संयुक्त कार्य के आयोजन पर खर्च करना होगा, और कम - वास्तव में एक उत्पाद विकसित करने पर। सवाल यह है कि कितना कम है:

अंजीर। 2 लेख पुतनाम, मायर्स [7] से

कोड की 35 से 95 हजार लाइनों से 491 सॉफ्टवेयर डेवलपमेंट प्रोजेक्ट्स की संख्यात्मक विशेषताओं को एकत्र करने के बाद, पुटनाम और मायर्स ऐसे परिणामों के साथ आए जो विश्वास करना लगभग असंभव है। तुलनीय आकार की परियोजनाओं को लगभग एक ही समय में विभिन्न नंबरों की टीमों द्वारा पूरा किया गया था, और बड़ी संख्या की टीमों को कम नहीं, बल्कि अधिक समय की आवश्यकता थी। ब्रूक्स का कानून ("डेवलपर्स को जोड़ें - परियोजना को धीमा करें") न केवल परियोजना में व्यवधान के खतरे के साथ काम करने के लिए निकला, बल्कि बहुत शुरुआत से , नौवें प्रोग्रामर के अतिरिक्त के साथ शुरू हुआ। यदि आप कुख्यात मानव-महीनों के संदर्भ में समान परिणाम प्रस्तुत करते हैं, तो आपको और भी अधिक अभिव्यंजक अनुसूची मिलती है। विभिन्न नंबरों की टीमों द्वारा एक ही समस्या को हल करने के लिए कितने पैसे (मासिक वेतन में) की आवश्यकता होती है:

अंजीर। 3 लेख पटनम, मायर्स [7] से

मोटे तौर पर प्राप्त डेटा पूरी तरह से शानदार पैटर्न में फिट होता है: किसी टीम में डेवलपर की उत्पादकता उसके आकार के विपरीत आनुपातिक होती है। इस मामले में, विकास की अवधि किसी भी टीम के लिए समान होगी, जो लगभग पुटनेम और मायर्स के डेटा को प्रदर्शित करती है। मानो या न मानो, सभी के व्यक्तिगत संबंध; लेकिन अगर आप इसे नहीं मानते हैं, तो भी आपको यह स्वीकार करना होगा कि राजनीति में बिताया गया समय टीम के आकार के साथ गैर-रैखिक रूप से बढ़ता है - और इसलिए, वास्तव में बड़ी टीमों में काम करने के लिए बहुत कम समय बचा है।

डेमारको और लिस्टर की पुस्तक में "समाजशास्त्र" के कई उदाहरण हैं, जो टीम में "आदेश" को बनाए रखने के काम के साथ परियोजना पर काम को प्रतिस्थापित करता है। अंतरिक्ष कार्यालय खोलें, जहां मालिक देख सकते हैं कि कौन काम से दूर झूल रहा है (और कर्मचारी लगातार एक दूसरे को विचलित कर रहे हैं); विस्तृत योजना और समय सीमा को पूरा करने के लिए निरंतर आवश्यकताएं (जल्दी करो और त्रुटियों की संख्या में वृद्धि के लिए अग्रणी); पेटीएम विनियमन (जो आपको किए गए काम की रिपोर्टिंग और कोड से "कागज के टुकड़े" के लिए कर्मचारी प्रेरणा को स्थानांतरित करने में बहुत समय व्यतीत करता है)। संयुक्त कार्य के संगठन के लिए ये सभी उपाय आवश्यक प्रतीत होते हैं - लेकिन, जब पूरी तरह से लागू किया जाता है, तो वे कार्य के लिए समय नहीं छोड़ते हैं।

अब हम समझ सकते हैं कि "सिर्फ पैसे क्यों जोड़ें" विधि काम नहीं करती है। कार्य के आधुनिक संगठन (खुली जगह, तंग समय सीमा, विस्तृत रिपोर्टिंग) के साथ परियोजना के आकार में वृद्धि से उत्पादकता में उल्लेखनीय वृद्धि नहीं होती है। इसके विपरीत, परियोजना टीम जितनी बड़ी होगी, यह जोखिम उतना अधिक होगा कि यह पूरी तरह से कागजी काम में पूरी तरह से सहमत हो जाएगा कि कौन क्या कर रहा है और किसकी समस्या है। डेमारको क्रॉस परियोजनाओं की प्रभावशीलता को "व्यापक" तरीके से बढ़ाने के प्रयासों का अंत करता है।

लेकिन क्या होगा अगर हम संयुक्त गतिविधियों के आयोजन के सिद्धांतों को बदल दें? डेमारको और लिस्टर ने 1987 में इसे वापस लेने की सिफारिश की: बौद्धिक कार्यों के क्षेत्र में लोगों को प्रभावी ढंग से प्रबंधित करने के लिए, ऊपर सूचीबद्ध लोगों के विपरीत उपाय करना आवश्यक है। [अर्थात विनियमन, मानकीकरण, बर्खास्तगी के दर्द के तहत काम और किसी भी पहल पर प्रतिबंध]। यह मान लिया गया था कि पीपलवेयर में यह स्पष्ट रूप से लिखा गया था कि "विपरीत" उपायों को क्या वास्तव में [, नहीं] जैसा दिखना चाहिए। आइए फिर से देखें परियोजना की सफलता का ग्राफ। और किसी भी प्रबंधक के पढ़ने के लिए अभी भी शामिल पुस्तक से परिणाम कहां है? कुछ देखने के लिए नहीं।

तो क्यों? क्या वास्तव में प्रभावी परियोजना प्रबंधन के लिए सड़क पर एक और क्रॉस है?

तीसरी समस्या: नई योजना बनाने में कठिनाई

पहली नज़र में, सही परियोजना प्रबंधन के लिए तीसरी बाधा रचनात्मक प्रक्रिया को निर्देशित करने के सही तरीके की असामान्य प्रकृति है। इस तरह की एक विधि, जिसे अब आमतौर पर स्क्रम के रूप में जाना जाता है, 1986 में वापस एक लेख [8] में वर्णित किया गया था, यहां तक ​​कि पीपलवेयर की रिलीज से पहले भी। कुछ वर्षों के भीतर, 1993 में, जेफ सदरलैंड ने पहली बार अपनी परियोजना में स्क्रैम के अलग-अलग तत्वों का इस्तेमाल किया, और परिणाम से खुश थे:

हमने बजट के बिना और त्रुटियों की एक न्यूनतम संख्या के साथ, छह महीने के भीतर, समय पर ईज़ील को सॉफ़्टवेयर उत्पाद वितरित किया - इससे पहले कोई भी ऐसा नहीं कर सकता था।

हालाँकि, स्क्रम के मुख्य विचारों का विस्तृत विवरण केवल बीस साल बाद , दूसरे दिन, 2014 [3] में प्रकाशित किया गया था। इस समय, स्क्रम एक अर्ध-संप्रदायवादी पद्धति के रूप में अस्तित्व में था, शिक्षक से छात्र के लिए शाब्दिक रूप से प्रेषित, और विशेष रूप से मुंह के शब्द के माध्यम से लोकप्रियता प्राप्त की। बात यह है कि स्क्रैम की मुख्य अवधारणा, जो सीधे इसके दर्शन से होती है, किसी भी उचित नियंत्रण तर्क में फिट नहीं हुई:

यह वह है जो मैं लगातार नेतृत्व को दोहराता हूं: "मैं केवल समय सीमा का नाम दे सकता हूं जब मैं देखूंगा कि टीम कितनी प्रभावी होगी" (3, पी। 28)।

अगर हम "परियोजना प्रबंधन" से मतलब रखते हैं तो बजट के भीतर समय पर निर्दिष्ट गुणों के साथ एक उत्पाद का निर्माण सुनिश्चित करते हैं, यह पता चला है कि स्क्रैम बिल्कुल भी "प्रबंधन" नहीं है! स्क्रम दर्शन का केंद्र छत से एक "निश्चित समय सीमा" (वास्तविक टीम और इसके प्रदर्शन से अलगाव में) के साथ आने के लिए एक स्पष्ट इनकार है, और इस इनकार का पहला परिणाम परियोजना योजना के लिए एक पूरी तरह से अपरंपरागत दृष्टिकोण है:

मैं कंपनी के प्रमुख के पास गया और कहा कि हम गैंट चार्ट को छोड़ रहे हैं। उसने जो सुना, उससे नाराज होकर उसने स्पष्टीकरण की मांग की।
- आपने अपने पेशेवर करियर के लिए कितने गैंट चार्ट का सामना किया है? मैंने पूछा।
"सैकड़ों के साथ," उन्होंने कहा।
- उनमें से कितने सच थे?
"कोई नहीं," उसने जवाब दिया, एक पल के लिए सोच रहा था।
तब मैंने समझाया कि अनावश्यक ग्राफ़ और तालिकाओं के बजाय, महीने के अंत तक हम उसे पूरी तरह से कार्यात्मक प्रणाली का हिस्सा देंगे, जिसे वह स्वयं परीक्षण करके देख सकेगा कि क्या विकास सही दिशा में है " [3, p.50]

सदरलैंड द्वारा बताई गई कहानी में, बॉस कोशिश करने के लिए तैयार हो गया। लेकिन हम जानते हैं कि "जीवित बचे लोगों की गलती" क्या है, और हम अच्छी तरह से जानते हैं कि ऐसे एक मालिक पर दस हैं जो इस तरह के "प्रोजेक्ट मैनेजर" को भेज देंगे। ईमानदारी से पैसा देने के लिए किस तरह की बकवास, कि "हम काम करेंगे और एक महीने में कुछ दिखाएंगे"? क्या बेवकूफ है?

सदरलैंड की पुस्तक से, हम काफी सटीक रूप से जानते हैं कि कौन सी: वह जिसने पहले से ही परियोजना को एक क्लासिक तरीका बनाने की कोशिश की है, और एक भयावह विफलता का सामना करना पड़ा है। केवल एक नेता एक कोने में संचालित होता है, जिसके पास खोने के लिए कुछ भी नहीं है, प्रबंधन के बुनियादी सिद्धांत को छोड़ने की हिम्मत करता है "संसाधनों - केवल उनके उपयोग की योजना के तहत।" बेशक, स्क्रम का उपयोग करने के बीस वर्षों के बाद, उसके प्रति दृष्टिकोण कुछ हद तक बदल गया है, लेकिन आज भी अधिकांश वार्तालाप "मैं शब्द और राशि का नाम दूंगा जब मैं टीम को इकट्ठा करता हूं और काम करना शुरू करता हूं" इस का जोखिम चलाते हैं।

स्क्रम विचारधारा आम तौर पर परियोजना के बारे में स्वीकृत विचारों के विपरीत है ("ग्राहक भुगतान करने के लिए सहमत है, और ठेकेदार निम्नलिखित कार्य करता है ...") यह सवाल पूछने का समय है: सदरलैंड को इस तरह का क्रांतिकारी कदम उठाने के लिए क्यों मजबूर किया गया था? क्या वास्तव में गैंट चार्ट को "टिक के लिए" छोड़ना और टीम के काम को व्यवस्थित करने पर ध्यान केंद्रित करना असंभव था (उदाहरण के लिए, दैनिक स्टैंडिंग मीटिंग्स में, जिसमें कई स्करम में सबसे महत्वपूर्ण बात देखते हैं)?

उनकी पुस्तक "गैंट चार्ट्स" में जिस सदरलैंड पर हमला हुआ था, उसको देखते हुए, कोई ऐसा नहीं कर सकता:

परियोजनाओं का प्रबंधन करते समय, पारंपरिक रूप से दो चीजों की आवश्यकता होती है - जवाबदेही और पूर्वानुमान। इस तरह के दृष्टिकोण से अनिवार्य रूप से बड़ी मात्रा में प्रलेखन, तालिकाओं और आरेखों का उद्भव होगा ... श्रम के महीने सबसे छोटे विस्तार को सब कुछ प्रदान करने पर खर्च किए जाते हैं, एक भी खराबी को रोकते हैं, वित्तीय संसाधनों को आगे नहीं बढ़ाते हैं और अनुसूची के अनुसार आगे बढ़ते हैं। [३, पृ .२३] एकमात्र परेशानी यह है कि जैसे ही इस पूरी तरह से सम्मानित योजना को वास्तविकता का सामना करना पड़ता है, यह तुरंत धूल में गिर जाता है। लेकिन दोनों योजना को खुद ही और इसके दृष्टिकोण को कचरे में फेंकने के बजाय, प्रबंधक यह दिखावा करते हैं कि योजना काम करती है ... वास्तव में, वे लोगों को झूठ बोलने के लिए भुगतान करते हैं । [३, पृष्ठ २२]

वे उनसे झूठ बोलने के लिए भुगतान करते हैं - यह बात है! ( « ») , . , , (« !»). :

, , , , [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