प्रभावी उत्पाद टीम कैसे बनाएं?

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

एक प्रभावी उत्पाद टीम क्या है, इसे कैसे बनाया जाए और इसके लिए क्या किया जाना चाहिए ताकि टीम के सभी सदस्य प्रक्रिया में अधिकतम रूप से शामिल हों, हमने विशेषज्ञों से एक पैनल चर्चा में बात की जो हमारे कार्यालय में हुई थी। हमारे साथ, रोमन अब्रामोव (CarPrice उत्पाद निदेशक और ProductStar के संस्थापक), मिखाइल अलेक्जेंड्रोव्स्की (संस्थापक Dostavista), अन्ना बोयरकिना (उत्पाद Miro के प्रमुख), Ilya Krasinsky (CEO Rick.ai), माइकल यान (सीईओ ManyChat) द्वारा सवालों के जवाब मांगे गए थे। । कट के तहत विवरण।



8 अगस्त को, मानटच के कार्यालय में एक पैनल चर्चा हुई, जिस पर उन्होंने एक प्रभावी उत्पाद टीम बनाने के विषय पर चर्चा की जो कई कंपनियों के लिए प्रासंगिक है। आमंत्रित विशेषज्ञ थे

• रोमन अब्रामोव, CarPrice उत्पाद निदेशक और ProductStar के संस्थापक
• मिखाइल अलेक्जेंड्रोवस्की, संस्थापक दोस्तविस्टा
• एना बॉयरकीना, हेड ऑफ प्रोडक्ट मिरो
• Ilya Krasinsky, Rick.ai के सीईओ
• माइकल यान, ManyChat के सीईओ।

बैठक का संचालन लामोदा समूह के उत्पाद निदेशक किरा माटेव्वा ने किया था। चर्चा के दौरान, हमने चर्चा की कि कौन से उपकरण और प्रक्रियाएं मौजूद हैं, कैसे एक टीम को एकजुट करना और निर्देशित करना, कर्मचारियों को बढ़ने और विकसित करने में मदद करना, प्रेरणा बनाए रखना, पंप कौशल, और दर्शकों के सवालों के जवाब भी दिए।

उन लोगों के लिए जो विशेष रूप से व्यक्तिगत उपस्थिति के प्रभाव की सराहना करते हैं, हम प्रसारण रिकॉर्डिंग देखने का सुझाव देते हैं । बाकी सभी के लिए - चर्चा का एक विस्तृत प्रतिलेख। अच्छा पढ़ लो!

उत्पाद टीम क्या है, गैर-उत्पाद टीम से इसका अंतर क्या है?

रोमा:

एक उत्पाद टीम एक टीम है जो एक उत्पाद को देखती है, सबसे अधिक संभावना ऑनलाइन। मेरी समझ में, इसमें डेवलपर्स, परीक्षक, विपणक, डिजाइनर (विशेष रूप से) शामिल हो सकते हैं। ये सिर्फ उत्पाद नहीं हैं। उत्पादों का कार्य इस टीम का नेतृत्व करना और व्यवस्थित करना है। ताकि वे एक साथ अच्छा महसूस करें, और यह सब एक परिणाम की ओर ले जाता है।

इल्या:

चलिए होलीवर को तुरंत जोड़ते हैं ताकि यह उबाऊ न हो: जब हर कोई हर किसी के साथ सहमत हो। मैं हमेशा बमबारी करता हूं जब उत्पाद टीम "उत्पाद को देखती है।" वैसे, टीम कर्मचारियों से अलग है कि टीम के सदस्य एक लक्ष्य से एकजुट हैं। मुझे उन टीमों से प्यार है जो पैसे के लिए जिम्मेदार हैं, और फिर यह पता चलता है कि जिस समय आपको उत्पाद को काटने की जरूरत नहीं है, उसका 60%। इसके विपरीत, अनावश्यक को इससे बाहर फेंकना आवश्यक है।

माइकल:

चलिए होलीवेरिट जारी है। मैं इस बात से सहमत नहीं हूं कि टीम पैसे के बारे में है। यह कुछ उत्पाद मैट्रिक्स के बारे में है। उत्पाद और गैर-उत्पाद टीम अलग-अलग हैं, गैर-उत्पाद टीमों के पास गैर-उत्पाद मीट्रिक में लक्ष्य हैं। और कुछ नहीं।

माइकल:

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

Anya:

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

टीम संरचना, भूमिकाएं और संगठन के प्रकार। टीम में कौन हो सकता है, और जिम्मेदारी के क्षेत्र कौन से हैं?

Anya:

मुझे लगता है कि यह बताना दिलचस्प है ... एक समय में, हमने टीम को एक मूल (कोर) उत्पाद और एक विकास टीम की टीम में विभाजित करने का फैसला किया। कहीं-कहीं 3-4 साल पहले, जब हमने कार्यों को प्राथमिकता दी, तो हमेशा हितों का टकराव होता था: हम उत्पाद कार्यक्षमता के विकास में या प्रयोगों में क्या निवेश करते हैं। मूल्य बनाना या इसे स्केल करने की कोशिश करना? इस चरण में काम करने वाले शांत समाधानों में से एक (मैं यह नहीं कह रहा हूं कि यह हमेशा ऐसा ही रहेगा): एक अलग टीम को विकास के लिए आवंटित किया गया था। आपको यह समझने की आवश्यकता है कि हमारे पास पूरा व्यवसाय दो सशर्त भागों में विभाजित है: लाभ का हिस्सा स्वयं सेवा से उत्पन्न होता है, जब कुछ लोग आते हैं और एक उत्पाद खरीदते हैं, और एक बिक्री विभाग के साथ एक मानव-स्पर्श व्यवसाय भी है। यह स्व-सेवा में है कि विकास दल काम करता है और नए उत्पादों के लिए GoToMarket (लगभग। GoToMarket - बाजार में प्रवेश) प्रदान करता है। उत्पाद प्रबंधकों, डिजाइनरों, डेवलपर्स: टीम में 20-22 लोग कार्यरत हैं। 4 उत्पाद प्रबंधक हैं।

इल्या:

यही है, ये वास्तव में, 4 टीमें हैं जिनके पास कुछ मीट्रिक हैं, वे तेजी से पता लगा सकते हैं, और इसी तरह। और बुनियादी ढांचा टीमें जो उन्हें नियंत्रित करती हैं ताकि वे कुछ भी ठीक न करें।

Anya:

इंफ्रास्ट्रक्चर टीमों का क्या मतलब है?

इल्या:

मुझे यह योजना पसंद है: आपको त्वरित प्रयोग करने की आवश्यकता है। यह एक पूरी तरह से अलग प्रकार की टीम है, डेवलपर्स खेल के नियमों को स्वीकार करते हैं कि “हम इसे अभी नहीं कर रहे हैं, ठीक है, डिजाइन पैटर्न, डेटाबेस और ओआरएम के साथ। हम एक ठूंठ बना रहे हैं, उन्होंने सामने फेंक दिया है, जितनी जल्दी हो सके, और इतने पर लुढ़का। "

इस मामले में, यह समस्या उत्पन्न होती है कि बहुत सारी टीमें बहुत सारे कचरा कोड बनाने लगती हैं, इसकी गुणवत्ता गिरती है, इसलिए उन्हें बुनियादी ढांचे की टीमों द्वारा मजबूत किया जाता है जो कोड समीक्षा करते हैं, कोड की गुणवत्ता का बीमा करते हैं, और इसी तरह। उत्पाद मेट्रिक्स और त्वरित प्रयोगों, बुनियादी ढांचे की टीमों - कोड गुणवत्ता, जटिल और लंबे घटकों, इंजन, रिफैक्टिंग आदि पर केंद्रित हैं।

Anya:

हाँ, सामान्य शब्दों में। हमेशा किसी तरह की नींव होनी चाहिए जो आपको त्वरित प्रयोग करने की अनुमति देती है।

माइकल:

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

इल्या:

लेकिन क्या आपके पास किसी प्रकार की विषमता है, कुछ टीमों को त्वरित प्रयोगों पर ध्यान केंद्रित किया जाता है, अन्य कोड जांच और रीफैक्टरिंग पर हैं: बिलिंग, उदाहरण के लिए, एक शाश्वत दर्दनाक विषय है जिसे लंबे समय से देखा और परिलक्षित किया जाता है?

माइकल:

एक इंफ्रास्ट्रक्चर टीम है जो विकास टीम में नहीं है, यह कोड के गहरे, "अंतरंग भागों" से संबंधित है।

Anya:

हमारे पास भी एक है!

इल्या:

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

माइकल:

हमारे पास एक दिलचस्प बात है। हम मूल रूप से एक दूरस्थ टीम थे और जितना संभव हो सके वृद्धि प्राप्त करने की कोशिश की। जब हम 20 से अधिक लोग हो गए, तो हम पहले मास्को कार्यालय में एकत्रित हुए। फिर हमें सैन फ्रांसिस्को में एक कार्यालय मिला, हमने एटलसियन के एक स्थानीय शांत दोस्त को नियुक्त किया, जिसने बड़ी कहानियों का निर्माण किया। उसने स्थानीय लोगों को भी रखना शुरू कर दिया। और हमें एक समस्या थी कि मार्केटिंग उत्पाद टीम से अलग होने लगी।

अब हम नई टीमों का निर्माण शुरू कर रहे हैं। हमने सैन फ्रांसिस्को के कार्यालय में डेवलपर्स को भेजना शुरू कर दिया। वे अपने ज्ञान और कौशल के साथ विपणक की मदद करते हैं।

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

रोमा:

दिलचस्प से, मैं तीन बातें कह सकता हूं। सबसे पहले, हमारी प्रवृत्ति "कम, लेकिन बेहतर है।" आईटी में 600 में से 100 लोग थे। अब 50 से कम लोग हैं, लेकिन वे बेहतर और अधिक कर रहे हैं। तीन मजबूत डेवलपर्स, एक उत्पाद के बिना भी, एक उत्पाद के साथ 10 से अधिक बुरे काम करेंगे। कर्मियों के एक फोर्ज के रूप में, हमारे पास किरोव शाखा है।

दूसरी प्रवृत्ति और वास्तविकता यह है कि हमारे पास बहुत सारे ऑफ़लाइन हैं। व्यापार न केवल बिक्री, बल्कि पूरे देश में विशाल खुदरा, फ्रेंचाइजी, विशाल गोदाम, हजारों कारें हैं जो तीन दिनों में पूरे देश में घूमती हैं। इस सब के लिए, हम CRM, वे सभी बाइंडिंग करते हैं जिनकी लोगों को आवश्यकता होती है। यह अक्सर ऑनलाइन पृष्ठभूमि वाले लोगों द्वारा उपेक्षित होता है, लेकिन यह महत्वपूर्ण है, और यह एक शानदार कहानी है।

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

हमने धीरे-धीरे ए / बी परीक्षण के रूप में स्विच किया। हमारे पास OKR व्यापार प्रणाली है, हम दो साल से इसका उपयोग कर रहे हैं, यह व्यवसाय के साथ सिंक्रनाइज़ करने में बहुत मदद करता है। पहले घर से एक दिन होता था, कोई भी। फिर दो दिन घर से थे, फिर तीन। यह तिमाही घर से पूरे सप्ताह में दर्ज की गई थी। जबकि सब कुछ शांत काम कर रहा है, लोग खुश हैं, परिणाम हैं। मेरा मानना ​​है कि यह भविष्य है - क्यों एक भरा हुआ कार्यालय में बैठो, किराया का भुगतान करें।

केवल एक प्लग है - ये प्रक्रियाएं हैं। मुख्य समस्या दूरस्थ कर्मचारियों के खिलाफ भेदभाव थी। “हम क्यों घर से बाहर बैठे कुछ दोस्त को जोड़ने जा रहे हैं। उसे वहीं बैठने दो। ” लेकिन जब सब समझते हैं कि कल और मैं घर से बैठेंगे, तो हर कोई हर किसी को जोड़ता है। मैं रिमोट से भी काम करता हूं।

यह कैसे सुनिश्चित करें कि सभी दूरदराज के कर्मचारी जितना संभव हो उतना शामिल हों?

रोमा:

सब कुछ अभ्यास से तय होता है। यदि आप किसी कर्मचारी को लिखते हैं, लेकिन वह ऑनलाइन नहीं है, यदि स्लैक के पास "दोपहर के भोजन के लिए" स्थिति नहीं है, तो अगले सप्ताह वह कार्यालय में बैठता है। एक व्यक्ति को जिम्मेदार होना चाहिए, यदि वह दूर से काम करता है, तो उसे लगातार उपलब्ध होना चाहिए।
SkyEng इस क्षेत्र में उनके अभ्यास के बारे में बहुत सारी बातें करते हैं। प्रमुख प्रदाताओं में से एक का कहना है कि आप खड़े होने के दौरान काम कर सकते हैं, और एक स्टैंड के रूप में इस्त्री बोर्ड का उपयोग कर सकते हैं। मैंने एक आरामदायक कुर्सी खरीदी, मैं रसोई की मेज पर बैठा हूं, स्काइप पर बात कर रहा हूं, सब कुछ ठीक है।

इल्या:

कार्यालय वहाँ होना चाहिए ताकि आप एक साथ मिल सकें और विचारों पर चर्चा कर सकें। लेकिन दूर की बात की शांत बात यह है कि लोग बैठे हैं और अपनी बात कर रहे हैं, कोई भी उन्हें एक बार फिर विचलित नहीं करता है। बैठकों की संख्या कम होने पर ठंडा करें। सबसे महत्वपूर्ण बात, मेरी राय में, और हम एक टीम के रूप में ऑनबोर्डिंग क्या सिखाते हैं:

1. कार्य कैसे किया जाता है यह एक शाश्वत समस्या है। हम स्थिति-समस्या-समाधान ढांचे का उपयोग करते हैं (मिंटो पिरामिड बुक के पहले 2 अध्याय देखें) और परिणाम से कार्य सेट करें, अर्थात, क्या करना है और परिणाम क्या होना चाहिए के सवाल का जवाब देना।
2. खानों की संस्कृति: पहले, टीम के सदस्य पाठ लिखते हैं, फिर कॉल करते हैं और ब्लॉकर्स और प्रश्नों पर संक्षेप में चर्चा करते हैं या गहरी क्रियाओं की योजना बनाते हैं।
3. मध्यवर्ती सहित परिणाम की डिलीवरी की संस्कृति।
   
   सामान्य तौर पर, वितरित टीम वयस्कों के बारे में होती है जो अपने समय का प्रबंधन करना जानते हैं और उन्हें प्रभावी ढंग से करने में मदद करते हैं।

क्या उत्पाद और परियोजना एक व्यक्ति है?

Anya:

उत्पाद को यह तय करना होगा कि उन्हें एक परियोजना की आवश्यकता है या नहीं। अगर आपको चीजों को आगे बढ़ाने की जरूरत है, तो कौन परवाह करता है?

माइकल:

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

Anya:

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

माइकल:

परिणाम सुनिश्चित करने के लिए उत्पाद को जिम्मेदार होना चाहिए। लेकिन यह कैसे किया जाता है यह महत्वपूर्ण नहीं है। यदि टीम के भीतर क्षमता है - यह अच्छा है। यदि नहीं, तो इसे फिर से भरने की आवश्यकता है।

माइकल:

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

इल्या:

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

प्रोजेक्ट मैनेजर एक "कवर वर्ड" है जिसमें आप कुछ भी भर सकते हैं। सामान्य तौर पर, यदि कोई कर्मचारी चाहता है, तो मैं उसे महारानी विक्टोरिया का पद दे सकता हूं। कौन परवाह करता है कि इसे क्या कहा जाता है? किसी को "स्क्रम-मास्टर" शब्द पसंद है, किसी को "प्रक्रिया सुविधाकर्ता" अधिक पसंद है।

माइकल:

चंचल कोच ...

इल्या:

मैं उन्हें दूर से प्यार करता हूं ... मैं उन्हें बहुत प्यार करता हूं, लेकिन दूर से।

रोमन:

कई लोग हमारे पाठ्यक्रमों में आते हैं जो एक परियोजना की भूमिका में काम करते हैं। वे इस विचार के साथ आते हैं कि वे जानते हैं कि अन्य लोगों की तुलना में क्या करना है, वे नए कौशल सीखना चाहते हैं, उदाहरण के लिए, उपयोगकर्ताओं के साथ संवाद करने के तरीके और इतने पर।

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

उत्पाद टीम में कैसे विकसित किया जाए?

रोमा:

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

पंप कैसे करें? उत्पाद पेशा बहुत विविध और बहुमुखी है। लेकिन काम के विभिन्न स्थानों में विभिन्न कौशल और क्षमताओं की आवश्यकता होती है, उन्हें अलग-अलग पक्षों से पंप किया जाना चाहिए। बी 2 बी और बी 2 सी उत्पाद हैं, और ये पूरी तरह से अलग कहानियां हैं। क्या लोग बड़े पैमाने पर उत्पादों के बारे में बात कर रहे हैं, बी 2 बी में यह 80% बेकार हो जाएगा। आपको सब कुछ अध्ययन करने और चुनने की आवश्यकता है जहां आप खुदाई में रुचि रखते हैं।

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

नेटवर्किंग का विस्तार करने की आवश्यकता है। , — , . : - , . , . , , — .

, . , , , , , , , -, . . , , , .

:

. , , . — . , , .

, , ( , ), , , -. , . , , . , , . : ( ), , , , , . - , - . , . , — , . — 90% .

— . , , . MVP, . «» ? custdev, . , , . — . , .

— 10 . , 30% . , . , , , . , , , . , .

, , 2 CEO, , , . , 0 1, , . .

, $15 000. - , 20-30 , , 50-60. « ». , 0 1 — . . , , .

:

, - -. Google: « 20% , ». , . « » , , .

, . , , , , — , «», . , , .

, , . , , . , : , . , . . , , — 10 , . , , . , . , , (: ). , , . , , — - , . , , « ». , , .

, . , OKRs. , , . , , , , . , - , .

:

— , , . , . -, - , . - , -… . . , . , , , . , . , . . . , . , — . -, . , , , .

:

, , . , - , . , .

. . , . , ( ).

:

: . — -. , . - , . - . , . , -, , . . -, , : « … … ». , . .

बेशक, जब आपको एक व्यावहारिक कार्य का सामना करना पड़ता है, तो आप सही सम्मेलन और सही पुस्तक का चयन करेंगे। यह बेहतर है जब विकास की आवश्यकता किसी विशिष्ट कार्य से आती है।

और निष्कर्ष में

हमने विशेषज्ञों से उपयोगी लिंक साझा करने और उन्हें एक स्थान पर रखने के लिए कहा। हमारे बॉट से फेसबुक या टेलीग्राम चैनल में सभी जानकारी प्राप्त की जा सकती है ।