🌪️ ✌🏼 📮 एक सॉफ्टवेयर परियोजना के लिए आवश्यकताओं का संग्रह

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

और आपको अब और सब कुछ के फैशनेबल बीटा संस्करण कैसे पसंद हैं? जल्द ही विमानों को अल्फा-बीटा संस्करणों में दिखाई देना शुरू हो जाएगा, ऐसा लगता है।

लेकिन आप त्रुटियों के बिना कार्यक्रम कर सकते हैं ताकि आत्मा आनन्दित हो और ग्राहक के साथ बीयर पीना न केवल सुखद हो, बल्कि सुरक्षित भी हो!

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

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

आपको उदाहरणों के लिए दूर जाने की आवश्यकता नहीं है - खुले विकास मॉडल और उनकी सफलता (जरूरी नहीं कि गैर-लाभकारी) दृढ़ता से दिखाए:

स्पष्टता, खुलापन, साहस
समुदाय और ग्राहक के साथ चर्चा
त्वरित समस्या की पहचान और संकल्प

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

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

प्रोग्रामिंग में "पवित्र युद्ध" कहां से आया?

सब कुछ सरल है। यह ज्यामिति के स्कूल पाठ्यक्रम को याद करने के लिए पर्याप्त है। जिस दुनिया में हम रहते हैं, उसकी वैज्ञानिक समझ ... "अपरिवर्तनीय सत्यों" = स्वयंसिद्धों में विश्वास पर आधारित है, उदाहरण के लिए, कि "समानांतर रेखाएँ एक दूसरे को नहीं काटती हैं" या किसी श्रेणी में बहुत से मामले हैं (हालाँकि यह एक प्रमेय है, लेकिन यह कुत्ता काम करता है, लेकिन कोई भी क्यों नहीं समझता है)।

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

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

यहां तक कि प्रतीत होता है कि क्या सरल, अंकगणित हो सकता है, स्वयंसिद्ध क्रम में डालने के लिए बार-बार प्रयास किए गए - लेकिन चीजें अभी भी हैं ...

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

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

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

सख्त / गैर-सख्त टाइपिंग (PHP, जावास्क्रिप्ट, पायथन, रूबी) के साथ गतिशील भाषाओं की दुनिया में, "पूरी तरह से" शब्द से, स्वयंसिद्ध का सेट एकदम सही है, एक और:

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

कार्यात्मक भाषाओं की दुनिया में, जैसे हास्केल / ओकेमेल, आपको यह मानना होगा कि:

किसी भी कार्य को कार्य द्वारा व्यक्त किया जा सकता है
चर, चक्र और परिवर्तनशीलता - त्रुटियों की ओर जाता है (यह वास्तव में ऐसा है)
प्रोग्रामिंग - विश्लेषणात्मक सोच के लिए चयन और इच्छुक के लिए

नतीजतन, सरल बैसाखी स्क्रिप्ट के बजाय "बनाया, जाँच, निर्णय और भूल गया", कार्यस्थल में वास्तविक वैज्ञानिक कार्य शुरू होता है और "ईश्वर के कार्यों" की खोज वेबसाइट को व्यक्त करने के लिए बहुत दिलचस्प है ... चर के बिना कार्यों के एक सेट के साथ, वाह!

बेशक, मैं अतिशयोक्ति करता हूं, लेकिन आग के बिना कोई धुआं नहीं है। हालांकि कुछ कार्यों में यह दृष्टिकोण ठीक काम करता है, और कोई भी बेहतर दृष्टिकोण के साथ नहीं आया है ।

सॉफ्टवेयर परियोजनाओं के प्रबंधन में "धर्मयुद्ध"

परियोजना प्रबंधन के क्षेत्र में, स्थिति और भी अधिक छद्म वैज्ञानिक उदासी से आच्छादित है। और कारण अच्छी तरह से जाना जाता है: एक स्पष्ट, सतह पर झूठ बोलना, माथे के लिए सरल और संक्षिप्त समाधान:

क्लाइंट क्या चाहता है, इसे समझें
विशेषज्ञों को आकर्षित करें और काम की मात्रा का मूल्यांकन करें
कोड लिखें

वास्तव में, किसी कारण से, यह काम नहीं करता है :-)

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

सख्त तर्क और इच्छा की कमी की इन शर्तों के तहत, मुझे अपने इच्छित उद्देश्य के लिए अपने सिर का उपयोग करने के लिए खेद है, जैसे कि छलांग और सीमा के द्वारा, ज्योतिष / अंक ज्योतिष की शैली में भयानक अवैज्ञानिक गालियां उत्पन्न होती हैं और कॉफी के आधार पर भाग्य-कथन।

दुर्व्यवहार का आमतौर पर बहुत आत्मविश्वास से लोगों द्वारा सक्रिय रूप से शोषण किया जाता है जो अच्छी तरह से समझाने में सक्षम होते हैं, जिन्होंने कभी भी "कोड" नहीं रखा (हां, मैं गलत एजाइल के बारे में बात कर रहा हूं)।

वे कहते हैं कि स्प्रिंट से पहले कुछ टीमों में भी सबसे उत्साही प्रशंसक हमें इंजीनियरों को मजबूर करते हैं, मुझे माफ कर देते हैं, मूत्र चिकित्सा :-) हालांकि, ये "अभ्यास" अक्सर बहुत अनुभवी डेवलपर्स द्वारा बनाए जाते हैं जो किसी अन्य की तरह, उनका सही उपयोग नहीं कर सकते हैं।

यहां मैं वास्तव में घोंचू के साथ सादृश्य पसंद करता हूं - यह एक सरल हथियार की तरह लगता है, लेकिन केवल कुछ ही इसे सही ढंग से उपयोग कर सकते हैं, और अधिकांश घायल हो जाते हैं, क्षमा करें, आप जानते हैं कि आप खुद क्या हैं।

एक और मिथक विनिमेयता है

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

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

समस्या यह है कि अब, किसी कारण से, यह किताबों को पढ़ने के लिए नहीं - बल्कि Google को लिखने और उन्हें बंद करने के लिए है, न कि मस्तिष्क सहित, सामाजिक नेटवर्क और स्मार्टफोन सूचनाओं में मानसिक रूप से हस्तमैथुन करते हुए।

एक वास्तविक विशेषज्ञ को खोजना जो व्यवस्थित रूप से नीचे से ऊपर, धीरे-धीरे लेकिन निश्चित रूप से सीखता है, अपने स्वयं के ज्ञान में अंतराल को बंद करना - अधिक से अधिक कठिन होता जा रहा है। बाजार, दुर्भाग्य से, "स्वयं-सिखाया" से भरा हुआ है ... "खराब हुए हाथ।"

क्या करें? अनुशंसित जीवन रक्षा मूल्य

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

हम पहले ऑनलाइन गेम खेलते थे और यह अच्छी तरह से काम करता था - इसलिए आगे बढ़ें, केवल मालिकों के बजाय आपके पास सॉफ्टवेयर प्रोजेक्ट होंगे, और बग के बजाय - ज़र्ग!

यह हमेशा संभव है और आवश्यक रूप से जोखिम का प्रबंधन करने के लिए और अनुभव से, अगर "व्यवस्थित और वैज्ञानिक रूप से" किया जाता है, तो एक सॉफ्टवेयर परियोजना या तो समय पर बंद हो जाएगी, या यह जल्दी से स्पष्ट हो जाएगा कि मिसाइल क्यों नहीं शुरू होती है और क्या / किसके लिए, विशेष रूप से, समस्या।

पूर्वगामी को देखते हुए, यह अनुशंसा की जाती है कि आप निकट-वैज्ञानिक-आनुभविक दृष्टिकोण के निम्नलिखित मूल्यों का पालन करना शुरू करें, जो कि सुविख्यात भजन के साथ सामान्य ज्ञान - " पायथन ज़ेन " और " चुस्त घोषणापत्र " के साथ निकटता से मेल खाते हैं :

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

आवश्यकताएँ संग्रह

सॉफ्टवेयर विकास में प्रवृत्तियों के कुछ रहस्यों और विशेषताओं को जानने के बाद, हम आत्मविश्वास से आगे बढ़ेंगे - हम सीखेंगे कि सिस्टम के लिए आवश्यकताओं को कैसे सही ढंग से इकट्ठा किया जाए।

क्या ग्राहक सिद्धांत रूप में सोचने में सक्षम है?

मजाकिया कुछ भी नहीं - यह अभी भी एक नियमित स्थिति है। और इस संदर्भ में ग्राहक एक सामूहिक अवधारणा है। सबसे पहले, तार्किक सोच के स्तर और ग्राहक प्रतिनिधियों को ध्यान केंद्रित करने की क्षमता का आकलन करने का प्रयास करें। आप किसके साथ काम करने जा रहे हैं और कौन आपकी मदद करेगा? संभावित विकल्प:

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

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

सामान्य शब्दावली
एक तार्किक डेटा मॉडल, जिसमें शब्दावली तत्वों के बीच सख्त बहुलता संबंध पेश किए जाते हैं (एक से एक, एक से कई, कई से कई)
रोल्स और चेन का उपयोग करते हैं जो दिखाते हैं कि सिस्टम का उपयोग कौन करता है और कैसे

अलार्म जो आवश्यकताओं को एकत्रित करने में आसन्न समस्याओं का संकेत करेंगे:

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

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

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

PHP वेबसाइट फ्रेमवर्क के साथ, बॉक्सिंग समाधान
पायथन में भविष्य कहनेवाला विश्लेषण
मोबाइल एप्लिकेशन या तो एक ही प्लेटफ़ॉर्म पर होता है जो हर जगह काम करता है, या हम प्रत्येक डिवाइस के लिए लिखते हैं

समय बर्बाद मत करो!

यदि 2-3 सप्ताह तक, चरम मामलों में, एक और डेढ़ महीने तक, यह भावना पास नहीं होती है कि आप खेल में भाग ले रहे हैं, "स्मार्ट लुक के साथ चैट करें और समय लें और किसी पर सब कुछ डाल दें", स्टॉप क्रेन को खींचें, ट्रेन में आग लगा दें और जोर से चिल्लाएं चिल्लाओ: "घर जाओ, बच्चों! प्रदर्शन खत्म हो गया है। ”

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

चेकलिस्ट

नतीजतन, हम आवश्यकताओं के संग्रह की प्रक्रिया को सफल मान सकते हैं और यह समझ में आता है कि क्या, ग्राहक के साथ मिलकर, आप कुछ हफ़्ते के भीतर निम्नलिखित कलाकृतियों को तैयार करने में सक्षम थे:

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

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

वास्तविक सफलता प्राप्त करने के लिए, सॉफ्टवेयर सिस्टम से प्यार करना बहुत जरूरी है, आवश्यकताओं को पूरा करने के लिए समर्पण और पूरी तरह से डिजाइन करने के लिए समर्पण, शुरुआती शुरुआत की शुभकामनाएं, एक ग्राहक के साथ बीयर पीना, एक दूसरे पर भरोसा करना और लगातार खुद को एदस दिक्स्ट्रा के शब्दों को दोहराना: "सादगी की कुंजी है विश्वसनीयता ”!

सभी के आने के साथ और ईमानदारी से आप सॉफ्टवेयर परियोजनाओं को लागू करने के लिए शुभकामनाएं देते हैं।

एक सॉफ्टवेयर परियोजना के लिए आवश्यकताओं का संग्रह - बिना कटौती के