- 100 से अधिक big tech कंपनियों के सर्वे के नतीजे
- big tech की project management शैली को संक्षेप में कहें तो ⇨ "स्थिति पर निर्भर करता है(It Depends)"
- ज़्यादातर जगह कोई तय methodology या काम करने का तरीका नहीं होता, और टीम अपने लिए उपयुक्त तरीका चुनती है
- listed कंपनियों या फंडिंग पाने वाली कंपनियों में dedicated PM होने को लेकर संतुष्टि कम थी, लेकिन बिना निवेश वाली कंपनियों में संतुष्टि अधिक थी
- टीम की autonomy और संतुष्टि में उच्च सहसंबंध है
- जिन टीमों में समस्याएँ थीं, वहाँ वजह methodology से ज़्यादा यह थी कि vision सही तरह नहीं दिखाया गया, या transparency और tools की कमी थी
- JIRA को लेकर ज़्यादातर प्रतिक्रियाएँ नकारात्मक थीं
- project management के वे तरीके जो अच्छे नहीं चले
- engineers प्रोजेक्ट की समय-सीमा के अनुमान में शामिल नहीं थे
- dedicated PM होने के बावजूद requirements बदलती रहीं
- जिन टीमों के पास विफल project management तरीके बदलने की autonomy नहीं थी, उन्होंने कम संतुष्टि दर्ज की
- big tech प्रोजेक्ट कैसे चलाती है
- engineers ज़्यादातर projects को lead करते हैं
- कोई तय methodology नहीं होती, और टीम स्वतंत्र रूप से चुन सकती है
- टीम-स्तर के projects में dedicated Project Manager नहीं होता। कई टीमों या पूरी कंपनी को शामिल करने वाले बड़े projects में Technical Program Manager रखा जाता है। Uber में यह अनुपात लगभग 1:50 है
- first-class developer tools दिए जाते हैं, और इसका छोटे iteration cycles पर बड़ा प्रभाव पड़ता है
प्रोजेक्ट को प्रभावित करने वाली big tech की संगठनात्मक संरचना
- बुनियादी माहौल
- engineers और टीमों को autonomy मिलती है
- वे अचेतन संसाधन (कारख़ाना मज़दूर) नहीं, बल्कि जिज्ञासु problem solvers होते हैं
- आंतरिक data, code और documents पारदर्शी रूप से खुले रहते हैं
- engineers को business और business metrics का भी exposure मिलता है
- hierarchical communication के बजाय engineer-to-engineer communication तेज़ होता है
- कम निराशाजनक developer experience में निवेश किया जाता है
- अधिक leverage को सही ठहराने वाला अधिक वेतन दिया जाता है
- इससे बेहतर प्रतिभा को hire करना संभव होता है
- empowered और autonomous टीमें
- स्पष्ट ownership वाली टीमें
Product Manager हाँ, Project Manager नहीं
- product manager की भूमिका "What game we're playing" और "How we're going to play it" को समझना है
- कई मामलों में big tech कंपनियों के product managers, Project Management नहीं करते
- execution की ज़िम्मेदारी टीम पर होती है, और ज़्यादातर मामलों में project management की ज़िम्मेदारी technical manager (team lead) निभाता है
- empowered और autonomous टीमों में project management का top-down होना दुर्लभ है ⇨ सब मिलकर करते हैं
- dedicated Project Manager न होने पर उठने वाले सवाल
- टीम-स्तर के projects : process को सरल रखना और आपसी रिश्तों को मज़बूत करना
- जटिल projects : big tech कंपनियाँ Technical Program Manager (TPM) रखती हैं
- dedicated Program Manager / Project Manager होते तो हैं, लेकिन वे आमतौर पर बाहरी पक्षों, ग्राहकों और long-term execution planning से जुड़े होते हैं
- product-केंद्रित माहौल और scrum न करने के कारण
- sprint-आधारित scrum, तेज़ी से deploy करने वाली स्थिति के लिए बहुत उपयुक्त नहीं है
- infrastructure और developer tools, scrum की कई activities की जगह ले लेते हैं
- big tech कंपनियों ने समझ लिया है कि infrastructure और developer tools में निवेश productivity बढ़ाता है
- Facebook, Google, Netflix जैसी कंपनियाँ scrum का इस्तेमाल नहीं करतीं। क्यों?
- सक्षम और autonomous लोगों को ऐसी संरचना की कम ज़रूरत होती है
- सक्षम टीमों को काम करने की स्वतंत्रता देने पर उनका leverage बढ़ाया जा सकता है
- engineering organization को scale करना, टीम-स्तर की process से बहुत आगे की बात है
- लेकिन इसका मतलब यह नहीं कि हर किसी को big tech की नकल करते हुए scrum छोड़ देना चाहिए
→ कुछ स्थितियों में scrum उपयुक्त होता है, और अधिक productivity भी दे सकता है
- kitchen sink team : जब एक ही टीम को सब कुछ संभालना पड़ता है (शुरुआती चरण का startup)
- जब नई टीम बनाई जा रही हो
- जब हर कुछ हफ़्तों में एक बार deploy किया जाता हो
- जब project progress की एक समान format वाली रिपोर्टिंग अनिवार्य हो
टीम को कैसे चलाना चाहिए?
- बार-बार होने वाले बदलाव, 'big bang' बदलावों से हमेशा बेहतर होते हैं
- किसी को मछली पकड़कर देने से ज़्यादा कठिन है उसे मछली पकड़ना सिखाना
- directing, mentoring और coaching — तीनों के अपने-अपने उपयोग हैं
- directing वह सहायक micro-managing है, जब व्यक्ति खुद कर सकता है लेकिन किसी वजह से कर नहीं पा रहा हो
- निर्णय लेने के लिए जितने कम लोगों की ज़रूरत होगी, निर्णय उतनी तेज़ी से होगा
- reporting के लिए optimize करना, कम भरोसे वाले माहौल के लिए optimize करना है
- consultants, मापने में आसान नतीजे देने की ओर पक्षपाती होते हैं, क्योंकि वही उनके मूल्य को साबित करने का सबसे आसान तरीका होता है
- सीधे competitors से सीखना कम आंका जाता है
- कुछ बेहतरीन engineers micro-manage होने की बजाय नौकरी छोड़ना पसंद करते हैं
8 टिप्पणियां
"JIRA के बारे में ज़्यादातर प्रतिक्रियाएँ नकारात्मक थीं"
मेरा मानना है कि किसी भी फ़ॉर्मेट में issues को मैनेज करना ज़रूरी है, और मैं खुद भी JIRA को लेकर नकारात्मक था, इसलिए मैंने जानबूझकर कुछ दूसरे tools आज़माए थे (github issues, trello, asana आदि)
लेकिन आख़िर में पुराना ही बेहतर निकला, और मैं फिर से JIRA पर लौट आया...
फिर भी, क्या इससे बेहतर कोई तरीका हो सकता है, इस बारे में मैं लगातार सोच रहा हूँ.
आपको किस बात से लगा कि पुरानी चीज़ें ही बेहतर होती हैं?
मुझे YouTrack पसंद है। यह Jetbrains का बनाया हुआ PM टूल है, और जितनी मुझे ज़रूरत होती है उतना यह प्रोजेक्ट मैनेज कर देता है।
हमारी टीम ने Linear पर स्विच किया, और कुल मिलाकर संतुष्टि काफी बढ़ गई है। मैं आपको इसे एक बार ज़रूर देखने की सलाह दूँगा।
लगता है यह वही प्रोडक्ट है, https://linear.app/. दिलचस्प लग रहा है।
मुझे जो फायदे महसूस होते हैं, वे हैं
मुझे लगभग इतना ही महसूस होता है।
फ़र्स्ट-क्लास डेवलपर टूल आखिर क्या बनाते हैं?
मूल लेख का भाव बनाए रखने के लिए मैंने इसे वैसे ही ले लिया है।
मौजूदा समय में इसे संगठन द्वारा उपलब्ध कराया जा सकने वाला सबसे बेहतरीन developer tool कहा जा सकता है.