20% समय का मुख्य कारण क्षमता उपयोग को 100% के बजाय 80% रखना है।
आप एक सॉफ्टवेयर डेवलपमेंट संगठन के रूप में सोच सकते हैं जो फीचर अनुरोधों को विकसित सुविधाओं में बदल देता है। आप कतारबद्ध सिद्धांत का उपयोग करके इसके व्यवहार को मॉडल कर सकते हैं ।
सिद्धांत
यदि अनुरोध प्रणाली की तुलना में तेजी से आते हैं, तो वे उनकी सेवा कर सकते हैं। जब आवक धीमी होती है, तो कतार का आकार कम हो जाता है। क्योंकि आगमन और सेवा प्रक्रिया यादृच्छिक हैं, समय के साथ कतार का आकार अनियमित रूप से बदलता है।
गणितीय रूप से झुके हुए इस "यादृच्छिकता" के बारे में पूछ सकते हैं: कुछ संभाव्यता वितरण होना चाहिए, इसलिए कतार का आकार औसतन क्या होगा? गणित (पंक्तिबद्ध सिद्धांत) का एक उत्तर है: यदि आगमन और सेवा प्रक्रिया दोनों मार्कोव हैं, तो N = rho ^ 2 / (1-rho)।
(जहाँ rho सेवा और आगमन दर के अनुपात के बराबर उपयोग गुणांक है। यदि प्रक्रियाएँ गैर-मार्कोव हैं, तो गणित अधिक जटिल है, लेकिन निष्कर्ष नहीं बदलता है।)
यदि आप इस फ़ंक्शन को प्लॉट करते हैं, तो आप देख सकते हैं कि औसत कतार की लंबाई कम रहती है जबकि उपयोग 0.8 तक है , फिर तेजी से बढ़ता है और अनंत तक जाता है। आप अपने कंप्यूटर के CPU के बारे में सोचकर इसे सहज रूप से समझ सकते हैं: जब इसका उपयोग 100% तक पहुंच जाता है, तो कंप्यूटर अनुत्तरदायी हो जाता है।
अभ्यास
सॉफ्टवेयर विकास का अर्थशास्त्र ऐसा है कि सॉफ्टवेयर कंपनियां जब बड़ी कतारें लगाती हैं तो बड़ी लागत आती है। इसमें बाजार के अवसरों की कमी, अप्रचलित उत्पाद, देर से परियोजनाएं, और मांग की प्रत्याशा में निर्माण सुविधाओं के कारण अपशिष्ट शामिल हैं।
इस प्रकार 20% का समय आर्थिक परिणामों के अनुकूलन की समस्या का वैज्ञानिक उत्तर है: उपयोग के अनुपात से बचने के कारण उच्च-कतार वाले राज्यों से बचें। यह अनिवार्य रूप से सुस्त है जो सिस्टम को उत्तरदायी रखता है।
कई व्यावहारिक निष्कर्ष तुरंत अनुसरण करते हैं:
- यदि आप 20% समय पर विचार कर रहे हैं और लागत लेखांकन (डेवलपर्स के समय की लागत X है, लेकिन / और कंपनी इसे वहन नहीं कर सकती है), तो आप गलत कर रहे हैं।
- यदि आप हर हफ्ते शुक्रवार को 20% आवंटित कर रहे हैं, तो आप इसे गलत कर रहे हैं
- यदि आप 20% समय परियोजना प्रस्ताव जमा / समीक्षा / अनुमोदन प्रणाली स्थापित कर रहे हैं, तो आप इसे गलत कर रहे हैं
- यदि आप टाइमशीट भर रहे हैं, तो आप इसे गलत कर रहे हैं
- यदि आप 20% समय के लिए एक प्रेरक के रूप में नवाचार का उपयोग कर रहे हैं, तो आप इसे गलत कर रहे हैं। जबकि नए उत्पाद 20% परियोजनाओं से बाहर आ गए हैं, वे बिंदु नहीं थे। यदि आपकी कंपनी अपने मुख्य घंटों के दौरान नवाचार नहीं कर सकती है, तो यह एक समस्या है!
- 20% समय रचनात्मकता के बारे में नहीं है। यह मत कहो कि आप अपनी रचनात्मकता को 20% समय के साथ पूरा करेंगे, पूछें कि आप अपने मुख्य घंटों के दौरान पहले से ही रचनात्मक क्यों नहीं हैं।
टिप्पणी में पूछे जाने वाले प्रश्न
डैन , आपको वह सही और सटीक रूप से कई लोगों द्वारा की गई गलती का वर्णन करता है। आप अपना उपयोग प्रतिशत नहीं चुन सकते, क्योंकि यह एक आउटपुट चर है। यह दो प्रक्रियाओं की विशेषताओं का अनुपात है, इसलिए यह वही है क्योंकि प्रक्रियाएं वे हैं जिस तरह से हैं। एक संगठन का दोनों प्रक्रियाओं पर प्रभाव पड़ता है; मिलान क्षमता और मांग ज्ञान के दुबले सॉफ्टवेयर विकास निकाय द्वारा संबोधित की गई कठिन समस्याओं में से एक है। यूटिलाइजेशन उन संकेतकों में से एक है जो किसी संगठन में इस समस्या को कितनी अच्छी तरह से हल करते हैं। सुस्त होते ही आपकी दुबली पहल आगे बढ़ती है और आप मूल्य धारा से अपशिष्ट को निकालते हैं। लेकिन अगर आप 20% समय जनादेश देते हैं, तो आप कम उपलब्ध क्षमता के साथ उसी उपयोग जाल में समाप्त हो जाते हैं।
किम , यह अभी भी आंशिक रूप से एक संस्कृति चीज है। निकटतम सांस्कृतिक संदर्भ, जिसके बारे में मैं सोच सकता हूं कि संगठनात्मक परिवर्तन के तथाकथित मार्शल मॉडल का तालमेल स्तर है । यह सफल दुबला परिवर्तनों के अंत में उभरता है या शुरू से ही दुबला निर्मित संगठनों में मौजूद है। ( यहां बॉब मार्शल के श्वेत पत्र (पीडीएफ) का लिंक दिया गया है ।)
प्रतिक्रिया दें संदर्भ
उपरोक्त तर्क सॉफ्टवेयर इंजीनियरिंग साहित्य में अच्छी तरह से समर्थित है। मैरी और टॉम पोपेंडीक ने 2006 की अपनी पुस्तक इम्प्लीमेंटिंग लीन सॉफ्टवेयर डेवलपमेंट में इस पर संकेत दिया । अपनी 2009 की पुस्तक प्रिंसिपल्स ऑफ़ प्रॉडक्ट डेवलपमेंट फ़्लो (अध्याय 3) में डोनाल्ड रेनैर्टसेन ने इस विषय को सूत्र और रेखांकन के साथ पर्याप्त उपचार दिया है।