- कई कंपनियाँ जटिल processes या लंबी-चौड़ी requirements में उलझकर development की गति धीमी कर देती हैं, लेकिन वास्तव में महत्वपूर्ण बात है जल्दी से ‘सही product’ बनाना
- product development process से अनावश्यक चीज़ों को हटा दिया जाए तो product development की गति बहुत तेज़ हो जाती है। सही product बनाना अपने आप में मूलतः एक तेज़ process है
- product team की गति को धीमा करने वाली चीज़ें हैं process, decision makers और executors के बीच की दूरी, ज़रूरत से ज़्यादा specifications जैसी अनावश्यक बातें
[Product Velocity के लिए सिद्धांत]
1. ‘कम करना’ ज़रूरी है
- आम तौर पर speed और quality के बीच trade-off होता है
- ज़्यादातर कंपनियाँ requirements और deadlines तय करती हैं और quality को output की तरह देखती हैं, लेकिन हम उल्टा करते हैं: पहले quality standard तय करते हैं और फिर सोचते हैं कि 60 दिनों के भीतर क्या launch किया जा सकता है
- महत्वपूर्ण यह है कि हर requirement को पूरा करने की कोशिश करने के बजाय, सिर्फ़ महत्वपूर्ण चीज़ों को जल्दी पूरा किया जाए
- requirements हटाकर और सिर्फ़ ज़रूरी काम करके speed और quality दोनों बढ़ाई जा सकती हैं
- Elon Musk भी ऐसा ही approach सुझाते हैं और कहते हैं, “पहले requirements को कम बेवकूफ बनाओ”
2. ‘बेवकूफ मोड’ अक्सर असरदार होता है
- ‘midwit meme’ का उदाहरण लें तो, बहुत समझदार लोग और बेवकूफ लोग सरल समाधान पर सहमत हो जाते हैं, जबकि औसत लोग अनावश्यक रूप से समस्या को जटिल बना देते हैं।
- हम अक्सर ‘बेवकूफ मोड’ में समस्याओं को देखते हैं और ज़्यादा जटिल सोचने के बजाय सरल समाधान ढूँढ़ने की कोशिश करते हैं।
- जब हम गलती करते हैं, तो अक्सर वजह यह होती है कि हमने ज़रूरत से ज़्यादा सोचा; सरल तरीका ज़्यादा बार काम करता है
- “अगर मैं बेवकूफ होता, तो क्या करता?” यह सवाल खुद से पूछने पर अक्सर लागू किया जा सकने वाला समाधान मिल जाता है
3. हर समस्या महत्वपूर्ण नहीं होती
- बहुत कम समस्याएँ वास्तव में बहुत महत्वपूर्ण होती हैं। security जैसी अहम समस्याओं को ज़रूर हल करना चाहिए, लेकिन हर समस्या हल करना ज़रूरी नहीं है।
- उदाहरण के लिए, mobile UI अच्छा नहीं है, लेकिन क्योंकि ग्राहक mobile का लगभग इस्तेमाल ही नहीं करते, इसलिए हम उसे सुधार नहीं रहे हैं।
- इस तरह की समस्याएँ, जिनकी ग्राहकों को बहुत परवाह नहीं है, अनदेखी की जा सकती हैं।
4. बस बनाओ
- हमारे यहाँ product development के लिए कोई process नहीं है। हम Figma mockups, PRD, design system, agile, OKR, स्पष्ट product roadmap, A/B testing, growth hacking वगैरह नहीं करते
- क्योंकि हमारे ग्राहक engineers हैं, हम उम्मीद करते हैं कि हमारे engineers product, design आदि सब संभाल सकते हैं
- हम जल्दी product बनाकर ग्राहकों की प्रतिक्रिया देखने वाला तरीका पसंद करते हैं
5. rewrite ज़रूरत पड़ने पर करते हैं
- कंपनियाँ अक्सर मानती हैं कि technical debt को जितना लंबा टाला जाए, उतनी तेज़ी से आगे बढ़ा जा सकता है, लेकिन हमें ज़रूरत पड़ने पर बड़े पैमाने पर rewrite करने में असहजता नहीं होती
- कभी-कभी सही चीज़ बनाने का सबसे तेज़ रास्ता यह होता है कि पहले गलत चीज़ बनाओ, फिर समझो कि वह गलत है, और उसे सही चीज़ से बदल दो
- अगर technical debt हटाना उपयोगी लगता है, तो हम ऐसा करेंगे
6. जहाँ संभव हो, outsource करो
- जहाँ संभव हो, in-house बनाने के बजाय हम बाहरी vendor का solution खरीदते हैं। उदाहरण के लिए, हम Fern नाम की कंपनी के ज़रिए SDK generate करते हैं
- बेशक, vendor का उपयोग करने में काफ़ी upfront cost आती है और flexibility भी सीमित होती है, लेकिन आम तौर पर यही सही चुनाव होता है
- हमारे engineering resources बहुत सीमित और महंगे हैं; एक engineer के एक हफ़्ते के समय की लागत लगभग 5,000 डॉलर है। opportunity cost जोड़ें तो इसकी कीमत इससे भी कहीं ज़्यादा है
- वास्तव में ऐसी चीज़ें अपेक्षाकृत कम हैं जिन्हें खुद बनाना सच में सार्थक हो
7. hiring मत करो
- हमें यह उम्मीद नहीं है कि लोगों की संख्या बढ़ाने से team output बढ़ ही जाएगा। hiring धीमी और कठिन है, और onboarding व people management समय लेते हैं
- खासकर ऐसे सक्षम लोगों को लाना मुश्किल होता है जो बहुत ज़्यादा support के बिना योगदान दे सकें
- इसलिए, भले ही हमारे पास बड़ा engineering team बनाने के resources हों, हम उसे छोटा बनाए रखने की पूरी कोशिश करते हैं। इससे जीवन बहुत आसान हो जाता है
समापन विचार
- हमने यह महसूस किया कि product development को उतना समय नहीं लगना चाहिए, जितना हम पहले समझते थे
- अगर आपको पता है कि ग्राहकों को क्या चाहिए, आपके पास मजबूत team है, और आप ध्यान भटकाने वाली अनावश्यक चीज़ों को हटा देते हैं, तो आप बहुत तेज़ गति से product विकसित कर सकते हैं
10 टिप्पणियां
मैं भी फिर से देखने आया हूँ। अगली बार फिर मिलते हैं।
बार-बार पढ़ने पर भी अच्छा लगता है।
?? यह काफ़ी आदर्शवादी है
आउटसोर्सिंग के मैनेजमेंट की लागत और उसमें लगने वाले resources भी कम नहीं होंगे... फिर भी कुल मिलाकर यह बेहतरीन सलाह है।
हमेशा कहा जाता है कि आउटसोर्सिंग का इस्तेमाल करो। लेकिन आउटसोर्सिंग का इस्तेमाल करते समय क्या करना चाहिए, इस बारे में शायद ही कुछ देखने को मिलता है.
अगर किसी स्पष्ट service picture के बिना सिर्फ एक साधारण खाका ही सौंप दिया जाए, तो यह समझ भी नहीं आता कि बदले में उम्मीद से कहीं ज़्यादा खराब चीज़ें मिल सकती हैं....
???: इसे तेज़ बनाइए, लेकिन agile मत बनाइए
मुझे लगता है कि यह तब संभव है जब product स्पष्ट हो
जब करना क्या है यह साफ़ हो, तो उससे ज़्यादा design की ज़रूरत नहीं होती — कुछ ऐसा सा एहसास
"पहले requirements को कम बेवकूफ़ बनाओ"
अगर आउटसोर्सिंग करने वाली कंपनी किसी दिन अचानक गायब हो जाए... फोन भी न उठाए, तो बहुत दुख होता है
क्या अंदरूनी डेवलपमेंट में भी, अगर किसी दिन सब लोग नौकरी छोड़ दें, तो स्थिति लगभग ऐसी ही नहीं होगी..?