Big Tech में प्रोजेक्ट Ship करने का तरीका

रिलीज़ (Shipping) मुश्किल क्यों है

• बहुत से लोग गलती से मान लेते हैं कि ‘रिलीज़’ करना आसान काम है, लेकिन डिफ़ॉल्ट स्थिति यह होती है कि रिलीज़ देर से होती है, रद्द हो जाती है, या कम गुणवत्ता के साथ समस्याएँ पैदा करती है।
• सारा कोड लिख देने या सभी Jira tickets बंद कर देने से अपने-आप रिलीज़ नहीं हो जाती। रिलीज़ के लिए किसी को lead की भूमिका लेनी पड़ती है।
• रिलीज़ सबसे उच्च प्राथमिकता वाला काम होना चाहिए। user experience (UX) पर ज़रूरत से ज़्यादा ध्यान देने से उल्टा रिलीज़ में देरी होती है।
• किसी प्रोजेक्ट को सफलतापूर्वक रिलीज़ करने के लिए एक technical leader या DRI (Directly Responsible Individual) की ज़रूरत होती है। जिन टीमों में यह भूमिका निभाने वाला engineer होता है, उनकी सफलता की संभावना ज़्यादा होती है।

‘रिलीज़’ क्या है?

• कई engineers ‘रिलीज़’ को सिर्फ code deploy करने या feature enable करने के रूप में देखते हैं, लेकिन बड़ी tech कंपनियों में इसकी परिभाषा अलग होती है।
• रिलीज़ तब मानी जाती है जब कंपनी के भीतर महत्वपूर्ण लोग मान लें कि यह ‘रिलीज़ हो चुकी है’। अगर VP या CEO संतुष्ट नहीं हैं, तो code deploy हो जाने के बाद भी वह वास्तव में ‘रिलीज़’ नहीं मानी जाती।
• अगर कोई प्रोजेक्ट users के बीच बड़ी सफलता हासिल करे या revenue लाए, तो उसे रिलीज़ माना जाता है; लेकिन users की प्रतिक्रिया अच्छी न होने पर भी अगर leadership संतुष्ट है, तो उसे रिलीज़ माना जा सकता है।

कम्युनिकेशन का महत्व

• प्रोजेक्ट का लक्ष्य क्या है, यह स्पष्ट रूप से समझना ज़रूरी है। लक्ष्य के अनुसार काम करने का तरीका और कम्युनिकेशन रणनीति बदलती है।
• कंपनी की leadership को प्रोजेक्ट की technical details लगभग पता नहीं होतीं। इसलिए trust बनाए रखने के लिए सही estimates, समस्या-समाधान, और उचित updates महत्वपूर्ण हैं।
• trust बनाए रखने के तरीके:
• अगर पहले सफल रिलीज़ का अनुभव है, तो यह फ़ायदेमंद होता है।
• आपको आत्मविश्वास भरा रवैया दिखाना चाहिए।
• NASA के mission control की तरह पेशेवर और संक्षिप्त ढंग से संवाद करना चाहिए।
• daily या weekly update threads के ज़रिए proactively जानकारी देनी चाहिए।

production deploy की समस्याओं का समाधान

• ज़्यादातर समस्याएँ अप्रत्याशित details में पैदा होती हैं। उदाहरण के लिए, Memcached के block size की समस्या, traffic prediction की गलती, या sensitive user data से जुड़ी समस्या हो सकती है।
• समस्याओं को तेज़ी से हल करने के लिए system की गहरी technical समझ ज़रूरी है।
• संभावित समस्याओं पर तेज़ी से प्रतिक्रिया देनी चाहिए, और यह साफ़ समझा पाना चाहिए कि समस्या गंभीर है या नहीं।

क्या इसे अभी तुरंत रिलीज़ किया जा सकता है?

• खुद से यह पूछना महत्वपूर्ण है कि क्या इसे अभी तुरंत रिलीज़ किया जा सकता है। अगर नहीं, तो यह सोचना चाहिए कि क्या बदलना होगा ताकि यह संभव हो सके।
• feature flags और staging environment का उपयोग करके जितनी जल्दी हो सके feedback लेना चाहिए।
• रिलीज़ से ठीक पहले technical काम कम कर देना चाहिए, और समस्या होने पर तेज़ी से प्रतिक्रिया देने की तैयारी रखनी चाहिए।

सारांश

• रिलीज़ करना बहुत कठिन काम है, और इसे सर्वोच्च प्राथमिकता देनी चाहिए।
• रिलीज़ का मतलब सिर्फ deploy करना नहीं, बल्कि leadership team का संतुष्ट होना है।
• leadership team का trust जीतना सफल रिलीज़ की कुंजी है।
• समस्याओं का अनुमान लगाकर उनसे निपटने के लिए backup plan महत्वपूर्ण है।
• रिलीज़ से ठीक पहले development work कम करके समस्या-समाधान पर ध्यान केंद्रित करना चाहिए।
• हमेशा यह सवाल पूछना चाहिए: “क्या इसे अभी तुरंत रिलीज़ किया जा सकता है?”
• डर छोड़कर साहस रखना चाहिए।

[GN⁺]

Hacker News राय

• यह अवलोकन प्रभावशाली है कि "Shipping" कंपनी के भीतर एक सामाजिक संरचना है। जब महत्वपूर्ण लोग मान लेते हैं कि प्रोजेक्ट पूरा हो गया है, तभी वह पूरा माना जाता है
• यह लेख software deployment के बारे में नहीं, बल्कि executives को संतुष्ट करने के बारे में है। अगर users इसे नापसंद करें और बाज़ार इसका मज़ाक उड़ाए, फिर भी executives खुश हों, तो इसे shipped माना जाता है
• जैसे खेलों में जीत सभी समस्याएँ हल कर देती है, वैसे ही software में shipping सभी समस्याएँ हल कर देती है। कोई भी product परफेक्ट नहीं होता, लेकिन अगर जल्दी ship किया जाए तो users संतुष्ट हो सकते हैं
• कभी-कभी समस्याओं को रोकने वाले engineers की तुलना में समस्याएँ हल करने वाले engineers को अधिक पहचान मिलती है। लोग समस्याएँ रोकने की कोशिश करते हैं, लेकिन leaders हमेशा इसे पहचान नहीं पाते
• बड़ी कंपनियों में "deployment" को केवल feature को वास्तविकता में बदलने के रूप में नहीं, बल्कि बड़े संदर्भ में समझना चाहिए। कुछ लोग इसे अनैतिक कह सकते हैं, लेकिन बड़ी कंपनियों में यह एक तरह का "game" है
• मैंने बहुत से projects ship किए हैं, लेकिन ठोस उदाहरण न होने से इस पर भरोसा करना मुश्किल है। अगर वास्तविक project examples शामिल होते, तो इसे समझना आसान होता
• यह लेख self-promotional blog spam है
• यह अनुभव से मेल खाता है, लेकिन इसमें व्यावहारिक सलाह की कमी है। leadership से मान्यता पाने के ठोस उदाहरणों की ज़रूरत है
• यह बड़ी कंपनियों के मेरे अनुभव से अलग है। executives के समर्थन के बिना भी, अगर user feedback या metrics सकारात्मक हों, तो इसे सफलता माना जाता है। छोटे projects भी मूल्यवान हो सकते हैं
• दावों को संख्यात्मक और गुणात्मक दोनों तरह से प्रस्तुत किया जाना चाहिए ताकि उन पर भरोसा किया जा सके। "बड़ी टेक कंपनियों में ship करना" एक बहुत व्यापक कथन है, और इसके लिए ठोस व्याख्या चाहिए

[signaling]

कुछ प्रभावशाली टिप्पणियों के अंश चुने हैं।

“कुछ लोग सिर्फ अपने लिए तकनीकी क्षेत्र बनाना चाहते हैं, या किसी भी स्तर पर अपने से ऊपर बैठे लोगों से प्रशंसा पाना चाहते हैं। यही वह तरीका है जिससे "खेल खेला जाता है"। इस खेल को खेलना आखिरकार संगठन की मौत की ओर ले जाता है, और यही कारण है कि हमारे पास शुरुआत से ही corporate life cycle जैसी चीज़ होती है। अंततः ऐसे लोग संगठन को अंदर से तोड़ देते हैं, और जिन लोगों के पास सचमुच विचार होते हैं या जो वास्तव में काम पूरा करने के लिए optimized होते हैं, उन्हें बाहर धकेल देते हैं।”

“खेल में जीतने का तरीका है खेल को न खेलना।”