विकास अनुसूची के पीछे अंतराल के कारणों का विश्लेषण करने के लिए पेरेटो चार्ट का अनुप्रयोग

कोई प्रोजेक्ट एक साल पीछे कैसे हो सकता है?
... दिन में "एक बार में"
... फ्रेड ब्रुक्स

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

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

1. उपयोग में आसानी;
2. गणना की गति और किसी भी अतिरिक्त सॉफ़्टवेयर का उपयोग करने की आवश्यकता की अनुपस्थिति। पर्याप्त बग ट्रैकिंग सिस्टम और एक्सेल;
3. डेटा को संसाधित करने की क्षमता "पूर्वव्यापी।" इसका अर्थ है कि यदि कुछ कारक ज्ञात नहीं थे, तो यह हमेशा विश्लेषण के समय दर्ज किया जा सकता है;
4. डेटा की दृश्यता।

नीचे विकास योजना के पिछड़ने के कारणों को निर्धारित करने के लिए पेरेटो ग्राफ के निर्माण का विस्तृत विवरण दिया गया है।

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

- कार्य का गलत मूल्यांकन;
- किसी कार्य को बंद करते समय बग की उपस्थिति के कारण समय समाप्त हो गया।

अगला, आपको उन कारकों की अलग से पहचान करने की आवश्यकता है जो बग पैदा करते हैं। एक उदाहरण के रूप में, हम निम्नलिखित संभावित कारण भी देते हैं:

- कार्य का परीक्षण करने के लिए समय की कमी के कारण एक बग की घटना;
- परीक्षण सुविधाओं की अक्षमता के कारण बग की उपस्थिति (यह एक स्थिति का अनुकरण करना संभव नहीं था);
- फीचर के कार्यान्वयन में त्रुटि (या एक अप्रत्याशित प्रोग्रामर के मामले) के कारण बग दिखाई दिया।

दूसरे चरण में, उल्लंघन के तथ्यों की संख्या की गणना की जानी चाहिए। हमारे उदाहरण के लिए, हम चित्र 1 में परिणाम दर्शाते हैं:

चित्रा 1. तथ्यों की संख्या


तीसरे चरण में, प्रत्येक दिए गए तथ्य के लिए ओवररन की गणना की जानी चाहिए (चित्रा 2)।

चित्रा 2. समय की गणना


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

चित्रा 3. समय कारकों की संख्या को ध्यान में रखते हुए उग आया


अगला, कारकों के प्रभाव को निर्धारित करें। ऐसा करने के लिए, हम इन कारकों की कुल संख्या (स्तंभ 4 में कुल) के संबंध में कारकों की संख्या (4) को ध्यान में रखते हुए समय का प्रतिशत अनुपात मानते हैं। अवरोही क्रम में स्तंभ को क्रमबद्ध करें (चित्र 4)।

चित्रा 4. कारकों का प्रभाव।


अगला कदम कारकों के कुल प्रभाव को निर्धारित करना है। अधिकतम मूल्य वाले पहले कारक के लिए, इसका अपना मूल्य होगा, प्रत्येक बाद वाले के लिए - पिछला प्लस यह खुद (चित्र 5)।

चित्रा 5. कारकों का कुल प्रभाव।


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

चित्रा 6. परेतो ग्राफ


ग्राफ स्पष्ट रूप से प्रत्येक कारण के प्रभाव की डिग्री दिखाता है, और कानून 80/20 (कुल प्रभाव) के अनुसार, परिणाम को प्रभावित करने वाले मुख्य कारक प्रतिष्ठित किए जा सकते हैं। उपरोक्त उदाहरण में, यह 3 कारणों से होता है:
1. कार्य का परीक्षण करने के लिए समय की कमी के कारण बग की घटना;
2. किसी कार्य को बंद करते समय बग की उपस्थिति के कारण समय उग आया;
3. परीक्षण सुविधाओं की अक्षमता के कारण बग की घटना (यह एक स्थिति का अनुकरण करना संभव नहीं था)।

नीचे की रेखा: जैसा कि अभ्यास से पता चला है, टीम के सामान्य मौखिक सर्वेक्षण में लैग के कारणों की हमेशा की तुलना में परेतो चार्ट से प्राप्त परिणामों के साथ मेल खाता है, क्योंकि कारकों का महत्व "आंख से" निर्धारित करना मुश्किल है। इसके अलावा, 80/20 नियम प्रबंधक को परिणामी कारकों को समाप्त करने पर ध्यान केंद्रित करने की अनुमति देता है।

पुनश्च। मुझे उम्मीद है कि पोस्ट उपयोगी था, और विवरण भी विस्तृत नहीं है।