जब आप किसी स्टार्टअप या बढ़ते प्रोजेक्ट में डेवलपर होते हैं, तो बहुत सारी तकनीकों में महारत हासिल करना और जटिल, उच्च-लोड वाली सेवाएँ बनाना जानना पर्याप्त नहीं होता है। अपने करियर में, मैं कई बढ़ते प्रोजेक्ट में शामिल रहा हूँ और दो स्टार्टअप शुरू से ही बनाए हैं। इस लेख में, मैं विकास के दौरान किन बातों पर ध्यान देना चाहिए और क्यों पूर्णतावाद सबसे अच्छे विचारों को भी खराब कर देता है, इस बारे में अपने अनुभव साझा करूँगा। उपकरण एक साधन हैं, साध्य नहीं हर डेवलपर के लिए, अकेले प्रोजेक्ट लॉन्च करना एक ठोस चुनौती है। यह महसूस करना बहुत स्वाभाविक है कि आपको सब कुछ पूरी तरह से करने की ज़रूरत है। मुझे यह समझने में थोड़ा समय लगा कि पूर्णतावाद की इच्छा अक्सर इस डर का प्रतिबिंब होती है कि सहकर्मी मुझे अतिरिक्त 'प्रिंट' या पैटर्न या टूल का उपयोग न करने के लिए जज करेंगे; और यहाँ, यह होता है: उत्पादन सर्वर बंद हो जाएगा, क्लाइंट शिकायत करेंगे, मुझे निकाल दिया जाएगा, और दुनिया खत्म हो जाएगी। कोई भी उपकरण, पैटर्न या प्रोग्रामिंग भाषा है, कोई लक्ष्य नहीं। अक्सर पूछे जाने वाले प्रश्न: मुझे अभी इसकी आवश्यकता क्यों है? यह क्या प्रदान करेगा? यह किन मेट्रिक्स में सुधार करेगा? उदाहरण के लिए: अभी लिंटर को कॉन्फ़िगर क्यों करें? अभी CI/CD को कस्टमाइज़ क्यों करें? यदि आप दिन में 10 बार परिनियोजन कर रहे हैं, तो संभवतः आपको इसकी आवश्यकता है। यदि आप सप्ताह या महीने में एक बार रिलीज़ परिनियोजित करते हैं, तो संभवतः आपको इसकी आवश्यकता नहीं है। यदि CI/CD अनुकूलन में बहुत समय लगेगा, लेकिन विकास में तेज़ी नहीं आएगी या परियोजना और ग्राहकों के लिए मूल्य नहीं आएगा, तो क्या इसे अभी लागू किया जाना चाहिए? सिर्फ़ एक उपकरण किसी पालतू प्रोजेक्ट में, कुछ नया करने की कोशिश करना समझदारी है: रिपॉजिटरी और कोड की संरचना में लगातार सुधार करना, पैटर्न के साथ प्रयोग करना, वगैरह प्रोडक्शन प्रोजेक्ट का मुख्य लक्ष्य क्लाइंट को मूल्य प्रदान करना है। क्लाइंट कभी नहीं जान पाएंगे कि हम सिंगल कोट्स और सिंगलटन के बजाय डबल कोट्स का उपयोग करते हैं, और कोई हार्डकोड नहीं है। । इस मामले में, हम जो उपकरण लागू करते हैं, वे लक्ष्य हैं। रिफैक्टरिंग केवल तभी आवश्यक है जब इससे विकास की गति और प्रदर्शन बढ़ेगा, बग कम होंगे, या बैकलॉग अनब्लॉक होगा। गुणवत्ता के प्रति प्रतिबद्धता उत्पाद के लक्ष्यों का पीछा करना चाहिए, न कि पूर्णतावाद की आपकी इच्छा। इसलिए, यह याद रखना महत्वपूर्ण है: एक बढ़ते प्रोजेक्ट में एक डेवलपर कभी भी पूर्णतावादी नहीं होता है। व्यवसाय मूल्य पहले आता है किसी बढ़ते प्रोजेक्ट में डेवलपर के लिए, व्यावसायिक मूल्य को समझना आवश्यक है। जब आप एक नियमित डेवलपर होने के आदी हो जाते हैं जो केवल तैयार विनिर्देशों के अनुसार कोड करता है, तो यह पहली बार में चुनौतीपूर्ण हो सकता है। जब उत्पाद का जन्म हो रहा होता है, तो उपयोगकर्ताओं के लिए मूल्य अभी तक सिद्ध नहीं होता है, लेकिन सिद्ध होने वाला मूल्य हितधारक के दिमाग में मौजूद होता है। इस स्तर पर, आप कोडबेस को अनावश्यक तर्क से ओवरलोड करने की गलती कर सकते हैं। उदाहरण के लिए, आपको ऑर्डर हैंडलर लिखने की आवश्यकता है। आप डेटाबेस में ऑर्डर के साथ एक टेबल बनाते हैं और ऑर्डर प्रकारों के साथ एक दूसरी टेबल बनाते हैं, हालाँकि अभी तक केवल एक ही प्रकार है। मान लीजिए कि आप ऐसा इसलिए करते हैं क्योंकि हितधारक जोर देता है कि किसी दिन इस तर्क की जरूरत पड़ सकती है। हकीकत में, इसकी कभी जरूरत नहीं पड़ सकती। अगर अभी उनमें कोई मूल्य नहीं है तो अनावश्यक संस्थाओं को न बनाएं और सबसे महत्वपूर्ण बात यह है कि उस पर व्यवसाय का समय और पैसा बर्बाद न करें। एक उचित प्रश्न पूछा जा सकता है: "क्या मैं किसी हितधारक के साथ बहस करने जा रहा हूँ?" खैर, कभी-कभी आप ऐसा करेंगे। हितधारक विस्तृत विश्लेषण की अपेक्षा करते हैं। बढ़ती परियोजनाओं की विशिष्टताएँ अक्सर संसाधनों की कमी होती हैं, इसलिए डेवलपर्स के पास विश्लेषणात्मक कौशल होना चाहिए। आपको उत्पाद के लिए सुविधाओं के मूल्य को लगातार मान्य करने की आवश्यकता है, क्योंकि इसकी व्यवहार्यता वस्तुतः इस पर निर्भर करती है। यदि आप अपने आपको सीमित रखेंगे, तो व्यवसाय के संसाधन समाप्त हो जाएंगे और आप भंडार को संग्रहित कर देंगे। बहुत सारे सवाल पूछें: "इस सुविधा को अभी क्यों लागू किया जाए? क्या हमें इस समस्या को अभी हल करना चाहिए? क्या यह समस्या मौजूद भी है?" यह ठीक वैसा ही है जैसा कि ऊपर तकनीकों के बारे में बताया गया है। सही सवाल पूछने में सक्षम होना आपकी व्यावसायिकता को दर्शाता है । आपको अपना समय और व्यावसायिक संसाधन केवल उन चीज़ों पर खर्च करने की ज़रूरत है जो वास्तव में आपके ग्राहकों के लिए मूल्य लाती हैं। हैकाथॉन एक बेहतरीन उदाहरण है जो दर्शाता है कि व्यवसाय मूल्य को समझना किस तरह से परिणाम को प्रभावित करता है। सीमित समय के भीतर, एक स्पष्ट रूप से परिभाषित समस्या का एक गैर-आदर्श लेकिन व्यावहारिक समाधान प्रस्तुत किया जाना चाहिए। जब डेवलपर्स प्रोजेक्ट से प्रेरित होते हैं और स्पष्ट रूप से समझते हैं कि वे ऐसा क्यों करते हैं, तो परिणाम 2 दिनों में भी अच्छा आता है। योजना जोखिमों पर निर्भर करती है एक रणनीति गेम की कल्पना करें: आपके पास एक लकड़हारा और एक भर्ती है। लक्ष्य एक योद्धा बनाना है। सबसे पहले, लकड़हारे को लकड़ी इकट्ठा करनी होगी और बैरक बनाना होगा, जहाँ भर्ती सैन्य प्रशिक्षण सीख सकता है। लकड़ी काटने के लिए, लकड़हारे को नक्शे के एक अज्ञात हिस्से से जंगल तक पहुँचने की ज़रूरत होती है। नक्शे से देखते हुए, जंगल तक एक खेल के दिन में पहुँचा जा सकता है, लकड़ी काटने में लगभग आधा दिन लगेगा, और बैरक बनाने में एक सप्ताह लगेगा। इसलिए बैरक लगभग दस दिनों में दिखाई देंगे। लकड़हारे को जंगल में पहुँचने में लगभग एक दिन लग जाता है, लेकिन अचानक नदी रास्ता रोक देती है। लक्ष्य बदल जाता है: हमें दूसरी तरफ जाने के लिए एक बांध, एक पुल या एक नाव बनानी होगी, या शायद कहीं और जंगल की तलाश करना बेहतर होगा। समय से पहले मूल्यांकन करने से रणनीति में विफलता होती है। यदि स्काउट ने पहले नक्शे के किसी अनदेखे हिस्से का पता लगाया होता, तो इस जोखिम से बचा जा सकता था। एक अनुभवी डेवलपर उन जोखिमों को पहचानता है जो हितधारक के लिए स्पष्ट नहीं हैं: तीसरे पक्ष की सेवाओं के साथ एकीकरण, कोड बेस का विस्तार करने की जटिलता, और इसी तरह। जोखिमों का मूल्यांकन करना और उनके बारे में चेतावनी देना आपकी ज़िम्मेदारी है। अधिकांशतः हितधारक इन जोखिमों से अनजान होते हैं, लेकिन वे मूल्यांकन को प्रभावित करते हैं, जो उनके लिए महत्वपूर्ण है। अपनी सेवा को भुगतान सेवा के साथ एकीकृत करना। सबसे पहले, भुगतान सेवा सेट अप करें, पहुँच प्राप्त करें, और जाँच करें कि कहाँ चीजें गलत हो सकती हैं। एकीकृत करने से पहले, समझें कि कैसे एकीकृत किया जाए। विकास के दो या तीन सप्ताह बाद यह पता लगाने की तुलना में शोध पर एक दिन बिताना बेहतर है कि सुविधा समय पर पूरी नहीं हो सकती है या एकीकरण विफल हो गया है क्योंकि भुगतान सेवा ने शर्तों को बदल दिया है या आवश्यक सुविधा के लिए समर्थन अक्षम कर दिया है। एक उदाहरण कार्य: जोखिमों का पता लगाने के बाद, आपको काम की योजना बनानी होगी और कार्य के लिए समय का अनुमान देना होगा। मैं इस ढांचे का उपयोग करता हूँ: परिदृश्य लिखें या उन्हें बोर्ड पर विज़ुअलाइज़ करें: उदाहरण के लिए, उपयोगकर्ता एक बटन पर क्लिक करता है, और दस्तावेज़ डाउनलोड हो जाता है। ऐसे दृष्टिकोण चुनें जिन्हें आप समझते हों। विश्लेषण करें कि स्क्रिप्ट अधिक तकनीकी दृष्टिकोण से कैसे काम कर सकती है। जितने अधिक विकल्प होंगे, उतना बेहतर होगा। मैं विकल्पों का मूल्यांकन करता हूँ और न्यूनतम जोखिम के साथ संभावित रूप से स्केलेबल समाधान चुनता हूँ जो समस्या को सबसे तेज़ी से हल करेगा। परिदृश्यों को तार्किक भागों में विभाजित करें जिन्हें कोडित करने की आवश्यकता है। प्रत्येक भाग का अनुमान दिनों में लगाएँ, और फिर 1.11 गुणांक से गुणा करें। यह मेरा व्यक्तिगत जादुई गुणांक है, जो 11 अक्टूबर को मेरा जन्मदिन है। यह, ज़ाहिर है, एक मज़ाक है (या नहीं)। मेरी सलाह है कि परियोजना के दायरे के आधार पर अनुमान में कुछ अतिरिक्त दिन या सप्ताह भी जोड़ें। जबकि हम यथासंभव अधिक से अधिक जोखिमों का पूर्वानुमान लगाने का प्रयास करते हैं, कुछ का पूर्वानुमान नहीं लगाया जा सकता। सफल न होने की तुलना में चीजों को जल्दी पूरा करना सबसे अच्छा है। बड़ा अनुमान देने से न डरें: जब कोई हितधारक पूछे, "क्या आप इसे तेज़ी से नहीं कर सकते?" तो सिर्फ़ "नहीं" का जवाब न दें, बल्कि इसका कारण भी बताएं। जोखिमों के बारे में बताएं, परिदृश्यों का प्रदर्शन करें और उदाहरण दें। हितधारक को यह समझने की ज़रूरत है कि आपने समस्या का विश्लेषण किया है और सिर्फ़ उसका बेतरतीब ढंग से मूल्यांकन नहीं किया है। महत्वपूर्ण पहलू: आपकी मानसिक स्थिति भी एक जोखिम है। अपनी छुट्टियों की योजना बनाएं और प्रेरित रहने और थकने से बचने के लिए अपने मानसिक स्वास्थ्य पर नज़र रखें: यह आपकी ज़िम्मेदारी है। एमवीपी कोई अंतरिक्ष यान नहीं है यह सवाल मुझे मेरे पूरे करियर में परेशान करता रहा है। सुनने में आसान लगता है - न्यूनतम व्यवहार्य उत्पाद। "MVP कैसे बनाएं?" विकिपीडिया परिभाषा: न्यूनतम व्यवहार्य उत्पाद (एमवीपी) उत्पाद का एक ऐसा संस्करण है जिसमें इतनी विशेषताएं होती हैं कि उसे शुरुआती ग्राहक उपयोग कर सकें और वे भविष्य में उत्पाद विकास के लिए फीडबैक दे सकें। मैंने अक्सर देखा है कि जब आपको MVP बनाने की ज़रूरत होती है, तो कभी-कभी यह अंतरिक्ष यान बनाने जैसा हो जाता है जिसमें बहुत ज़्यादा समय लगता है। MVP चरण में मुख्य लक्ष्य क्लाइंट से त्वरित प्रतिक्रिया प्राप्त करना है और इस प्रतिक्रिया के आधार पर, हितधारक के साथ सहमत होना है कि हम 'सीधे चलें' या 'दाएं मुड़ें।' प्रतिक्रिया एकत्र करने का सबसे अच्छा तरीका मीट्रिक है। अगर वे इसके बिना सफल होते हैं तो यह बहुत अच्छा है, लेकिन अगर ऐसा नहीं होता है, तो कम से कम आपको पता चल जाएगा कि क्यों। मैं आपको अपने पहले MVP के बारे में बताऊंगा। मुझे कई उपकरण और फ्रेमवर्क मिले: मैंने इन सभी का उपयोग करने का फैसला किया क्योंकि ये फ्रेमवर्क बड़ी कंपनियों के अंदर उपयोग किए जाते हैं, और मैंने उनके बारे में सम्मेलनों, व्याख्यानों और YouTube पर सुना। UML, डिज़ाइन पैटर्न, रोडमैप, स्टोरी पॉइंट्स, सिस्टम रिक्वायरमेंट स्पेसिफिकेशन, ADR, UI टेस्ट, और इसी तरह। सेवा का उद्देश्य परीक्षण रन के बारे में डेटा संग्रहीत करना था। मैंने एक साल के लिए एक रोडमैप तैयार किया, में एक विस्तृत आर्किटेक्चर तैयार किया, बैकएंड के लिए एक फ्रेमवर्क चुनने में लंबा समय बिताया, Sentry में परीक्षण और लॉग के लिए एक सिस्टम स्थापित किया, और अपेक्षित 10-15 के बजाय कई उपयोगकर्ताओं पर लोड की गणना की। मैं एक बेहतरीन प्रोजेक्ट बनाना चाहता था। UML पहले संस्करण को पूरा होने में 6 महीने लगे। आप सभी लॉन्च और ग्राफ़ देख सकते थे और रिपोर्ट डाउनलोड कर सकते थे, लेकिन डेटा संग्रह में समस्या थी। सप्ताह में दो या तीन बार एक टूटी हुई रिपोर्ट दिखाई देती थी, जिससे सेवा का उपयोग करना असंभव हो जाता था, लेकिन मैंने हठपूर्वक योजना का पालन किया। अगले कुछ सालों में, मेरे पास कई अलग-अलग प्रोजेक्ट थे और मैंने अपना स्टार्टअप शुरू करने की कोशिश की। मैंने मार्केटिंग, बिक्री और क्लाइंट की परेशानी के बारे में सीखा। इस अनुभव ने मेरी मानसिकता बदल दी और मुझे इस लेख में साझा किए गए तरीकों को विकसित करने की अनुमति दी। मैं हाल ही में किए गए एक कार्य का वर्णन करूँगा ताकि यह प्रदर्शित किया जा सके कि वे व्यावहारिक रूप से कैसे काम करते हैं। मुझे API विधि को गति देने की आवश्यकता थी, जो उपयोगकर्ताओं को इसकी धीमी गति से परेशान करती थी। योजना इसे मोनोलिथ से अलग सेवा में ले जाने की थी, जहाँ आंतरिक सेवाओं और डेटा संरचनाओं के साथ बहुत सारे एकीकरण के कारण कठिनाइयाँ थीं। यह परियोजना प्रायोगिक थी - कोई नहीं जानता था कि त्वरण संभव है या नहीं। बेशक, मैं आगे बढ़कर सब कुछ फिर से लिखने और इसे सही बनाने का सुझाव दे सकता हूँ। मैंने मोनोलिथ और आंतरिक सेवाओं पर शोध करके शुरुआत की और एकीकरण के जोखिमों की जांच की। फिर मैंने मिरो में एक सरल आरेख का उपयोग करके एक रणनीति बनाई, सब कुछ पुनरावृत्तियों में तोड़ दिया, और उसके बाद ही काम करना शुरू किया। समय-समय पर, एकीकरण के साथ कुछ समस्याएँ आती थीं जिनके बारे में सबसे पहले हितधारक को पता चलता था। सबसे पहले, हमने उन्हें हल किया। हाँ, परियोजना में अभी भी तकनीकी ऋण था: लिंटर, अधूरे परीक्षण, डेटाबेस में पुरानी स्कीमाएँ - लेकिन ग्राहकों की समस्या हल हो गई। प्रत्येक पुनरावृत्ति पर, मैंने API विधि के प्रदर्शन के बारे में मीट्रिक्स एकत्रित किए: धीमी गति से और त्रुटियों के साथ, बिना रिलीज के। 2x तेज और त्रुटियों के साथ, बिना रिलीज के। सभी अनुरोधों से 5x, 1% त्रुटियाँ. 6x तेज, बिना किसी त्रुटि के। सभी पुनरावृत्तियों ने लक्ष्य को प्राप्त किया, और चौथे प्रयास में, हमने 100% प्राप्त किया। सब कुछ नए सिरे से लिखने में 10 पुनरावृत्तियों का समय लगेगा, लेकिन कम समय में भी, हमें एक स्केलेबल सेवा मिल गई जिसने समस्या का समाधान कर दिया। एकमात्र प्रश्न दृष्टिकोण का है। एक बढ़ते प्रोजेक्ट में एक डेवलपर का कोडेक्स पूर्णतावाद को छोड़ दें। जबकि दुनिया समस्याओं को हल करने वाली तकनीकों से भरी हुई है, लेकिन लोगों के लिए परियोजनाओं को उपयोगी बनाने के लिए आपको सब कुछ जानने की आवश्यकता नहीं है। जहां संभव हो, पहले से तैयार समाधान का उपयोग करें। व्यावसायिक मूल्य सबसे पहले आता है। उपयोगकर्ता किसी उत्पाद के लिए नहीं आते हैं, वे अपनी समस्या के समाधान के लिए आते हैं। शुरू से ही जोखिमों का मूल्यांकन करें और उन्हें स्पष्ट तरीके से हितधारकों तक पहुंचाएं। अल्पकालिक योजनाएँ बनाएँ। यदि कार्य दो वर्षों से लंबित है, तो संभवतः उपयोगकर्ताओं को इसकी आवश्यकता नहीं है। हर संभव तरीके से फीडबैक और मेट्रिक्स एकत्रित करें। मेट्रिक्स विकास बिंदुओं को खोजने का एक विश्वसनीय तरीका है। स्केलेबल समाधान तब भी प्राप्त किए जा सकते हैं जब शुरुआत में "सही" इंजीनियरिंग पैटर्न का उपयोग नहीं किया गया हो।
