युवा पीओ की 10 गलतियाँ (निष्कर्ष)

और अब 3 मुख्य गलतियाँ। यदि उन्हें बार-बार किया जाता है, तो मुझे डर है कि एक युवा पीओ से आप पूर्व पीओ की भूमिका में जा सकते हैं। यहाँ और यहाँ शुरू करो।


8. आप देव टीम से किसी को भी खारिज नहीं कर सकते
अन्यथा पूरी टीम को ध्वस्त कर दिया जाएगा

हां, शैली के क्लासिक्स में, स्क्रम टीम स्व-संगठित है, और आप "सिंहासन" पर बैठते हैं और बैकलॉग को प्राथमिकता देते हैं। कोई फर्क नहीं पड़ता कि कैसे)

वास्तव में, एक स्व-संगठित टीम समस्याओं पर चर्चा करने से डरती नहीं है, ईमानदारी से टीम के किसी अन्य सदस्य को आवाज़ देती है कि "वास्तव में, हम यहाँ चैट करने नहीं जा रहे हैं।" उदाहरण के लिए, यदि कोई व्यक्ति टीम में दिखाई देता है - एक विलंबकर्ता, तो उन्होंने इस सब पर रेट्रो में चर्चा की, महसूस किया कि "यह काम नहीं करेगा" और " यह स्पार्टा है " शब्दों के साथ ... उसे अलविदा कहा। (मैं ऐसी टीम में काम करना जारी रखना भी नहीं जानता :)

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

मैं अपने अभ्यास से दो मामलों के बारे में बात करना चाहता हूं। हमारी टीम के 2 अच्छे उदाहरण हैं।

• पहला उदाहरण। मजबूर है । डेवलपर ने नियोजन में भाग लिया, सुविधाओं पर चर्चा की, समर्थन किया, निपुण किया, और फिर वह कह सकता था: "दोस्तों, मेरे पास 2 महीने का प्रशिक्षण है।" वह वापस आया, सभी फिर से एक सर्कल में। लेकिन टीम खुद उसे कुछ भी नहीं बता सकती थी, नहीं चाहती थी और चुप थी, और काम का हिस्सा बंद हो गया, पूरी टीम ने इन नियोजित कार्यों पर घसीटा और निश्चित रूप से, ज्यादा समय नहीं हुआ। मैंने इसे लंबे समय तक देखा, डेवलपर के साथ बात की, परिणामस्वरूप, हमने उसे अलविदा कहा। और टीम के स्वास्थ्य के लिए कुछ भी नहीं हुआ, सभी ने कहा: "हाँ, सही निर्णय, लेकिन सामान्य तौर पर पूरी टीम के रूप में इस तरह के निर्णय करना अच्छा होगा" (परिपक्व :))।
• दूसरे का उदाहरण । धनात्मक । डेवलपर को शिथिलता का सामना करना पड़ा, यह पूरी तरह से स्पष्ट नहीं है कि वह क्या कर रहा था। लेकिन रेट्रो पर, टीम ने कहा कि यह अच्छा नहीं था, उन्होंने अपनी टीम के व्यक्ति के पेशेवरों और विपक्षों का वर्णन किया। और आपको पता है क्या? हमें एहसास हुआ कि हम बस एक-दूसरे को नहीं समझते थे। डेवलपर ने एक अलग तरीके से काम करना शुरू किया, वह बहुत कुछ प्रबंधित करता है, बेहतर लिखता है। यह बहुत रेट्रो है। तो कभी-कभी टीम का उद्बोधन भी होता है अगर कोई अच्छा स्कोरर मास्टर होता है जो बात शुरू करने में मदद करेगा।

9. कोई भी व्यवसाय पूरा होना चाहिए।

नहीं, नहीं। सामान्य तौर पर, उत्पाद विकास में एक अत्यंत दुर्लभ चीज को पूरा करने की आवश्यकता होती है। बेशक, अगर यह बहुत ही सही ढंग से परिभाषित किया गया है :)

उदाहरण के लिए, आप एक विशेषता के साथ आए, इसके बारे में झूठ बोला, वह कल्पना में रहती है, प्रोटोटाइप सुंदर है, और उसके पास एक सफेद बॉर्डर वाला नीला बटन भी है। सौभाग्य से, एक जीवन-रक्षक mvp है जो आपको कुछ भी नहीं करने देगा। क्लाइंट को सबसे पहले सभी आवश्यक मिलेंगे, और उसके बाद ही - कुछ आवश्यक, फिर अतिरिक्त और केवल कुछ समय के लिए आत्मा।

कई PO शुरुआती को चिंता होती है कि उन्होंने अपना कोई भी विचार (महाकाव्य) नहीं किया है, इस भावना से उन्हें ऐसे कार्य करने पड़ते हैं जिनसे बहुत कम मूल्य मिलेंगे, लेकिन बहुत सारे संसाधन खर्च होंगे, इस बीच ग्राहक को एक समस्या से जूझना पड़ेगा जो आप जल्दी कर सकते हैं और अभी तय करो।

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

इस तरह से अपने आप काम करेगा यदि कार्यों में एक सटीक वर्णित उपयोगकर्ता कहानी है, तो मैं आकर्षित करूँगा कि यह कैसा दिखता है:



10. काम और डर अपनी नौकरी खो देते हैं

आप एक नई कंपनी में आते हैं / एक स्टार्टअप शुरू करते हैं, लेकिन एक ही समय में आप काम करते हैं और पिछले अनुभव के आधार पर निर्णय लेते हैं। नई वास्तविकताओं में, निश्चित रूप से ऐसे लोग / नियम / राय होंगे जो आपको बताएंगे कि यहां "यह असंभव है ", लेकिन "यह स्वीकार नहीं किया गया है ", और "इस शब्द का बिल्कुल भी उच्चारण न करें।" यह एक उत्पाद पर एक कृत्रिम प्रतिबंध बन जाता है, यह अक्सर अनुमानों, व्यक्तिपरक राय और दूसरों के डर पर आधारित होता है। लेकिन आप यह नहीं जानते हैं, और अपने उत्पाद के चारों ओर कंक्रीट की दीवारों का निर्माण करते हैं, जो वे उसे विकसित नहीं होने देते हैं।

एक उदाहरण है। हमारी टीम ने उत्पाद के लिए सर्वरों के बिना छह महीने बिताए, क्योंकि "ऐसे नियम - यहां हर कोई 6 महीने के लिए सर्वर का इंतजार करता है", उनकी लागत फेरारी एफ 60 अमेरिका जैसी है, और क्लाउड होस्टिंग निषिद्ध है। ठीक है, रुको - तालिका के तहत सर्वर इतना बुरा नहीं है।

एक मौका ले लो, यह कोशिश करो। क्या काम नहीं कर रहा है? फिर से कोशिश करो! या यह पता चलता है कि आपको एक ठोस दीवार नहीं बनानी है या आप इसे तोड़ सकते हैं, या सबसे बुरी बात यह हो सकती है कि आपको पता चलेगा कि इसे ध्वस्त करना वास्तव में असंभव है। लेकिन जिस तरह से आप समस्या के संदर्भ में जितना संभव हो उतना पता लगा लेंगे, आपको समाधान के लिए अधिक विकल्प मिलेंगे। हां, सबसे अधिक संभावना है कि आप किसी को तोड़ने की कोशिश के साथ किसी को गुस्सा करेंगे जो टूट नहीं सकता है। कोई भी आपको उत्पाद और कंपनी के लिए हर संभव प्रयास करने के लिए दंडित नहीं करेगा, और इससे भी अधिक वे आपको आग नहीं देंगे :) पहले तीन बार - निश्चित रूप से। चौथे पर - यह संभव है, लेकिन आपने वह सब कुछ किया जो आप कर सकते थे।

वैसे, अब हम क्लाउड में होस्ट किए जाते हैं, और वर्चुअल मशीन को 1 मिनट में उस मात्रा में तैनात करते हैं जिसमें हम इसे आवश्यक मानते हैं। और मैं अभी भी यहाँ काम कर रहा हूँ :)