वेब विकास में स्क्रम और आवश्यकताओं का प्रबंधन

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

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

स्करम - सभी बीमारियों के लिए एक रामबाण दवा

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

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

आवश्यकताओं को भी प्रबंधित करने की आवश्यकता है

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

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

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

तैयार हो जाओ, उद्देश्य, या

तो काम में शामिल करने के लिए क्या आवश्यकताएं हैं, और कौन सी नहीं हैं? समस्या को स्पष्ट करने के लिए एक सरल सादृश्य का उपयोग किया जा सकता है: एक वेब परियोजना एक सैन्य मिसाइल के साथ एक लक्ष्य को मारने का कार्य है।

आवाज़ के काम पर अधिक विस्तार से विचार करें। मान लीजिए कि राकेट की कार्रवाई के दायरे में कहीं हवा चलती है, रॉकेट लॉन्चर पर है, लक्ष्य को नष्ट करना है। लॉन्च के समय, मार्गदर्शन प्रणाली लक्ष्य के लिए पथ की गणना करती है।



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

रॉकेट प्रक्षेपवक्र की प्रासंगिकता की जाँच एक निश्चित अवधि में एक बार होती है। मान लीजिए कि लॉन्च के कुछ समय बाद, मार्गदर्शन प्रणाली लक्ष्य की स्थिति की जांच करती है और यह पता चलता है कि लक्ष्य ने अपनी स्थिति बदल दी है और रॉकेट गलत दिशा में आगे बढ़ रहा है। मार्ग को समायोजित किया जाएगा।



परियोजना में परिवर्तन एक अलग प्रकृति का हो सकता है, लेकिन विशिष्ट कार्यक्षमताओं के कार्यान्वयन को प्रभावित करता है, उदाहरण के लिए, एक समझ एक सेवा का बेहतर, सरल कार्यान्वयन है।

थोड़ा और समय बीत जाता है, रॉकेट प्रक्षेपवक्र को समायोजित करके अपने युद्धाभ्यास पर प्रतिक्रिया करते हुए लक्ष्य की ओर बढ़ना जारी रखता है।



और फिर, एक योजना का परिवर्तन। इस समय टीम का सामना दुर्गम तकनीकी कठिनाइयों से हो रहा है, सिस्टम के हिस्से को फिर से लिखना आवश्यक है।

और इसलिए, प्रक्षेपवक्र की आवश्यकताओं में कई बदलावों के बाद, रॉकेट लक्ष्य को मारता है।



क्या कोई गारंटी है कि ग्राहक संतुष्ट है? तभी रॉकेट सही निशाने पर लगा।

निष्कर्ष

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

ऑफहैंड दो प्रकार की आवश्यकताओं को अलग करना आसान है:

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

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

वैसे, मैक्सिम कुज़िन पहली बार हवाई जहाज के साथ आए थे। हाय मैक्स!