जटिल विषय क्षेत्र - जवाब के लिए किसे देखना चाहिए?

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

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

सबसे बुरी बात शुरू होती है क्योंकि ऐसे सिस्टम लॉन्च के दिन करीब आते हैं। डिज़ाइन के दौरान की गई छोटी-छोटी त्रुटियां और चूक, 5000 मीटर की गहराई पर कोठरी में पानी के माध्यम से जाने देती हैं।

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

मैं श्रृंखला का थोड़ा गैर-मानक वर्णन करूंगा, नीचे से ऊपर - तकनीकी कार्यान्वयन से आवश्यकताओं तक, और इसके विपरीत नहीं, जैसा कि अक्सर होता है।

भूमिका - डेवलपर

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

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

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

यह ज्ञात है कि बाद में प्रोग्राम कोड में गंभीर बदलाव करने के लिए (हाँ, मुझे प्रोग्रामिंग पैटर्न के बारे में पता है, लेकिन वे सर्वशक्तिमान नहीं हैं), जब यह डीबग किया जाता है, परीक्षण किया जाता है, पाला जाता है - यह न केवल अनिश्चित रूप से वेब प्रोजेक्ट कार्यान्वयन के कार्यकाल को बदलता है, बल्कि मायावी त्रुटियों के साथ सिस्टम को भी बदल देता है। ।

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

हम श्रृंखला को आगे बढ़ाते हैं।

भूमिका - प्रबंधक

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

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

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

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

उपकरण

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

आवश्यकताओं को स्पष्ट करने की प्रक्रिया में, सिस्टम एंटिटीज़ और उनके गुण और संस्थाओं के बीच बातचीत दोनों को स्पष्ट किया जाता है।

यहाँ एक उदाहरण है: "ग्राहक छूट पाने वाले ग्राहकों के समूह से संबंधित हो सकता है।"

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

आपको सभी प्रश्नों का सटीक और औपचारिक उत्तर देना होगा, और इसे डेवलपर पर दोष नहीं देना चाहिए: "प्रोग्रामर ने किसी तरह फैसला किया, वह स्मार्ट है, मुझे नहीं पता कि कैसे।"

जोखिम कम करने के तरीके

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

ऊपर से नीचे तक आवश्यकताओं के प्रवाह को बेहतर बनाने के लिए सूचीबद्ध उपायों के साथ अनुपालन - नाटकीय रूप से सफल होने के लिए एक वेब परियोजना की संभावना में वृद्धि!
सभी को शुभकामनाएँ।