डार्क साइड फुर्तीली

चौकस पाठक टेप के माध्यम से फ़्लिप करता है और सवाल पूछता है: "फिर से, चुस्त के बारे में पाठ?"। हाँ।

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

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

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

जब आप चुस्त-दुरूस्त लागू करते हैं, तो आप एक चांद अन्वेषण परियोजना तैयार कर रहे हैं, न कि जानकर
दूसरी तरफ क्या है

यह सब नई विकास प्रक्रियाओं को शुरू करने के प्रयास से शुरू होता है।

Scrum, kanban, scrambana या कुछ अन्य स्थानीय बाइक इतनी महत्वपूर्ण नहीं हैं।

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

जावा - बायां, जावास्क्रिप्ट - दायां

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

यह सही लगता है, लेकिन वास्तविक जीवन में, सब कुछ थोड़ा गलत है।

अधिकांश शास्त्रीय विकास विभागों में, एक मोनोलिथ के साथ काम करना अधिक लाभदायक है। इस मामले में, सभी विशेषताएँ संलग्न हैं - 3-4 सप्ताह में रिलीज चक्र, लंबे परीक्षण और विधानसभा।

कभी-कभी एक मोनोलिथ सामान्य होता है

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

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

परीक्षण सुधार

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

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

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

वास्तव में, 20 टीमों को स्टैंड का उपयोग करना चाहिए, लेकिन वे नहीं कर सकते, क्योंकि उनमें से एक ने सब कुछ तोड़ दिया

परीक्षण खड़ा है के बारे में

एक बार, हमारे पास कई मोनोलिथ थे, प्रत्येक एक परीक्षण बेंच के साथ, और हर कोई खुश था। एक बार हमने स्टैंड के पृथक्करण के लिए एक जटिल परियोजना बनाई, हमने टीमों को आवंटित किया, और फिर 20 स्टैंड थे।

अब उनमें से 70 हैं, लेकिन हम 200 पर लक्ष्य कर रहे हैं - ताकि हर कोई, नि: शुल्क, और कोई भी नाराज न हो।

व्यवस्थापक के साथ संवाद से:
- मुझे बताओ, तैनाती स्वचालन कहां है?
- हर दो सप्ताह में एक बार गणना में एक घंटा लगता है, मुझे यहां क्या स्वचालित करना चाहिए?

वास्तव में, यह: (200 खड़ा + उत्पादन) * (50+ घटक) = तैनात करने का बहुत प्रयास।
अब हमारे पास 50 से अधिक घटक हैं जो रोबोट रोल आउट करता है। अगर उसके लिए नहीं, तो हर कोई बुरा होगा।

इस स्तर पर, कंपनी, जो फुर्तीली की ओर जाती है, में उत्पादन के लिए असेंबलिंग और डिलीवरी के लिए स्वचालित सिस्टम होंगे, टीम के काम में धीरे-धीरे सुधार होगा और प्रदर्शन भी बढ़ेगा - प्रति सप्ताह 60-80 रिलीज तक, और प्रत्येक घटक 2-3 बार एक दिन में जारी किया जाएगा। ।

इस बिंदु पर, हर कोई समझता है कि सिस्टम एक व्यक्ति के लिए इसे समझने के लिए बहुत बड़ा हो गया है

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

जीवन की कहानी:
"सामान्य तौर पर, किसी ग्राहक पर 3 बार दस्तक देने की कोशिश करना सामान्य है, लेकिन यह ग्राहक विशेष है, और हम 100 बार दस्तक देंगे, एक सुधार कारक है, और इसे छूने की आवश्यकता नहीं है, कृपया इसे स्पर्श करें, यह ऐसा नहीं है।"

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

अन्य निगरानी

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

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

परमाणु ऊर्जा संयंत्र की तरह

जीवन की कहानी : लंबे समय तक हमने अपने उत्पादों में बग की खोज की और उन्हें ठीक किया। उसके बाद, ग्राहकों में से एक ने कई प्रक्रियाओं को तोड़ दिया जिसमें इस बग को ध्यान में रखा गया था।

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

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

यदि इसे दूर किया जाता है, तो सिस्टम "छाता" परियोजनाओं को छोड़कर सभी मामलों में काफी अच्छी तरह से काम करेगा।

छाता परियोजनाओं

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

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

Life Story: Spotify एक अनुकरणीय फुर्तीली कंपनियों में से एक है। कुछ बिंदु पर, वे एक परिवार की सदस्यता के साथ आए, लेकिन अपने स्वयं के रोडमैप और योजनाओं वाले टीमों के बीच तालमेल और योजना बनाने में कठिनाई के कारण इसे महसूस नहीं कर सके। एक साल बाद, Google और Apple ने परिवार की सदस्यता समाप्त कर दी।

सिंक्रनाइज़ेशन और शेड्यूलिंग विरोध

छाता परियोजनाओं के साथ मुख्य समस्या सभी भाग लेने वाली टीमों का सिंक्रनाइज़ेशन है। यह इस तथ्य से जुड़ा है कि लोग बातचीत करना पसंद नहीं करते हैं।

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


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

सामान्य तौर पर, सिंक्रनाइज़ेशन की आवश्यकता होती है और इसके बिना आप आगे नहीं बढ़ सकते। यह एक स्पष्ट समय सीमा और उच्च आलोचना के साथ परियोजनाओं में जीवन को जटिल बनाता है - समय सीमा 10% से 50% तक होती है, और यह अक्सर अस्वीकार्य है।

इसे कैसे प्रबंधित करें?

वितरित विभाग में शास्त्रीय नेता यह नहीं समझते हैं कि उनकी भूमिका क्या है क्योंकि उन्हें प्रतिमान "मुझे सभी को कार्य दिए गए थे" पढ़ाया गया था, और मुझे "मेरे पास बिल्कुल भी लोग नहीं हैं, मैं कंपनी में क्यों हूँ?"



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

सामान्य तौर पर, जब ऐसा प्रश्न लगता है, तो नेता को या तो बदलने या सिखाने की आवश्यकता होती है।

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

आईटी में संस्कृति

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



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

चंचल - हिमशैल की नोक

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

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

लोग नहीं हैं। चंचल को नई दक्षताओं की आवश्यकता है, जो लोगों के पास इतने सारे नहीं हैं। यह एक दुष्चक्र से बाहर निकलता है - कोई लोग नहीं हैं -> सब कुछ बहुत अच्छा नहीं कर रहा है -> कोई पैसा नहीं है -> लोगों से लेने के लिए कहीं नहीं है।

तीन निष्कर्ष

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

उपरोक्त सभी में एक परेशानी है। पूरे रास्ते जाओ! = सफलता के लिए आओ। इसे पास न करना = असफल होने की गारंटी।

लेकिन अगर आप रास्ते में हैं - शुभकामनाएँ!