सॉफ़्टवेयर की छोटी इकाइयाँ भेजें और अपनी स्थानीय होस्ट शाखाओं का आकार सीमित करें

पिछले दशक में हैकरनून का नेतृत्व करते हुए, मैंने कई प्रतिभाशाली सॉफ्टवेयर डेवलपर्स के साथ काम किया है, और उनके कार्यकाल की शुरुआत में, मैं आमतौर पर एक ही बात कहता हूं: सॉफ्टवेयर की छोटी इकाइयों को शिप करें और अपनी स्थानीय होस्ट शाखाओं के आकार को सीमित करें। क्यों? यहां दो प्रमुख कारण और एक बड़ा कारण है लेकिन:

1. जब आप परियोजना को पूरा करने की दिशा में काम करना जारी रखते हैं तो उपयोगकर्ता आपके काम से अधिक लाभ उठाते हैं - और उस पर प्रतिक्रिया देते हैं।

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

मेरे पूर्व सहयोगी डेन ल्योंस ने एक बार मुझसे कहा था, "हमें मूल्य की परमाणु इकाइयों को जोड़ना जारी रखना चाहिए और जितनी जरूरत हो उतने रिलीज करना चाहिए।" इससे पहले कि हम इससे खुश हों और आगे बढ़ने के लिए तैयार हों, हम [कार्यक्षमता] पर आसानी से 10 रिलीज़ कर सकते हैं।''

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

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

2. जितना अधिक आपकी शाखा उत्पादन वास्तविकता से भटकती है, टीम के साथियों के लिए आपके प्रोजेक्ट में योगदान देना और आसन्न परियोजनाओं को आगे बढ़ाना उतना ही कठिन होता है।

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

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

अधिक नियमित रूप से छोटे परिवर्तन करके आप दूसरों को योगदान करने के लिए सशक्त बना रहे हैं। उन्हें लगता है कि वे जो भेजेंगे वह भी काम करेगा क्योंकि आप दोनों पहले से ही सहमत हैं कि उत्पादन आधार रेखा क्या है। वृद्धिशील आपका BFF है. यह आपको वास्तविकता से जोड़ता है। यदि वृद्धिशील परिवर्तन उत्पाद पर नकारात्मक प्रभाव डाल रहे हैं, तो आपको क्या लगता है कि उसी दिशा में बड़े परिवर्तन उत्पाद अनुभव पर सकारात्मक प्रभाव डालेंगे?

और बड़ी पुरानी बात यह है: साहसिक परियोजनाओं से डरो मत जो बहुत बड़ी शाखाएँ बन सकती हैं क्योंकि आप एक बुरे व्यक्ति हैं जो इस बात में अंतर लाने में सक्षम है कि यह चीज़ लोगों के लिए कैसे काम करती है।

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