कंपनी के भीतर आईटी उत्पाद आवश्यकताओं का प्रबंधन

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

इस लेख में मैं यह बताना चाहता हूं कि आप इस आने वाली अराजकता के साथ कैसे काम कर सकते हैं।

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

वास्तविक समस्या का पता लगाना

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

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

अंडरवर्ल्ड की अराजकता और अंधेरे को थोड़ा धक्का देने के लिए, हमें यह समझने की जरूरत है कि इन विचारों और प्रस्तावों के पीछे क्या है। जो व्यक्ति आपके पास आया था वह वास्तव में क्या हल करना चाहता है, किस समस्या को बंद किया जाना चाहिए?



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

यह समझना कि किसी व्यक्ति को वास्तव में क्या चाहिए, एक पूरी कला है, जिसके लिए पूरे दृष्टांत समर्पित हैं (उदाहरण के लिए, "व्लादिमीर तरासोव - एक हिरण के करीब पहुंचें"), किताबें (उदाहरण के लिए, "रोब फिट्जपैट्रिक - अपनी मां से पूछें") और व्यावहारिक तीव्रता (उदाहरण के लिए, कस्टम विकास)।

ड्रिल के खरीदार के बारे में पुरानी बाइक

एक आदमी स्टोर में आता है और वहां एक ड्रिल खरीदता है। लेकिन वास्तव में, उसे ड्रिल की आवश्यकता नहीं है, उसे दीवार में एक छेद की आवश्यकता है जिसे वह ड्रिल करना चाहता है। इसलिए, वह एक ड्रिल खरीदता है।

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

यह हमें लगता है कि हम पहले से ही एक मूलभूत समस्या पा चुके हैं। लेकिन नहीं।

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

यही है, एक ड्रिल खरीदना, वह वास्तव में शांति से फुटबॉल देखना चाहता था।

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

इस विशेष क्षण में, एक आंतरिक ग्राहक के साथ काम करना बाहरी ग्राहक के साथ काम करने से बहुत अलग नहीं है।

पहले से मौजूद सुविधाओं के लिए आवश्यकताएँ

जासूसी बाइक।

किसी तरह उन्होंने यह पता लगाने के लिए एक शहर में एक जासूस भेजा कि कारतूस का कारखाना कहाँ है। उन्होंने मदद करने के लिए जानकारी दी कि शहर में एक चर्च है, और यदि आप सीधे चलते हैं और सड़क पर छोड़ दिए जाते हैं, तो कहीं न कहीं उस दिशा में एक कारखाना होगा।

यहाँ शहर में एक जासूस आता है। वह दादी से मिलता है और पूछता है:
- बताइए, चर्च कैसे जाना है?
- लेकिन आप कारतूस का कारखाना देखते हैं? उससे सीधे और फिर दाईं ओर जाएं। एक चर्च होगा।

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

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

हो गया।

डुप्लिकेट आवश्यकताएँ

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

एक उदाहरण:

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

यहां यह स्पष्ट है कि सभी मामलों में, पत्र भेजने के लिए एक प्रणाली की आवश्यकता होती है, और भेजने के लिए कार्य विभिन्न परिस्थितियों में विभिन्न स्थानों से आते हैं।

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

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

परस्पर विरोधी आवश्यकताएँ

ऐसा होता है कि कोई विशेष दो या अधिक आवश्यकताएं एक-दूसरे के विपरीत होती हैं। कभी-कभी "पूरी तरह से", जिसे किसी भी तरह से जोड़ा नहीं जा सकता है। कभी-कभी, फिर भी, "विभिन्न मोड" की परिकल्पना की जा सकती है, जिनमें से प्रत्येक में एक की आवश्यकता पूरी होती है, जबकि दूसरी उपलब्ध नहीं होती है। या समस्याओं में से एक को दूसरे तरीके से हल करें - फिर विरोधाभास गायब हो जाएगा।

एक समाधान की ओर बढ़ने के लिए, आपको "क्यों / क्यों" की श्रृंखला को खोलना शुरू करना होगा। प्रत्येक आवश्यकताओं के लिए (जैसा कि लेख के पहले भाग में वर्णित है)। यही है, हमें यथासंभव गहराई से समझना चाहिए कि वास्तव में ऐसी आवश्यकताएं क्या थीं और इन आवश्यकताओं के साथ आए लोग "वास्तव में" चाहते हैं।

फिर हमारे पास इन "वास्तविक समस्याओं" के लिए या तो अन्य समाधान खोजने का अवसर है, या यह समझने के लिए कि इन परस्पर विरोधी आवश्यकताओं को कैसे जोड़ा जा सकता है।

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

या समझें: इन आवश्यकताओं को किसी भी तरह से जोड़ा नहीं जा सकता है, और आपको एक चुनने की आवश्यकता है। लेकिन, सौभाग्य से, यह अभी भी काफी दुर्लभ है।

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

बॉयलर आवश्यकताओं

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

यानी विचार पूरी तस्वीर को देखने का है। अब जो कुछ भी है और जो वे जोड़ना चाहते हैं, बदल सकते हैं। और इस पूरी तस्वीर के आधार पर यह पहले से ही तय है: क्या, कैसे और कब करना है।


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

परिणाम

यह है कि आने वाली अराजकता आपके सिस्टम के कार्यों और कार्यों के डेवलपर्स के लिए एक सुंदर, उपयोगी और समझ में आती है जो आपके सहयोगियों को प्रसन्न करती है।