पारेटो नियम के आसपास जाने का संभावित तरीका

हाय सब लोग

मैं 20/80 समस्या के संभावित समाधानों में से एक पर चर्चा करने का प्रस्ताव करता हूं जो वास्तव में हमारी कंपनी में उपयोग किया जाता है।



कई परियोजना प्रबंधक पेरेटो कानून को जानते हैं (सामान्य रूप में इसे तैयार किया जाता है क्योंकि "प्रयास का 20% परिणाम का 80% देता है, और शेष 80% प्रयास केवल परिणाम का 20% देता है"), हमारे संस्करण में "परियोजना के अंतिम 20% संसाधनों की 80% आवश्यकता है।" सीधे शब्दों में कहें, परियोजना वास्तव में उद्घाटन से 3 दिन पहले शुरू की जा रही है। परिणामस्वरूप: आपातकालीन स्थिति, समय सीमा पूरी करने में विफलता, खराब गुणवत्ता, इधर-उधर भागना, तनाव और PM'a के अन्य सुख।



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



अब, क्रम में:

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

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

• 1 सप्ताह - हम ग्राहक को हस्तांतरण के लिए काम का पहला पैकेज तैयार करते हैं और आंतरिक परीक्षण करते हैं
• दूसरा सप्ताह - हम ग्राहक को पहला पैकेज देते हैं और काम के दूसरे पैकेज को पूरा करते हैं। यह महत्वपूर्ण है कि 1 पुनरावृत्ति में त्रुटि सुधार सर्वोच्च प्राथमिकता के साथ आगे बढ़ता है।
• 3 वें सप्ताह - 1 पैकेज को बंद करें, 2 पैकेज पर त्रुटियों को ठीक करें, 3 पैकेज बनाएं

यदि 4 वें सप्ताह तक अभी भी 1 और 2 पुनरावृति के लिए अपूर्ण कार्य बने हुए हैं, तो आपको उन पर ध्यान केंद्रित करने और 4 पुनरावृत्ति को काम में नहीं लेने की आवश्यकता है।



बोनस जो हमें इस दृष्टिकोण से मिलता है:

• परियोजना की वर्तमान स्थिति और योजनाओं से विचलन की एक स्पष्ट समझ, "कार्य चरण को पूरा करने के लिए क्या किया जाना है" यह समझना (और भुगतान प्राप्त करना)
• "शक्ति संतुलन" को समझना - कलाकार के पक्ष में कितने कार्य हैं, और ग्राहक के पक्ष में कितने कार्य हैं
• महत्वपूर्ण रूप से कम प्रभाव 20/80
• ग्राहक के साथ संबंधों में जोखिम में कमी (काम की डिलीवरी बहुत शुरुआत में शुरू होती है)
• अपने खाते पर नई आवश्यकताओं और विवादों की संख्या को कम करना: यह पता लगाया कि कार्य, किया, पारित किया
• लागत में कमी - 3 महीने के बाद लिखे गए कोड में त्रुटियों को ठीक करने के लिए यह बहुत सस्ता है

हमारा दृष्टिकोण बिल्कुल सत्य होने का दावा नहीं करता है, और सामान्य तौर पर, यह हो सकता है कि यह केवल हमें सूट करे। लेकिन शायद यह लेख किसी के लिए उपयोगी होगा। मुझे सवालों के जवाब देने और 20/80 के अन्य समाधानों पर चर्चा करने में भी खुशी होगी