डेवलपर्स बनाम व्यवसाय

मेरा नाम दिमित्री वोल्कोव है। एक उत्पाद प्रबंधक के रूप में अपने काम के दौरान, मैंने जीत और असफलताओं के बारे में बहुत सारी कहानियाँ जमा की हैं कि विकास और व्यवसाय के बीच संचार का सही तरीके से निर्माण कैसे किया जाए और क्या कभी नहीं किया जाना चाहिए। आज मैं ऐसी दो कहानियां बताऊंगा।

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


संपादक का ध्यान दें: यह पाठ 28 फरवरी, 2019 को पिमनाया रैली में दिमित्री वोलकोव की एक रिपोर्ट का परिणाम है। कुछ मुद्दों पर संपादकीय राय लेखक की राय से मेल नहीं खा सकती है।

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

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

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

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

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

हालाँकि, समस्या की खोज काफी जल्दी हो गई थी। पूरी बात व्यवसाय की अत्यंत सरल, आसान और निर्धारित स्थिति में थी: "मैंने कहा - यह आवश्यक है, इसलिए इसे करें।" और इस परियोजना में आंतरिक संघर्ष का कारण बना कि हम किस तरह की सुविधा प्रदान करते हैं।

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

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

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

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

संचार और संबंधों के बारे में

एक और मामला जो मैं बात करना चाहता हूं, वह भी संचार और संबंधों के बारे में है, लेकिन उच्च संबंधों के बारे में, प्यार के बारे में भी अधिक संभावना है।

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

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

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

इससे सभी चल रही प्रक्रियाओं में प्रतिभागियों को शामिल करना संभव हो गया, और सभी टीमों ने जो देखा और हमारी आवश्यकताओं के प्रति अधिक चौकस होना शुरू किया।

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

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

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

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

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

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

यह निश्चित रूप से उसे समस्या को अधिक व्यापक रूप से देखने में मदद करेगा, क्योंकि आपके सहकर्मी शायद उसके साथ अपनी राय साझा करने के लिए तैयार हैं, लेकिन अब वे उस पर भरोसा नहीं करते हैं।

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

Yandex.Money में टीमें भी इसी तरह काम करती हैं। परियोजना और उत्पाद का घनिष्ठ संबंध हमें पहले की तुलना में बहुत तेजी से विकसित करने की अनुमति देता है - हम नियमित रूप से बैकलॉग को साफ करते हैं, अप्रचलित कार्यों को हटाते हैं, जो असभ्य होते हैं, समय पर टी-शर्ट और कहानी बिंदुओं में हमारे कार्यों का मूल्यांकन करने के लिए ताकि समय की सुविधा और प्रक्रियाओं को गति प्रदान कर सकें। की योजना बना। हम अपनी टीम के साथ संवाद करते हैं और इस बारे में बात करते हैं कि उपयोगकर्ता सीजेएम के प्रत्येक चरण में कैसे व्यवहार करता है, संख्याओं और मैट्रिक्स के साथ रिपोर्ट में क्या होता है।

अंत में, मैं कह सकता हूं कि यदि आपका उत्पाद बाजार में या आपके उत्पाद में जो कुछ भी हो रहा है उसे साझा नहीं करता है, तो यह उसे करने के लिए कहने का समय है। जैसे ही आप टीम को बताते हैं कि आप वास्तव में क्या कर रहे हैं और क्यों कर रहे हैं, सभी प्रतिभागियों की भागीदारी बहुत बढ़ जाती है। व्यवहार में सिद्ध।

---

इसे पढ़ने वालों के लिए आश्चर्य - इस पोस्ट में Yandex.Money से एक अच्छा बोनस के लिए एक प्रचारक कोड है। वह वही प्राप्त करेगा जो पहले पाता है और सक्रिय करता है ।

UPD 10:20 काटा के पहले लाइनों के बीच पहला प्रचार कोड था। यह 17 मिनट में सक्रिय हो गया था।

और अगर आपके पास समय नहीं है, तो निराश न हों - अगले पदों में भी प्रचारक कोड होंगे। अगली बार सभी से आगे आने के लिए हमारे ब्लॉग को सब्सक्राइब करें।

द्वारा तैयार पाठ:
लेखक दिमित्री वोल्कोव हैं।
संपादक - यूजीन शकीलार, डेनिस वोनसरोवस्की।