स्केलेबल स्कैम में टीम के साथी कैसे बचे और कोड गुणवत्ता नियंत्रण बनाए रखें

Ivi तकनीकी निदेशक, एवगेनी रॉसिन्स्की ( इरोस ), स्ट्रीमिंग के तकनीकी पक्ष पर रिपोर्टों पर हमारे सम्मेलनों में प्रतिभागियों से अच्छी तरह से परिचित हैं। लेकिन आज आपके पास टीमलीड पर यूजीन की रिपोर्ट का प्रतिलेख है कि टीम के नेताओं में फुर्तीला परिवर्तन कैसे दिखाई देता है।



Ivi में इतने समय पहले हम फुर्तीले बदलाव से नहीं गुजरे और इसके संदर्भ में इससे अच्छा लाभ मिला:

• व्यापार
  
• विकास की गति
  
• बाजार का समय;
  
• अन्य दिलचस्प मैट्रिक्स।
  

लेकिन इस रचनात्मक निर्णय के परिणामों ने टीम के नेताओं को बहुत गंभीरता से मारा। रिपोर्ट सिर्फ इस बारे में है कि इससे कैसे निपटा जाए, और किस उपकरण का उपयोग किया जाए।

परिवर्तन से पहले

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

आइवी में विकास पांच प्रमुख प्लेटफार्मों के तहत होता है :

• आईओएस,
  
• एंड्रॉयड,
  
• वेब,
  
• स्मार्ट टीवी
  
• विंडोज + एक्सबॉक्स।
  

और, ज़ाहिर है, बैकएंड, जिसके बिना कहीं नहीं। इससे पहले कि हम परिवर्तन को अंजाम देने का फैसला करें, हमारी टीमों का गठन दक्षताओं द्वारा किया गया।



जो लोग जानते हैं, उदाहरण के लिए, स्विफ्ट या ऑब्जेक्टिव C:

• एक ही कमरे में बैठे;
  
• उत्पाद प्रबंधकों से कार्य प्राप्त करना;
  
• उन पर काम करें और एक परिणाम उत्पन्न करें।
  

सब कुछ ठीक लग रहा है, लेकिन एक समस्या है - सामग्री के उत्पाद और उपयोगकर्ता की खपत के मामले में प्लेटफ़ॉर्म बहुत गंभीर रूप से भिन्न हैं।

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

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

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



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

इसलिए, चूंकि कंपनी के पास इस बात की पर्याप्त क्षमता थी कि लचीली कार्यप्रणाली क्या है, इसलिए हम उस व्यवसाय से सहमत हैं जिसके बीच की बाधा को हमें दूर करने की आवश्यकता है:

• उत्पाद,
  
• व्यापार
  
• प्रौद्योगिकी,
  

उत्पादक रूप से बातचीत करें, और एक सामान्य बात करें।

परिवर्तन के बाद

इसके परिणामस्वरूप समर्पित मूल्य स्ट्रीम के साथ एक आर्किटेक्चर हुआ, जिसमें प्रत्येक टीम एक विशिष्ट व्यवसाय क्षेत्र में लगी हुई है।



एक नई संरचना बनाने के लिए हम:

• कई प्रशिक्षण आयोजित किए;
  
• निर्धारित किया जाता है कि हमारे व्यवसाय के लिए मुख्य क्षेत्र क्या हैं;
  
• उन्होंने स्वेच्छा से लोगों को मूल्य धारा में मजबूर किया;
  
• लागू करना शुरू कर दिया।
  

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

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

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

• iOS डेवलपर
  
• Android डेवलपर
  
• जावास्क्रिप्ट डेवलपर
  
• स्मार्ट टीवी विशेषज्ञ
  
• लेआउट डिजाइनर,
  
• परीक्षक को।
  

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

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

अवधारणा का

हमने कई बुनियादी अवधारणाओं को अपनाया है:



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

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

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

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

नई योजना में समयबद्ध

टिमलीड्स का क्या हुआ? वे समस्याओं के बारे में जागरूकता की शास्त्रीय योजना से गुजरे जिन्हें हल नहीं किया जा सकता है।



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

बेशक, इनकार के बाद गुस्सा था।

कई घोटाले हुए, जिसके बाद सौदेबाजी शुरू हुई। हर कोई एक प्रश्न के साथ आया: "चलो हम सभी का अपना तरीका है, लेकिन मेरे पास पहले जैसा है, लेकिन मैं एक मार्कर ले लूंगा," Agile "लिखूंगा अपने घर में, मैं इस शिलालेख के साथ एक टी-शर्ट में जाऊंगा, लेकिन सब कुछ पहले जैसा होगा।" यह काम नहीं किया

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

समस्याओं और कठिनाइयों

अब मैं और अधिक संरचनात्मक रूप से उन कठिनाइयों को सूचीबद्ध करने का प्रयास करूंगा जो हमें सामने आईं:



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

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

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

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

फिर शुरू हुआ: अलगाववाद, भेदभाव और ईर्ष्या ।

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

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

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

लचीली कार्यप्रणाली की ताकत यह है कि यह हर किसी के लिए मायने नहीं रखता है कि सब कुछ कैसे होता है, मुख्य बात यह है कि लोग सहमत हों और संतुष्ट हों।

यह एक ओर है। दूसरी तरफ, ताकि न्याय के बारे में है कि कौन रिफैक्टिंग में शामिल है और कौन नई सुविधाएँ कर रहा है, टीम के नेता बैकलॉग के साथ काम करना शुरू करते हैं, मैं थोड़ी देर बाद इस पर लौटूंगा।

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

एक अच्छा उदाहरण कानून FZ-54 है, जिसके अनुसार उपयोगकर्ताओं को और कर को इलेक्ट्रॉनिक चेक भेजने के साथ-साथ इंटरनेट पर सभी खरीद होनी चाहिए। आप सम्मेलनों में अपनी पसंद के अनुसार बोल सकते हैं और लचीली कार्यप्रणाली के बारे में बात कर सकते हैं और इसके बारे में क्या नियम और इतने पर हैं, लेकिन जैसे ही आपके राजस्व का 70% जुर्माना होने का जोखिम होता है, आप पूरी तरह से अलग शासन पर स्विच करते हैं और सुनिश्चित करते हैं कि आपकी कंपनी पर जुर्माना नहीं लगाया गया है। इस तरह के मामले निराले हैं, लेकिन हैं। विशेष रूप से, हमें योजना में परिवर्तन के मामले में संचार का दूसरा स्तर बनाना था। यह आसान नहीं है, लेकिन संभव है।

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

उपकरण

यहां वे उपकरण हैं जिनका हम उपयोग करते हैं।



मैं एक नए कर्मचारी के लिए मार्ग के नक्शे के साथ कहानी शुरू करूँगा। दुर्भाग्य से, यह कुछ ऐसा है जिसे हमने अभी तक नहीं सीखा है कि कैसे पूरी तरह से स्वचालित करना है और वास्तव में, प्रत्येक कर्मचारी के लिए अलग से सोचें कि वह क्या करेगा।

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

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

फिर हमने गिल्ड सिंक पेश किया - गिल्ड क्रियाओं का सिंक्रनाइज़ेशन ।

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

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

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

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

अब डेवलपर्स के मामलों में श्रम बाजार में, सब कुछ बहुत सरल नहीं है। , , . , , , . , , .

. , , Agile- , Guild Sync .

, , , . , , Guild Sync , .



, , , , , . 10 .

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

. , . , , , , . , , , . , - , , , , , .. . , « ». , , .

Guild , . - , , .

, product owner' value stream. , 10 , - , , . , product owner' . backlog' . , , . , ( , , , , ).

— , .

Teamlead —

, , - .

, . , , , , , , — .

, , , « ». , , , . , , , , value stream. , , . , , .

24 25 . - Saint TeamLead Conf .

, 40 , — 10 .