जब डेवलपर "No" कहें, तो पूछने लायक 4 सवाल

• जब डेवलपर No कहते हैं, तो उसका सही तरीके से जवाब देना एक product manager के रूप में अपनी authority दिखाने और goals हासिल करने में मदद करता है
• जब वे कहते हैं कि technical reasons की वजह से किसी feature को दिए गए समय में implement नहीं किया जा सकता, तो सही सवालों के ज़रिए स्थिति को आगे बढ़ाया जा सकता है

1. क्या इस feature को बनाने के लिए कोई दूसरा technical solution हो सकता है?

• किसी feature को बनाने के कई तरीके हो सकते हैं, और पहला तरीका हमेशा सबसे अच्छा नहीं होता
• डेवलपर अक्सर नई technology का इस्तेमाल करके शानदार feature बनाना चाहते हैं, लेकिन इससे simplicity के लिए optimization करने की बजाय over-engineering हो सकती है
• किसी खास technical skill set वाले डेवलपर कभी-कभी अपने knowledge range के बाहर मौजूद आसान solutions को पहचान नहीं पाते
• इसलिए engineer को technical solution के बारे में और ज़्यादा creatively सोचने के लिए प्रेरित करना अच्छा होता है
• जिन बेहतरीन product managers के साथ मैंने काम किया, उनमें से कुछ के पास technical landscape की पर्याप्त समझ और insight थी, जिससे वे engineers से out-of-the-box सोच निकलवाने वाले समझदारी भरे सवाल पूछ सकते थे

2. अगर आपको इन्हीं constraints के भीतर solution देना पड़े, तो आप क्या करेंगे?

• अगर डेवलपर आपके प्रस्तावित solution पर आपत्ति उठाते हैं, तो उनसे उनका solution पूछिए
• डेवलपर creativity और innovation का बड़ा स्रोत होते हैं, और जब आप उनसे feature का कोई simpler version पूछते हैं, तो आप उन्हें रचनात्मक ढंग से सोचने का मौका देते हैं
• जब वे problem का core समझ लेते हैं, तो डेवलपर creatively सोचकर project constraints के भीतर काम करने वाला solution ढूंढ लेते हैं

3. क्या इस feature के लिए phased approach पर विचार किया जा सकता है?

• जब कहा जाए कि technical complexity की वजह से feature implement नहीं हो सकता, तो पूछें कि क्या project को phases में बाँटकर अलग-अलग release dates के साथ आगे बढ़ाया जा सकता है
• एक ही बार में grand vision देने का temptation होता है, लेकिन phased approach ज़्यादा iterative होती है और concrete results जल्दी देती है
• priorities बदल सकती हैं, और phased approach आपको developers के साथ मिलकर यह तय करने देती है कि आगे कौन-सा feature जोड़ा जाए

4. इस काम को संभव बनाने के लिए हम कौन-सी रुकावटें हटा या सुलझा सकते हैं?

• यह resource-based objections पर किया जाने वाला सवाल है; जब डेवलपर limited resources (जैसे समय या उपलब्ध डेवलपर) का हवाला देते हैं, तो उनकी capacity खाली करने के लिए proactively काम हटाया जा सकता है
• संभावित तरीके: काम को पूरी तरह हटाना, ऐसा काम खुद करना जिसमें डेवलपर की ज़रूरत न हो, दूसरी टीमों और/या third parties के साथ communication संभालना, या process की ownership लेकर legacy features को retire करना ताकि काम आसान हो सके

निष्कर्ष

• डेवलपरों के "नहीं हो सकता" पर थोड़ा push back करना असहज लग सकता है, लेकिन इससे आपको ज़्यादा respect मिल सकता है
• engineer किस वजह से oppose कर रहे हैं, यह समझने के लिए थोड़ा गहराई में जाना चाहिए, और फिर उनकी objections को एक-एक करके दूर करना चाहिए
• ये सभी अच्छे सवाल हैं क्योंकि ये इस बात को स्वीकार करते हैं कि किसी खास feature को implement करते समय engineers को unique difficulties और constraints का सामना करना पड़ सकता है
• साथ ही, यह भी साफ़ दिखाता है कि आप team और project की मदद के लिए खुद भी हाथ बँटाने, कठिन काम उठाने, या requirements और timelines के हिसाब से adjust करने के लिए तैयार हैं

[sirotan]

आख़िरकार यह इस बात पर निर्भर करता है कि इसे कैसे coordinate किया जाता है
अच्छी बात है, धन्यवाद
अगर ऊपर की बातों के आधार पर पूछा जाए, तो जो लोग सच में बस करना नहीं चाहते इसलिए No कहते हैं, वे जल्दी ही छाँटे जा सकेंगे

[ddaemiri]

PM/PO के रूप में, जब मैं प्रोजेक्ट में business विभाग और IT विभाग के बीच समन्वय की भूमिका निभाता था, तब दो तरीके मेरे लिए मददगार रहे हैं.
बिल्कुल, इसकी बुनियादी शर्त यह है कि business विभाग हो या IT विभाग, दोनों बात समझने वाले हों.
पहला, काम को चरणबद्ध तरीके से आगे बढ़ाना.
दूसरा, scope को कम करना.
यही दो बातें हैं.
business विभाग या IT विभाग के साथ प्रोजेक्ट चलाने में सबसे बड़ी मुश्किल 'समय' होती है.
समय तय होता है, और अक्सर volume उस समय के भीतर पूरा करना मुश्किल लगता है.
ऐसे में काम को 'चरणबद्ध' किया जाता है. जैसे phase1, 2, 3.. इस तरह क्रमिक schedule में. सबसे महत्वपूर्ण features को phase1 में, कम महत्वपूर्ण चीज़ों को phase2 में.. इस तरह.
लेकिन जो प्रोजेक्ट इस तरह चरणबद्ध नहीं हो सकते, यानी जिन्हें एक ही बार में open करना पड़ता है,
उनमें scope को 'समय' के हिसाब से घटाना पड़ता है. phase 1, 2, 3 में जाने वाली चीज़ों में से 'वास्तव में ज़रूरी features' के अलावा बाकी सब हटाने पड़ते हैं.
इन दो तरीकों पर, अगर business विभाग/IT विभाग बात समझने वाले हों, तो ज़्यादातर सहमत हो जाते हैं.
आख़िर प्रोजेक्ट के पूरी तरह बिगड़ जाने और फिर अपने-अपने बॉस से डाँट खाने से तो यह बेहतर है..
हम्म.
सब हिम्मत रखिए^^

PS:
अंत में एक और छोटा-सा मसाला है.
ऊपर बताए गए ये 2 तरीके अपनाने पर भी, कई बार developers अनिच्छा दिखाते हैं.
तब अगर आप कहें,
"आइए प्रोजेक्ट की समयसीमा के बीच में एक बार check कर लेते हैं. अगर लगे कि और समय चाहिए, तो मैं ज़िम्मेदारी लेकर timeline बढ़वा दूँगा"
तो अक्सर developers के चेहरे खिल जाते हैं.
और फिर जब बीच में check किया जाता है, तो 95% मामलों में अतिरिक्त समय की ज़रूरत नहीं पड़ती थी.
क्योंकि developers एक बार coding शुरू कर दें, तो कई बार काम जल्दी आगे बढ़ जाता है.

[exit55]

डेवलपर्स के साथ समन्वय करने वाली भूमिका में होने के नाते, मैं ऐसे डेवलपर के साथ काम करना चाहूँगा/चाहूँगी जिसके साथ इस तरह की बातचीत संभव हो। अभी तक तो मुझे ज़्यादातर ऐसे डेवलपर ही मिले हैं जो पहले ही कह देते हैं कि यह नहीं हो सकता, और यह बात सच में निराश करती है। इधर-उधर से समझाकर और पूछते-पूछते अक्सर पता चलता है कि ज़्यादातर मामलों में बस कोई ऐसा तरीका था जिसके बारे में उन्हें खुद पता नहीं था..

[abhidhamma]

हाहाहाहाहा... दिल दुख गया..

[bbulbum]

इंजीनियर होने के नाते, "NO" कहने से पहले खुद से पूछने वाले सवाल।

[neidn]

मुझे भी लगता है कि ये ऐसे सवाल हैं जो खुद से पूछना वाकई बहुत अच्छा रहेगा

[evenn33111]

आखिरकार वे engineer होने से पहले इंसान हैं। मैं सहमत हूँ कि engineer के तौर पर आदतन "No" कहना एक समस्या है, लेकिन अगर PM/PO पक्ष के पास ऐसे सवाल हों, तो यह बहुत मददगार हो सकता है।