प्रोजेक्ट शुरू करने का सबसे अच्छा तरीका क्या है या इसे कैसे बनाया जाए ताकि यह कष्टदायी रूप से दर्दनाक न हो

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

परियोजना की समझ

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

• एक बार का शिल्प एक परियोजना है जिसका उद्देश्य कुछ प्रकार की ग्राफिक अवधारणा और निवेशकों को इसकी आगे की बिक्री करना है। इस प्रकार की परियोजना की विशिष्ट विशेषताएं हैं:
  
  
  1. पागल प्रलेखन। मूल विचार स्पष्ट है, लेकिन व्यावसायिक मामले पूरी तरह से अराजकता में हैं, और विचार करने के लिए कोई तार्किक छेद नहीं हैं।
  2. समय सीमा। प्रलेख लिखने से लेकर प्रोटोटाइप तक 3 महीने तक।
  3. कोई विकास योजनाएं नहीं हैं और न ही किसी अन्य सहायता की योजना है।
  4. छोटी टीम। आमतौर पर 5 लोगों तक, जिनमें डिजाइनर भी शामिल हैं।
  5. व्यावसायिक प्रक्रियाओं का अभाव। सभी बातचीत अराजक है, पारस्परिक संचार, प्रमुख बिंदुओं के स्पष्टीकरण और / या जाने पर आविष्कार के आधार पर।
  6. भूमिकाएँ धुंधली हैं। शक्तियों और जिम्मेदारी के क्षेत्रों का कोई स्पष्ट विभाजन नहीं है।
  7. कोई वास्तविक डेटा नहीं। सभी डेटा "सुंदरता" और सर्वश्रेष्ठ प्रदर्शन के लिए तैयार किए गए हैं।
  8. विकास को गति देने के लिए, बाहरी निर्भरता का पूरा उपयोग किया जाता है।
  
  
• एक स्टार्टअप एक परियोजना है जिसे बाद के विकास के साथ एक विशिष्ट विचार को लागू करने के लिए कॉन्फ़िगर किया गया है। आमतौर पर, इन परियोजनाओं को एक सर्पिल मॉडल के अनुसार विकसित किया जाता है और इस कारण से, पहले प्रकार (एक बार के शिल्प) के रूप में लगभग विशिष्ट विशेषताएं हैं:
  
  
  1. चरणों में स्पष्ट टूट। न्यूनतम: शब्द और कार्यक्षमता की एक सूची जो किसी निश्चित समय में लागू की जानी चाहिए।
  2. अपेक्षाकृत समझदार प्रलेखन। एनालिटिक्स आयोजित, पूरा होने के चरणों के लिए बेंचमार्क, शोधन अक्सर स्प्रिंट के दौरान आते हैं। सबसे अधिक बार झरना का उपयोग करते हैं, इस तथ्य के बावजूद कि एजाइल ने दावा किया था।
  3. मुख्य कार्यक्षमता के लिए औसत समय सीमा। औसतन, 6 से 12 महीने तक।
  4. प्रारंभिक चरणों में, बाहरी निर्भरता का उपयोग किया जाता है, जो अंततः अपने स्वयं के कार्यान्वयन में बदल जाता है।
  5. छोटी टीम। आमतौर पर 7-10 लोग तक।
  6. भूमिकाओं का अलगाव है, लेकिन जिम्मेदारी धुंधली है।
  7. कोई प्रोजेक्ट म्यूट कर सकता है। एक स्तर पर, कार्यान्वयन के लिए अवधारणा या दृष्टिकोण बदल सकता है। आमतौर पर यह निवेशकों की आवश्यकताओं के कारण होता है, शुरू में वास्तुकला में असफल विचार या त्रुटियां।
  8. सशर्त रूप से लाइव डेटा। फ़ोकस समूहों में चलना या तृतीय-पक्ष संसाधनों से लाइव डेटा पार्स करना। सच है, यह हमेशा नहीं होता है ...
  
  
• एक सूचना प्रणाली एक परियोजना है जो तीसरे पक्ष की सेवाओं में एकीकरण की योजना के साथ एक विचार को लागू करती है।
  
  
  1. एक विकास योजना है।
  2. स्पष्ट रूप से लिखित दस्तावेज। न्यूनतम: एपीआई विवरण प्रलेखित।
  3. आपको तृतीय-पक्ष सेवाओं के साथ एकीकृत करने, बैसाखी स्थापित करने या सिस्टम के कुछ हिस्सों को फिर से बनाने की आवश्यकता हो सकती है।
  4. मध्यवर्ती रिलीज़, हॉट फ़िक्स हैं।
  5. मध्यम टीम। आमतौर पर 10 से 20-30 लोग।
  6. जिम्मेदारियों का स्पष्ट पृथक्करण।
  7. सुरक्षा आवश्यकताएँ: विश्लेषण के बाद, ऐसे मामले बनाए जाते हैं जो सिस्टम के पतन का कारण बन सकते हैं।
  8. समय परीक्षण के लिए समर्पित है।
  9. Agile द्वारा उपयोग किया जाता है।
  10. लगभग हमेशा एक बैकलॉग होता है।
  11. केवल बाहरी निर्भरताएं जो अपने दम पर लागू करने के लिए महंगी हैं, उनका उपयोग किया जाता है। यह एक सममूल्य पर मालिकाना लोगों के साथ अभ्यास किया जाता है।
      
  
  
• एक बंद प्रणाली एक स्वैच्छिक परियोजना है जिसे ग्राहक की विशिष्ट आवश्यकताओं को पूरा करने के लिए डिज़ाइन किया गया है, और अधिक परिशोधन के साथ।
  
  
  1. विशिष्ट ग्राहक।
  2. एक विकास योजना है।
  3. विकास के लिए डिजाइन प्रलेखन। उपयोगकर्ताओं की सहायता के लिए, ग्राहक के अनुरोध पर अलग-अलग दस्तावेज लिखे गए हैं।
  4. उपयोगकर्ता अधिकारों का अंतर।
  5. लगभग हमेशा एक बैकलॉग होता है।
  6. टीम का आकार आमतौर पर औसत से बड़ा होता है। एक नियम के रूप में, 10 लोगों से हृदय गति की हानि।
  7. Agile द्वारा उपयोग किया जाता है। समय-समय पर, अतिरिक्त कार्य आते हैं जिन्हें हर कीमत पर लागू किया जाना चाहिए।
  8. अप्रत्याशित प्रदर्शन। मांग वरिष्ठ प्रबंधन के अनुरोध पर होती है, इसलिए एक व्यावहारिक परीक्षण सर्किट कभी भी बेमानी नहीं होगा।
     
  
  
• सास समाधान एक लचीली विन्यास और एक विशिष्ट ग्राहक के लिए आगे अनुकूलन के साथ एक स्वैच्छिक परियोजना है।
  
  
  1. मल्टीमॉड्यूलर सिस्टम। सिस्टम को कई भागों में विभाजित किया गया है। जिसे किसी विशिष्ट परियोजना के दायरे के बाहर भी, व्यक्तिगत रूप से उपयोग किया जा सकता है।
  2. स्पष्ट नियोजन। न्यूनतम: श्रम लागत सुविधाओं के कार्यान्वयन के लिए अनुमानित हैं। आधुनिकीकरण और रीफैक्टरिंग के लिए समय निर्धारित किया गया है।
  3. वॉल्यूमेट्रिक प्रलेखन। लगभग सब कुछ वर्णित है, एक नियम के रूप में, परीक्षण मामलों सहित।
  4. एक नियम के रूप में, कोई बाहरी निर्भरता नहीं है और सिस्टम भागों के अपने स्वयं के कार्यान्वयन लिखे जाते हैं। भले ही थर्ड पार्टी इंप्लीमेंटेशन हो।
  5. कई विकास दल। हर कोई अपने विकास के हिस्से के लिए जिम्मेदार है, चाहे वह समर्थन हो या मोर्चा।
  6. हर चीज और हर चीज का टेस्ट कवरेज। ऑटो, यूनिट, रिग्रेशन और इंटीग्रेशन टेस्ट का उपयोग किया जाता है।
     

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

परियोजना के प्रकार को निर्धारित करने के लिए, नीचे मैंने प्रश्न दिए हैं, जिनका उत्तर प्राप्त करने से यह स्पष्ट हो जाएगा कि वे आपसे क्या चाहते हैं:

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

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

प्रौद्योगिकी चयन

पसंद में यह नियम का पालन करना बेहतर होता है: तकनीक को सुपरनोवा नहीं होना चाहिए, बल्कि पुराना भी होना चाहिए। यदि प्रौद्योगिकी या ढांचा नया है, तो इसके परिणामस्वरूप समस्याएं हो सकती हैं:

• योग्य कर्मियों के लिए खोजें
• विकास की संभावनाएँ: प्रारंभिक अवस्था में, विकास मर सकता है, या, इसके विपरीत, यदि तकनीक पुरानी है, तो बग का इलाज स्वयं करना होगा।
• नए लोगों के लिए टर्नकी समाधानों की कमी, और पुराने लोगों के लिए अपडेट की कमी।
  

समस्याओं की यह सूची न केवल प्रौद्योगिकी के संबंध में, बल्कि तृतीय-पक्ष निर्भरता के लिए भी प्रासंगिक है। उपरोक्त सभी कली में परियोजना को दफन कर सकते हैं।

कुछ विशिष्ट चुनने से पहले, कुछ बार सोचें। परियोजना के लिए महत्वपूर्ण कारकों के साथ लाभों की एक कुख्यात तालिका बनाएं।

यह उदाहरण एक काल्पनिक परियोजना के लिए है:

प्रोजेक्ट की कार्यक्षमता का नाम।	परियोजना महत्व अनुपात
रूपों के साथ काम करें	3
मार्ग	1
एनीमेशन लिखने में आसानी	0.3

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

प्रोजेक्ट की कार्यक्षमता का नाम।	परियोजना महत्व अनुपात	प्रौद्योगिकी 1	प्रौद्योगिकी 2
रूपों के साथ काम करें	3	+	±
मार्ग	1	+	±
एनीमेशन लिखने में आसानी	0.3	+	-

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

आर्किटेक्चर

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

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

अवरोही - डेवलपर्स सिस्टम के बड़े नोड्स से धक्का देते हैं और छोटे वाले पर जाते हैं। वास्तुकला का अर्थ यह है कि प्राथमिकता वाले घटक बड़े नोड होते हैं जिनमें छोटे होते हैं।

आरोही - डेवलपर्स छोटे भागों से धक्का देते हैं और बड़े वाले जाते हैं। वास्तुकला का अर्थ यह है कि पहले तो बहुत सारे छोटे घटक बनाए जाते हैं, और बड़े पहले से ही उनसे इकट्ठे किए जाते हैं।

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

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

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

जैसा कि अभ्यास से पता चलता है, सभी विकास तकनीकों को एक सर्पिल दृष्टिकोण तक कम किया जाता है, जिसमें कार्यक्षमता का क्रमिक निर्माण होता है। मैं इस लेख के ढांचे के भीतर इस पर विचार करना उचित नहीं समझता।

आयोजन

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

जिसके लिए बाद में वे आपको धन्यवाद देंगे

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

निष्कर्ष

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

जब आपके पास एक विकल्प होता है कि किस तकनीक का उपयोग करना, वास्तुकला करना है, और आपको परियोजना के लिए समय सीमा निर्धारित करने की आवश्यकता है, तो नीचे दी गई तालिका आपकी मदद कर सकती है:

प्रोजेक्ट प्रकार / सुविधाएँ	डिस्पोजेबल शिल्प	स्टार्टअप	सूचना प्रणाली	बंद सिस्टम	सास हल	कुछ अन्य परियोजनाएं
5 से कम उम्र के लोगों की संख्या		एक्स	एक्स	एक्स	एक्स
7 से 10 लोगों की संख्या
10 से 30 तक लोगों की संख्या	एक्स
मात्रा 30 से अधिक	एक्स	एक्स
3 महीने तक की पूर्णता तिथि		एक्स	एक्स	एक्स	एक्स
डिलीवरी की अवधि 6 से 12 महीने तक
अवधि 12 महीने से अधिक	एक्स
प्रलेखन
अन्य प्रणालियों के साथ एकीकरण की आवश्यकताएं
विशिष्ट ग्राहक ज्ञात
आगे की योजना बनाई
आयोजन
भूमिकाओं को स्पष्ट रूप से चित्रित किया गया है
बाहरी निर्भरता की अनुमति दी
परीक्षण और विश्लेषण के लिए लाइव डेटा है।
सुरक्षा आवश्यकताओं
परीक्षण आवश्यक है
उत्पाद प्रलेखन या निर्देश की आवश्यकता है
मॉड्यूलर कार्यान्वयन की आवश्यकता है
कई विकास दल
केवल

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