"क्या करना है जब प्रक्रियाओं में नाटकीय परिवर्तन एक टीम को आबंटित करता है।" टीम लीडर बने बैकएंड इंजीनियर का अनुभव

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

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



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

परिणामस्वरूप, हमने तूफान का सामना किया, लीड समय को आधा कर दिया और क्रॉस-फंक्शनल टीमों की प्रभावशीलता में काफी उन्नत किया। यह काफी हद तक चल रहे बदलावों के प्रति हमारे दृष्टिकोण में बदलाव, निश्चित मानसिकता से विकास की मानसिकता में परिवर्तन से मदद मिली।

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


इतिहास नंबर 1। लीड समय को कम करने के लिए विकास प्रक्रिया को बदलना


2016 में, हमारे विकास में 20 लोग और 5 टीमें शामिल थीं। टीमों ने प्रभावी रूप से एक दूसरे के साथ बातचीत की, जल्दी से सूचना और अनुभव का आदान-प्रदान किया। कर्मचारियों और टीमों की वृद्धि के साथ, सीआई / सीडी प्रक्रियाओं और कोड समीक्षाओं की शुरूआत, टीमों के बीच अन्योन्याश्रय की संख्या में वृद्धि हुई।

उदाहरण के लिए, ठेस पर एक बड़ी सुविधा शुरू करने के लिए, टीम को 6 और इंजीनियरिंग टीमों के साथ काम करने की आवश्यकता थी:

  • कोड को कोड समीक्षा दें।
  • क्यूए परीक्षण के लिए एक सुविधा दें। यदि आवश्यक हो, तो क्यूए एक विशेष परीक्षण वातावरण बनाने के लिए DevOps कमांड को शामिल करेगा।
  • रिलीज मैनेजर का उपयोग करके सुविधा को राहत दें, जो कंपनी में सभी रिलीज के लिए जिम्मेदार है।
  • अतिरिक्त कमांड को कनेक्ट करें यदि रिलीज के दौरान कुछ गलत हो जाता है।

और यह विपणन, डिजाइन और तकनीकी सहायता टीमों के साथ निर्भरता को ध्यान में रखे बिना है, जो सुविधाओं के लॉन्च में भी सक्रिय रूप से शामिल हैं।

अधिक निर्भरता, अधिक लीड समय, यानी विकास की शुरुआत से रिलीज होने तक का समय। लीड समय जितना अधिक होता है, हम उपयोगकर्ताओं को उतना कम मूल्य देते हैं।

बड़ी संख्या में संचार और कम वितरण की गति टीम को ध्वस्त कर देती है। क्या करें? निर्भरता कम करें और लीड समय को छोटा करें।

हम विकास में एक वाहक बनाने की कोशिश कर रहे हैं


इस समस्या को हल करने के लिए, हमने पहले एक कन्वेयर बनाने की कोशिश की:

  • सभी चरणों और प्रक्रियाओं का वर्णन करें;
  • एसएलए (सेवा स्तर समझौता, आवश्यक गुणवत्ता का स्तर) का परिचय उस समय को निर्धारित करने के लिए जिसके लिए कार्य को प्रत्येक चरण से गुजरना चाहिए;
  • कार्य के सुधार के लिए पिछले चरणों में पीछे हटने से रोकने के लिए सीधा प्रवाह।

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

फिर हमने प्रत्येक टीम के अंदर स्थानांतरित करने के लिए कन्वेयर को फिर से बनाने का फैसला किया।

क्रॉस-फ़ंक्शनल टीमों का निर्माण करने की कोशिश कर रहा है


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

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

हम अन्योन्याश्रितताओं का निर्धारण करते हैं


सबसे पहले, हमने वर्तमान निर्भरताएँ निर्धारित कीं जिनसे हम छुटकारा पाना चाहते हैं:

  • कोई पूर्णकालिक क्यूए इंजीनियर नहीं है, जिसके परिणामस्वरूप हम कुछ दिनों से लेकर एक सप्ताह तक परीक्षण की प्रतीक्षा कर सकते हैं।
  •   ,     -.
  • full-time -, ,   .

अन्य निर्भरताएं थीं, लेकिन हमने मुख्य रूप से तीनों पर ध्यान केंद्रित करने का फैसला किया। अब हमें QA इंजीनियर, स्क्रैम मास्टर और रिलीज मैनेजर से पहले बहुत कुछ सीखने की जरूरत थी।

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

अपने आप को मुक्त करने के लिए सीखना
हमने सहमति व्यक्त की कि हम सप्ताह में कम से कम एक बार रिलीज करना चाहते हैं। ऐसा करने के लिए, हमें टीम के भीतर एक रिलीज मैनेजर की आवश्यकता है। बैकएंड डेवलपर्स में से एक अपने स्वयं के समझौते बन गए।

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

स्वाभाविक रूप से, किसी ने हमें बैरिकेड पर नहीं फेंका। क्यूए, रिलीज मैनेजर और स्क्रैम मास्टर ने ज्ञान पारित किया और कठिन मामलों में सलाह दी।

पहली असफलता


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

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

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

इतिहास नंबर 2. एक नई भूमिका और गलती का डर


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

एक नियम के रूप में, उनमें से प्रत्येक के साथ काम करने वाले 4 कारणों में से एक कार्य को छोड़ने के निर्णय की आधारशिला है:

  •    → ,  ,   .
  •   (, , ) → , .
  •   , → :   ,   .
  •    →     .

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

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

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

वृद्धि पर स्थापना और किसी दिए गए पर स्थापना


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

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

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


पूरी योजना कैरल ड्यूक वेबसाइट पर है।

इस दृष्टिकोण में होने वाले परिवर्तनों के प्रति एक व्यक्ति के दृष्टिकोण का वर्णन किया गया है।

स्थिर मानसिकता वाले व्यक्ति (दी गई सेटिंग)
  • : «  ,      ».
  •     ,   .   , ,   .

  Growth mindset (  )

  •   ,   ,  .
  •    , .
  •     , .

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

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

कहानी नंबर 2 की निरंतरता


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

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

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

कंपनी के स्तर पर, हमारे पास ओकेआर है, इसलिए हमने इसे व्यक्तिगत प्रशिक्षण के स्तर के लिए लागू करने का निर्णय लिया। परिस्थितियां इस प्रकार थीं:

  • हम व्यक्तिगत ओकेआर में केवल वही जोड़ते हैं जो मौजूदा काम में मदद करता है;
  • मुख्य परिणाम किसी भी समय औसत दर्जे का होना चाहिए और प्रश्न का उत्तर देने में मदद करें "पिछले सप्ताह की तुलना में मैंने कितनी प्रगति की है;
  • प्रत्येक प्रमुख परिणाम में उन पहलों की सूची होती है जो इसे हासिल करने की अनुमति देते हैं;
  • (, ),   ,    ;
  •  OKRs   1:1.

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

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

एंड्री



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

कहानी नंबर 1 की निरंतरता


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

इसने हमें कम संख्या में कार्यों को सख्ती से लागू करने की अनुमति दी। हालांकि यह पहले की तुलना में आधा था, लेकिन हम इसे पूरी तरह से स्वतंत्र रूप से और बग के बिना बिक्री के लिए लाए।

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

नतीजतन, तिमाही के परिणामों के आधार पर, हम निर्भरता कम करने, टीम के भीतर दक्षताओं में वृद्धि और कठिनाइयों और गलतियों के प्रति दृष्टिकोण के परिवर्तन के कारण लीड समय को 2 गुना कम करने में सक्षम थे।



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

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

All Articles