जब लेख और रिपोर्ट में वे टीम प्रबंधन में मामलों के बारे में बात करते हैं, तो वे अक्सर खुद को यह बताने के लिए सीमित करते हैं कि क्या गलत था और कैसे उन्होंने स्थिति को बदल दिया। लेकिन इस बार हमारे पास यह जानने का एक अनूठा अवसर है कि टीम आगे कैसे रही और यह सब कैसे समाप्त हुआ - वास्तव में, यह समाप्त नहीं हुआ, बल्कि जारी रहा।
इविवि में फुर्तीली परिवर्तन के बारे में "
एक स्केलेबल स्किम कैसे बचे और कोड गुणवत्ता नियंत्रण बनाए रखें " शीर्षक वाली कहानी का सिलसिला
यहां जारी है।
TeamLead Conf में, कंपनी के तकनीकी निदेशक, एवगेनी रॉसिन्स्की (
इरोस ) ने बताया कि क्यों टीम के संपूर्ण पुनर्गठन को रोल करने के लिए आवश्यक हो सकता है, कैसे डेवलपर्स को झगड़ा करने और मदद करने के लिए नहीं, बल्कि व्यावसायिक दक्षता को बनाए रखने और बढ़ाने के लिए।
कंपनी का संदर्भ
ivi - 48 मिलियन उपयोगकर्ताओं के दर्शकों के साथ सबसे बड़ा कानूनी इंटरनेट सिनेमा, जो सामूहिक रूप से मासिक आधार पर 70 मिलियन घंटे खर्च करते हैं। Ivi में 62 हजार यूनिट सामग्री है, जो विभिन्न उपकरणों और हमेशा उत्कृष्ट गुणवत्ता में उपलब्ध है।
ऐसा हुआ कि उसी दिन जब यूजीन ने इस रिपोर्ट के साथ टीमलीड कॉन्फ में बात की, यह कंपनी का जन्मदिन था। 9 साल पहले, परियोजना के वेब संस्करण की पहली रिलीज हुई थी, और 2 दिनों के बाद, चैनल वन की ताकत ने बड़ी संख्या में उपयोगकर्ताओं को आईवीआई में लाया। कंपनी ने यह भी सोचा कि यह DDoS था, लेकिन गरिमा के साथ सामना करने में सक्षम थे।
यह लेख एक नए उत्पाद को लॉन्च करने के बारे में है - सभी अनुप्रयोगों का एक पूरा पुनरारंभ।
बिना सेंसर किए हुए संस्करण को सुनने के लिए वीडियो देखें या पहले व्यक्ति में रिपोर्ट की प्रतिलेख पढ़ें।सबसे पहले, चलो उन तकनीकों और दक्षताओं के बारे में बात करते हैं जो क्षति की सीमा को समझने के लिए उपयोग की जाती हैं।
दक्षताओं:- बैकएंड (पायथन, गोलंग, जावा);
- वेब (जावास्क्रिप्ट, Node.js);
- Android (जावा)
- iOS (ऑब्जेक्टिव-सी, स्विफ्ट);
- स्मार्टटीवी (जावास्क्रिप्ट);
- विंडोज / एक्सबॉक्स (सी #);
- सोनी पीएस (जावास्क्रिप्ट)।
2016 में इनमें से प्रत्येक दक्षताओं के लिए, हमारी अपनी टीम थी, अर्थात iOS टीम, Android टीम, आदि। एक बैकएंड टीम भी थी और अलग से, उत्पाद प्रबंधकों की एक टीम थी जो नई सुविधाओं के साथ आई थी।
मुख्य समस्या, जिसके कारण इसे बदलना आवश्यक था, यह था कि सभी प्लेटफ़ॉर्म अलग-अलग हैं, जिसमें यह भी शामिल है कि उनके पास अलग-अलग बैकलॉग और प्राथमिकताएँ थीं। और हम वास्तव में अपने अनुप्रयोगों के भीतर एक
ही सूचना स्थान बनाना चाहते थे।
ऐसा अक्सर होता है कि कल्पना करने के 4 महीने बाद सभी प्लेटफार्मों पर एक जटिल विशेषता दिखाई देती है। उसी समय, यह 3 दिनों के बाद एक मंच पर दिखाई दिया, और फिर, बैकलॉग की प्राथमिकता के आधार पर, यह अलग-अलग प्लेटफार्मों पर अलग-अलग गति से लुढ़का। यह निम्नलिखित कारणों से राक्षसी निकला:
- 4 महीने के लिए, सुविधा पहले से ही पूरी तरह से अलग अर्थ प्राप्त कर सकती है और इसके लिए आवश्यकता गायब हो सकती है।
- संचार समस्याओं के कारण, जो इस मामले में स्पष्ट हैं, लोगों ने विभिन्न तरीकों से सुविधाओं को लागू किया।
चूंकि उत्पाद में तीन मुद्रीकरण मॉडल हैं जो विभिन्न प्लेटफार्मों पर अलग-अलग दक्षता के साथ काम करते हैं, इसलिए प्रत्येक प्लेटफ़ॉर्म पर बैकलॉग प्राथमिकता अलग थी।
कुछ विशेषताएं, सिद्धांत रूप में, कभी भी अलग-अलग प्लेटफार्मों पर लागू नहीं की जा सकती हैं।परिवर्तन की एक संक्षिप्त वापसी
2017 में, हमने
वैल्यू स्ट्रीम की अवधारणा पेश की - ये क्रॉस-फंक्शनल टीमें हैं जो विशिष्ट व्यावसायिक कार्यों के लिए जिम्मेदार हैं। यह समझने के लिए कि हमारा व्यवसाय क्या विशिष्ट व्यवसाय है, हम पूरी कंपनी के 25-30 लोगों को एक साथ लाए, कोचों को आमंत्रित किया, जो लचीली कार्यप्रणाली में लगे हुए हैं, और 2 दिनों में हमने तैयार किया कि हमारा मूल्य क्या होना चाहिए - विकास निर्देश।
5-6 मूल्य की धाराएँ मिलीं। उन्होंने इन लोगों को एक साथ लगाया, प्रत्येक को एक उत्पाद मालिक दिया, जो इस विशेष दिशा के लिए डूब जाएगा (
यहां अधिक विवरण)।
हम दर्द, खून, आँसू और खुशी जानते थे और बहुत अच्छे संकेतक तक पहुँच गए थे:
- विभिन्न प्लेटफार्मों पर समान सुविधाओं के तुल्यकालिक उतराई ।
- समय-समय पर बाजार में कई कमी । कई सुविधाओं की रिलीज़ केवल प्रत्येक प्लेटफ़ॉर्म पर रिलीज़ प्रबंधन चक्र में आराम करती है, उदाहरण के लिए, Apple प्रत्येक सुविधा को अलग से लोड करने की अनुमति नहीं देता है। इसलिए, सुविधाओं को समूहीकृत किया जाता है और औसतन हमें हर दो सप्ताह में एक बार जारी किया जाएगा।
- "अड़चनों" का उन्मूलन , जो उत्पाद स्वामी और तकनीकी प्रबंधक और टीम के नेता दोनों थे।
- डेवलपर्स यह समझने लगे कि वे नई कार्यक्षमता को "देखना" क्यों कर रहे हैं।
हम वर्ष बहुत अच्छी तरह से बच गए -
2017 में, राजस्व लगभग दोगुना हो गया ।
लेकिन यह पर्याप्त नहीं था, और 2017 के उत्तरार्ध में जीवन - 2018 की शुरुआत में हमें आश्चर्य हुआ।
आपको एक नए उत्पाद की आवश्यकता क्यों थी
व्यवसाय ने नए लक्ष्य निर्धारित किए हैं। आश्चर्य यह था कि किसी भी चीज़ के लिए किसी भी सॉफ़्टवेयर का विकास मौजूद है। कुछ परोपकारी कारणों के लिए कोड लिखें। कंपनी के अस्तित्व को सही ठहराने के लिए, उसके मालिकों और शेयरधारकों ने कुछ लक्ष्य निर्धारित किए हैं जिन्हें टीम को पूरा करना चाहिए।
हमारे शेयरधारक यह नहीं कहते कि यह कैसे करना है, वे कहते हैं कि वे क्या हासिल करना चाहते हैं। कैसे - टीम को तय करना होगा।
टीम को
अधिक कमाई करने के तरीके के साथ आने के कार्य का सामना करना पड़ा। हमने एक मंथन किया, और किराना विभाग, तकनीकी एक के साथ, इस निष्कर्ष पर पहुंचे कि महत्वाकांक्षी लक्ष्यों (सशर्त रूप से, भुगतान करने वाले दर्शकों के आकार को दोगुना करने) का एहसास करने के लिए, सिद्धांत रूप में, हमें फिल्म को मुफ्त में भुगतान करने के लिए मुफ्त देखने से
जोर देना चाहिए।
लगभग सभी परिकल्पनाओं ने पुराने उत्पाद की अवधारणा में बहुत खराब रूप से फिट होने के लिए आगे रखा। अधिक सटीक रूप से, यह बिल्कुल भी फिट नहीं था - उपयोगकर्ता संक्रमण पर कोई प्रेरक प्रवाह इस तथ्य पर आराम करता है कि कुछ प्लेटफार्मों पर इसे लागू किया जाता है, कुछ पर, कुछ सीमाएं हैं, अन्य वहां। हमारी टीम 9 साल पुरानी है, और हमने बहुत सी चीजें जमा की हैं जो हमें नीचे तक ले गईं। अच्छे तरीके से, सब कुछ फिर से लिखना आवश्यक था।
कई गुणात्मक और मात्रात्मक अध्ययनों ने
पुराने उत्पाद की
समस्याओं को दिखाया है। यह पता चला कि मानव जाति ने जो सोचा है, उससे हम 2-3 साल पीछे हैं। उदाहरण के लिए, अगर मोबाइल उपकरणों पर लगभग 5 साल पहले ऊपरी बाएँ कोने में बर्गर मेनू लगाने के लिए फैशनेबल और आधुनिक था, तो बड़ी स्क्रीन के आगमन के साथ लोगों ने वहां पहुंचना बंद कर दिया। 2018 तक, हमारे पास वास्तव में बर्गर मेनू था, और लोगों ने किसी तरह इसका सामना किया।
गरीब उपयोगकर्ता को सब कुछ करने की आदत हो जाती है, लेकिन इसका मतलब यह नहीं है कि आपको सब कुछ छोड़ने की आवश्यकता है जैसा कि यह है।
कई ढांचों को फिर से तैयार करने की जरूरत थी। हमें तार्किक खामियां मिलीं और किसी भी लंबे समय तक रहने वाले कोड के रूप में, हमारे पास बहुत सारे पुराने बहुत अच्छे कोड नहीं थे। डेवलपर्स वास्तव में इसे पसंद नहीं कर रहे थे।
उदाहरण के लिए, उन डेवलपर्स को किराए पर लेना बहुत मुश्किल है जो ऑब्जेक्टिव-सी में लिखना चाहते हैं। हम सभी फैशन से प्रभावित हैं, और यहां तक कि आलसी - अगर कोई उपकरण है जो आपको एक ही चीज़ के बारे में करने की अनुमति देता है, लेकिन तेजी से और अधिक कुशलता से, हम इसका उपयोग करना चाहते हैं। और श्रम बाजार की स्थिति ऐसी है कि आप एक सारांश में लिख सकते हैं: "मैं स्विफ्ट में लिखना चाहता हूं," और यहां तक कि अगर आप नहीं जानते कि स्विफ्ट में कैसे लिखना है, तो आप निश्चित रूप से कहीं मिलेंगे।
इसके साथ कुछ किया जाना था, और यह विकास में बाधा डालने वाली समस्याओं में से एक है। इसलिए, हमें अप्रचलित घटकों को फिर से लिखना और आधुनिक रूपरेखाओं को लागू करना था।
लक्ष्यों
हम चाहते थे:
- एक एकल डिजाइन के साथ एक नया उत्पाद बनाएं।
- हमारे उत्पाद के भीतर सभी ब्लॉकों को जारी करने के लिए हमारी अच्छी सिफारिश प्रणाली जिम्मेदार बनें।
- तार्किक इंटरफ़ेस त्रुटियों को ठीक करें।
- कोड साफ करें।
- एक नई सांख्यिकी प्रणाली में माइग्रेट करें।
- एक डिजाइन प्रणाली लागू करें।
सभी चुनौतियां काफी महत्वाकांक्षी हैं, विशेष रूप से डिजाइन प्रणाली, क्योंकि बहुत कम डिजाइन प्रणालियां हैं जो क्रॉस-प्लेटफॉर्म पर काम करती हैं और प्रोग्राम कोड से तलाकशुदा हैं। वे मुख्य रूप से जेएस इंजन का उत्पादन करते हैं, जिसका उपयोग विभिन्न प्लेटफार्मों पर किया जाता है। वास्तव में, कोड के अंदर उत्पाद कैसा दिखना चाहिए, इसके बारे में जानकारी प्रसारित करने का तंत्र।
हम यह बहुत अच्छी तरह से नहीं कर सकते हैं, क्योंकि हम वीडियो के साथ काम करते हैं, और वीडियो के साथ काम करने के लिए अधिक या कम देशी टूल का उपयोग करना पड़ता है। साथ ही, यदि आप मूल उपकरण का उपयोग नहीं करते हैं, तो हमेशा ऑपरेटिंग सिस्टम रिलीज़ से 1-2 कदम का बैकलॉग होगा। Xamarin जैसी सभी सार्वभौमिक रूपरेखाओं को अभी भी रिलीज़ होने के बाद पकड़ा जाना है। और हम चित्रित किए जाने से पहले बहुत लालची हैं - Google और Apple दोनों ही हमें सलाह देते हैं कि हम देशी उपकरणों का उपयोग करें।
देशी उपकरण गुणवत्ता, अच्छा, तेज अनुप्रयोग बनाने में मदद करते हैं। वीडियो के मामले में, यह बस आवश्यक है।
प्रबंधन समाधान के लिए खोजें
लक्ष्य निर्धारित करने के बाद, हम उनकी त्वरित उपलब्धि के लिए तैयार हुए। मुझे याद दिलाएं कि हम वैल्यू स्ट्रीम में विभाजित थे, विभिन्न डेवलपर्स अलग-अलग टीमों में बैठे थे, और हमें कठोर वास्तविकता का सामना करना पड़ा - क्या करना है?
ऐसा लगता है कि हमारे पास एक प्रणाली थी जिसके लिए हम लोगों को काफी समय के लिए आदी कर दिया था, और अब खेल के नियम बदल गए हैं।
बेशक, सबसे पहले हमने पहले की तरह काम करने की कोशिश की, वैल्यू स्ट्रीम का उपयोग करते हुए, निम्नलिखित तार्किक गणनाओं को स्वीकार करते हुए: "लेट वैल्यू स्ट्रीम, जो व्यापार की ऐसी दिशा में लगी हुई है, इन क्षेत्रों से जुड़े सभी घटकों को रिफलेक्टर करेगा।"
ओह हम कितने गलत थे! लगभग एक महीने बाद यह पता चला कि प्रत्येक एप्लिकेशन के मूल को फिर से लिखने के लिए, वास्तव में, आपको व्यावसायिक नियमों के सभी क्षेत्रों में जाने की आवश्यकता है।
वैल्यू स्ट्रीम की जिम्मेदारी के क्षेत्र में अंतर करना बहुत मुश्किल था, जो अलग-अलग कमरों में, अलग-अलग मंजिलों पर बैठे लोगों को किस हिस्से में ले जाता है।
विकास प्लेटफार्मों के विभिन्न भाषाओं और विशेषताओं के कारण, सबसे अधिक दुख की बात है, सहयोग का प्रभाव पूरी तरह से गायब हो गया है।
वैल्यू स्ट्रीम के ढांचे के भीतर, आईओएस और एंड्रॉइड डेवलपर्स एक ही विशेषता को देख रहे हैं, और उनके पास कुछ बात करने के लिए है, वे व्यापार तर्क पर चर्चा कर रहे हैं। और जब उनमें से प्रत्येक ने एक निम्न-स्तरीय रूपरेखा देखी, जो कमजोर रूप से सहसंबद्ध है जो बाद में अंतिम उत्पाद में होगी, तो
सिंक्रनाइज़ेशन पूरी तरह से
गायब हो जाता है।
ऐसे लोग थे, जो सैद्धांतिक रूप से, जो हो रहा था, उसके अर्थ से अलग हो गए। द टाइमलीड्स सबसे पहले हतोत्साहित होने वाले थे, क्योंकि वे, जिम्मेदार लोगों के रूप में, मानवता के कर्मचारियों में ठोकर खाने और विश्वास करने की ज़रूरत थी, ताकि वे सच्चे चर्च में वापसी के लिए सही दिशा में पर्याप्त कोड लिखें। यह बहुत बुरी तरह से निकला।
डेढ़ महीने के बाद, यह एहसास हुआ कि वैल्यू स्ट्रीम तैयार उत्पादों के लिए बहुत अच्छा है, लेकिन आम तौर पर अप्रभावी होते हैं जब किसी उत्पाद को खरोंच से लिखना पड़ता है।
सभी सरल सत्य की तरह, आप उन्हें केवल रेक नंगे पांव चलने के बाद ही समझते हैं, और यहां तक कि रेक के माध्यम से चालू करते हैं।
सब कुछ नया पुराना भूल गया है।
जैसा था वैसा ही हम सब कुछ लौटा देंगे
विजयी युगांतरकारी परिवर्तन के बाद, हमने 2016 में जैसा था वैसा ही सब कुछ करने का फैसला किया, क्योंकि लोकतंत्र का अधिकार अर्जित किया जाना चाहिए।
ताकि सभी को वोट देने का अधिकार हो, और इस अधिकार का दावा किया जाता है और इसका इस्तेमाल किया जाता है, इसके लिए नियम और पारिस्थितिकी तंत्र तैयार करना आवश्यक है जिसमें यह काम करेगा।
जब कोई पारिस्थितिक तंत्र नहीं होता है, तो कुछ चीजों को आधिकारिक रूप से किया जाना चाहिए ताकि नियम किसी तरह बन जाएं।
निम्नलिखित कार्य किया:
- वे लोगों को टाइमलीड्स के विंग के तहत वापस ले आए, उन्हें फीचर-ओरिएंटेड प्रोग्रामिंग से सिर्फ सामान्य प्रोग्रामिंग में वापस कर दिया।
- उत्पाद प्रबंधकों को उपयोगकर्ताओं को प्रवाहित करने के लिए सौंपा गया था। हमारे मामले में, यह डाउनलोडिंग, प्राधिकरण, आदि है।
- हमने एक नए उत्पाद के लिए सभी आवश्यकताओं को औपचारिक रूप देने की कोशिश की, जिसे हमने विकास की शुरुआत में सहमति दी थी।
सब कुछ तर्कसंगत प्रतीत होता है, लेकिन दो साल पहले हम उसी समस्याओं में भागे थे।
इसने काम नहीं किया, फिर से संगठन में समस्याएं
दो साल पहले मुख्य समस्याएं थीं: केंद्रीकरण और निर्णय लेना।
अधिनायकवाद "बाधाओं" के उद्भव की ओर जाता है - टीम के नेता, तकनीकी प्रबंधक और उत्पाद प्रबंधक जिनके पास विकास के लिए सुविधाओं को व्यक्त करने का समय नहीं है। एक उत्पाद जिसे 8 साल पहले देखा गया है, कुछ महीनों में पुनर्विचार करना मुश्किल है। 80% अवधारणा तैयार होने पर यह शांत नहीं होता है, और 20% (बस जहां लुगदी है) अभी तक नहीं है। इससे टीम बहुत नाराज हुई और परेशान हुई।
जब डेवलपर्स औपचारिक रूप से टीम के नेताओं के प्रबंधन में लौट आए, तो उत्पाद प्रबंधकों के साथ लाइव संचार बहुत कम था, और टीके को औपचारिक रूप देने की आवश्यकता थी। मौखिक संचार द्वारा पूरी तरह से बदल दिया गया था, फिर से औपचारिकता में बदल गया - वह लौट आया, किसी ने उसे वापस नहीं किया। लेकिन इंजीनियरों को इस तरह से व्यवस्थित किया जाता है, उन्हें संस्थान में पढ़ाया जाता है: एक समस्या बयान है - इसे हल करने की आवश्यकता है, कोई समस्या बयान नहीं है - दुनिया दुर्घटनाग्रस्त हो रही है, एल्गोरिथ्म काम नहीं करेगा।
इस प्रक्रिया में, त्रुटियों और गलतफहमी की खोज की गई, दोनों तार्किक और वास्तुशिल्प। कई वर्षों के लिए कोड बनाने की कल्पना करें, और यह सब समय आप इसे फिर से भरना चाहते हैं, और जब अवसर पैदा होता है, तो यह पता चलता है कि सभी विचार और अवधारणाएं बहुत अच्छी नहीं हैं या बिल्कुल भी काम नहीं करती हैं। सपना झूठा निकला।
उसी समय, जैसा कि आमतौर पर होता है जब समय सीमा का मूल्यांकन किया जाता है, तो एक व्यवसाय एक बात सुनता है, विकास एक और सुनता है। इसके अलावा, व्यापार अभी भी दो में विभाजित है, और फिर यह समय सीमा पर दबाव डालना शुरू कर देता है और कल एक नया उत्पाद प्राप्त करना चाहता है। घंटे X पर, यह पता चला है कि विकास सोचता है कि अभी भी 3-4 महीने हैं, और व्यवसाय कल रिलीज होने का इंतजार कर रहा था। हर कोई परेशान है, टीम आंसू बहाना शुरू कर देती है।
तुमने क्या किया है
हमने कैसे रहते हैं, इस पर बड़े पैमाने पर पूर्वव्यापी कार्रवाई की, और खुलासा किया कि डेवलपर्स और टीम के नेताओं के बारे में सबसे अधिक चिंता क्या है।
कार्यक्षमता को फिर से करने की आवश्यकता है , और अक्सर 3 बार। सच कहूं, तो समस्या की आधी समस्या समस्या के बयान के पक्ष में थी, दूसरी छमाही कार्यान्वयन पक्ष पर थी। हालांकि, डेवलपर्स, निश्चित रूप से दृढ़ता से आश्वस्त थे कि पूरी समस्या समस्या के निर्माण में थी। टास्क में डायरेक्टर भी वही थे। कोई भी खुद को गलत या दोषी नहीं मानना चाहता है, हर कोई कहता है कि समस्या दूसरी तरफ है।
पुराने आवेदन के लिए समर्थन । मल्टीमिलियन-डॉलर दर्शकों के साथ एक सेवा को केवल त्याग नहीं किया जा सकता है। एक नया उत्पाद लिखने के साथ समानांतर में, कुछ पुराने के साथ किया जाना चाहिए। यह बहुत कष्टप्रद है!
एक डिजाइन प्रणाली का कार्यान्वयन। हमें इस दिशा पर बहुत गर्व है: यह वास्तव में आपको बहुत जटिल चीजें करने की अनुमति देता है, और उत्पाद एक समान दिखता है। लेकिन मुझे JSON क्या है इसके बारे में डिजाइनरों को प्रशिक्षित करना था, और डिजाइनरों को डेवलपर्स को यह बताना था कि उपस्थिति भी बहुत महत्वपूर्ण है। इस बारे में बहुत सारी प्रतियां तोड़ी गईं।
जानकारी का अभाव और प्रश्न का उत्तर "क्यों?"। वैल्यू स्ट्रीम के बिना, कुछ डेवलपर्स अब यह नहीं समझते हैं कि वे कुछ क्यों कर रहे हैं। सूचना के प्रसारण में विराम था, और कारण-प्रभाव संबंध आंशिक रूप से चला गया था। जिन लोगों को यह पूछने की ताकत मिली कि हम ऐसा क्यों कर रहे थे वे खुश थे। बहुत संचारी लोगों ने नहीं सोचा था कि बेवकूफ कहीं ऊपर बैठे थे जो उन चीजों का आविष्कार करते हैं जिन्हें डिज़ाइन नहीं किया जा सकता है।
नए व्यावसायिक नियमों पर प्रलेखन का अभाव। जानकारी की कमी के कारण, प्रलेखन की कमी थी, जिसमें यह बताया जाएगा कि आवेदन कैसे सही ढंग से काम करना चाहिए।
सभी ने एक वास्तुकार की भूमिका पर कोशिश की, और सभी को यह पसंद नहीं आया। मेरे लिए यह सबसे बड़ी खोज थी। पहली बार, टीम के नेताओं ने लगभग डेढ़ साल में प्रसंस्करण अनुप्रयोगों के लिए समय सीमा का अनुमान लगाया, जो बेकार है। ऐसा इसलिए हुआ क्योंकि प्रत्येक टीम लीडर सिस्टम के सभी टुकड़ों को खुद के माध्यम से जाने देना चाहता था, यानी वह वास्तव में आवेदन वास्तुकला को सौंपना और विघटित नहीं करना चाहता था, लेकिन सब कुछ अपने पास रखना चाहता था।
इस दृष्टिकोण के साथ, आपको वास्तुकला को फिर से तैयार करने के लिए वास्तव में डेढ़ साल की आवश्यकता है। लेकिन इस दुनिया में ऐसे शब्दों का कोई लेना-देना नहीं है। इसलिए, लंबी चर्चा के बाद, हम इस नतीजे पर पहुंचे कि टीम लीडर के वास्तुशिल्प कार्यों को विकास के अनुभवी सेनानियों को सौंपा जाना चाहिए, जो अन्य बातों के अलावा, कुछ प्रमुख क्षेत्रों में एक वास्तुकार की तरह भाग लेना और महसूस करना चाहते थे।
यह एक दिलचस्प तथ्य निकला - यह पता चला है कि जिम्मेदारी लेना अप्रिय है।
खुद को आर्किटेक्ट या टीम लीडर कहना और टीम लीडर होना दो बड़े अंतर हैं। हर कोई इस बात को स्वीकार करने के लिए तैयार नहीं हुआ कि अगर आप ध्यान रखते हैं और किसी रूपांतरण को अपनाते हैं, तो यह केवल आपकी जिम्मेदारी होगी।
मैं भोली थी और किसी कारण से सोचा था कि हमारी टीम में हर किसी में इतनी हिम्मत है। मैं यह भूल गया कि टिमलीड से पहले आपको परिपक्व होने और थोड़ा बड़ा होने की आवश्यकता है। साल भर में, हम में से कई इस दिशा से गुजरे थे, और कुछ ने महसूस किया कि वे बड़े नहीं होना चाहते थे, लेकिन चौड़ाई में, और टीम लीडर नहीं बनना चाहते थे।
स्थिति को कैसे ठीक किया जाए
विभिन्न आर्किटेक्चरल दिशाओं में डरपोक की भूमिकाओं के अपघटन और विभेदीकरण के अलावा, हमने तथाकथित फ्लाइंग प्रतिशोध इकाइयों (वीओसी) का गठन किया और उन्हें गुणवत्ता नियंत्रण विशेषज्ञों (क्यूए) को आकर्षित किया। सबसे पहले, वे सभी की तुलना में स्वतंत्र थे - अभी तक कोई नया उत्पाद नहीं है, और आप बाद के रजिस्टरों के लिए टेस्ट केस और टेस्ट सूट लिख सकते हैं।
फिर यह पता चला कि व्यावसायिक नियम अभी तक पूरी तरह से तैयार नहीं हुए हैं, और कंपनी के पास बहुत से लोग नहीं हैं जो जानते हैं कि नए आवेदन को कैसे काम करना चाहिए।
हमने QA के लिए निम्नलिखित कार्य निर्धारित किए हैं:
- हमें व्यावसायिक नियमों और एप्लिकेशन में काम करने वाले तर्क पर अप-टू-डेट प्रलेखन की आवश्यकता है।
- नए व्यापार तर्क के अनुयायियों की जरूरत है, और न केवल प्रबंधकों और तकनीकी प्रबंधकों।
चूंकि हमारे पास एक नया अनुप्रयोग है, और हमें इसे फिर से करने की आवश्यकता है, हमें ऐसे लोगों की आवश्यकता है जो इस तरह के प्रश्नों को उठा सकते हैं: इस तरह की त्रुटि को कैसे संभालना चाहिए, ऐसी स्थिति में आवेदन कैसे व्यवहार करना चाहिए। मैं दोहराता हूं, मुख्य मामलों का वर्णन किया गया था, लेकिन शैतान विवरण में है - उन्हीं 20% को बंद करने की आवश्यकता है।
हमने डायनेमिक माइक्रोकैंडम बनाना शुरू किया। इस तथ्य के बावजूद कि लोगों को कहीं भी प्रत्यारोपित नहीं किया गया था, लेकिन एक विशिष्ट दिशा के उत्पाद से जुड़ा हुआ था, क्यूए का एक व्यक्ति जो विधिपूर्वक परियोजना के काम में लगा हुआ था, अर्थात् इसके लिए जिम्मेदार था:
- डेवलपर्स से प्रश्न एकत्र करना, प्रश्नावली बनाना;
- संगठन और बैठकों की रिकॉर्डिंग;
- प्रलेखन की औपचारिकता;
- पहले से ही परीक्षण के मामले और परीक्षण सूट लिखना।
जब हम फिनिश लाइन पर पहुंच गए, तो इसने हमें रिलीज के लिए तैयारी की गति बढ़ाने के लिए परीक्षण के लिए आउटसोर्सर्स, आउटस्टाफर्स को जोड़ने की अनुमति दी। हमारे पास बहुत सारे प्लेटफ़ॉर्म हैं, जो मैंने सूचीबद्ध किए हैं वे केवल उपकरण हैं जिनके साथ हम काम करते हैं। उदाहरण के लिए, स्मार्टटीवी में 6-7 प्लेटफ़ॉर्म हैं, जिनमें से प्रत्येक के लिए आपको अलग से रिलीज़ करने, एक अलग रिग्रेशन का संचालन करने आदि की आवश्यकता होती है। यदि आपके पास पहले से पंजीकृत व्यावसायिक मामले हैं, तो आप आसानी से यहां आउटसोर्स और आउटस्टाफर्स को जोड़ सकते हैं।
VOCs की शुरूआत ने टिमलीड्स को काफी राहत दी। उन्हें प्रबंधकीय कार्यों से विचलित होने का अवसर नहीं मिला, बल्कि विकसित सामग्री के आधार पर कोड के विकास के संबंध में रणनीतिक निर्णय लेने का मौका मिला।
प्रोजेक्ट "द फ्लाइंग स्क्वाड्स ऑफ रिटेंशन" उम्मीदों पर खरा उतरा, और हम एक-दूसरे को मारे बिना रिलीज़ लाइन में प्रवेश कर गए।
आगे क्या है?
2018 , — , , . . , , . «, ,» — .
, , 2016 Value Stream. , . , , . .
, , .
, , . , , , 2018 4 . , , , .
.
.
— . , , , , , . -, , .
: , , , . . .
सेंट पीटर्सबर्ग टीमलेड कॉन्फिडेंस कार्यक्रम लगभग तैयार है। चलो कुछ रन करते हैं, सभी नियोजित विषयों को प्रकट करने के लिए परिष्करण स्पर्श जोड़ते हैं, और ब्लॉकों में रिपोर्ट के बारे में बात करना शुरू करते हैं। अभी के लिए, आप स्वतंत्र रूप से रिपोर्ट की सूची का मूल्यांकन कर सकते हैं और 23 और 24 सितंबर को टीम के साथियों के कौशल को आरक्षित कर सकते हैं ।