ब्लडसुकेर्स बॉस ऑफ कॉनटेक्स्ट या व्हाई वे ऑलवेज फेल

मेरी राय में, "प्रसंग में बॉस ऑफ ब्लडसुकर्स ..." लेख ने स्व-शासी टीमों के टूटने का कारण नहीं बताया था, लेकिन इसका कारण उत्पाद के लिए आवश्यकताओं के वितरण की कम गति थी, और यह समझने की कमी थी कि नेता हमेशा टीम का हिस्सा होता है।

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

क्लासिक डिजाइन

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

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

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

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

फिर यह कैसे सुनिश्चित करें कि ग्राहक आवश्यकताओं को बहुत बार नहीं बदलता है, और ठेकेदार समय पर ग्राहकों की सभी आवश्यकताओं को पूरा करता है?

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

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

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

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

अंतिम लक्ष्य को प्राप्त करने के लिए रास्ते से नहीं भटकने के लिए, टीम हर दिन 15 मिनट की रैलियों के लिए इकट्ठा होती है, जिस पर टीम का प्रत्येक सदस्य तीन सवालों के जवाब देता है:

1. पिछली बैठक के बाद से क्या किया गया है?
2. अगली रैली के लिए क्या किया जाएगा?
3. क्या समस्याएं हैं?

मामले में जब योजना को विकास से अलग किया जाता है, तो दूसरे प्रश्न का उत्तर परियोजना प्रबंधक द्वारा दिया जाता है, हालांकि, तीसरे के उत्तर के रूप में।

प्रत्येक पुनरावृत्ति (स्प्रिंट) के अंत में, टीम ग्राहक को नई कार्यक्षमता के साथ उत्पाद दिखाती है। प्रत्येक प्रदर्शन के बाद, टीम ग्राहक से अलग होकर एक पूर्वव्यापी आचरण करती है। रेट्रोस्पेक्टिव को संचालित करने के लिए बहुत सारे तरीके हैं, मैं "प्लस / DELTA" शैली में एक पूर्वव्यापी को नोट करना चाहता हूं, जिसमें प्रत्येक टीम के सदस्य 10 सकारात्मक बिंदुओं (प्लस) और दस बिंदुओं को व्यक्त करते हैं जिन्होंने टीम को लक्ष्य बनाने से विचलित (DELTA) किया।

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

निष्कर्ष निकालना

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