बहुत बड़ी टीमों में संतुलित विकास। यैंडेक्स रिपोर्ट

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

रिपोर्ट में, मैंने इन चरम सीमाओं से बचने और सफल टीमवर्क प्राप्त करने के बारे में बात की।



- मैं बात करना चाहता हूं कि बड़ी टीमों में कैसे रहना है। एक बड़ी टीम है जब इस कमरे में और भी अधिक लोग हैं।

और मैं चाहता हूं कि वे जीआईएफ पर इन लोगों की तरह आसानी से काम करें:



मेरे पास एक बहुत बड़ी टीम नहीं है, लेकिन मैंने अभी कंपनी में बड़ी टीमों के साथ जो कुछ हो रहा है, उसके बारे में थोड़ा जासूसी की है, और मैं इसे आपके साथ साझा करना चाहता हूं।

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

और इनमें से कई “कई” हैं, जो डेवलपर्स हैं। हम कई अलग-अलग उत्पाद बनाते हैं, न केवल वेब के लिए। सामानों के बारे में, कारों के बारे में, खाने के बारे में, सभी प्रकार के लोहे के टुकड़े, कृत्रिम बुद्धि है। और डेवलपर्स इसमें शामिल हैं। यहां तक ​​कि अगर, यह प्रतीत होता है, हम कारों या भोजन के बारे में बात कर रहे हैं।



हमारी कई सेवाएं हैं। वे स्लाइड पर फिट नहीं होते हैं। मुझे आशा है कि मैंने आपको आश्वस्त किया है कि यैंडेक्स बहुत बड़ा है। बड़ी चीजों का प्रबंधन करना मुश्किल है।

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

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



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



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



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



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

और वह कहता है: “कॉमरेड चीफ डिज़ाइनर, मेरे पास एक अच्छा विचार है। मुझे एक डिजाइनर की जरूरत है। ” वह जवाब देगा: "ठीक है, सबसे पहले, आपका विचार अजीब है, और दूसरी बात, सभी डिजाइनर मेरे साथ व्यस्त हैं। Q5 पर आओ। ”

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

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



अंत में, वह खुद एक विकास टीम प्राप्त कर सकता है और कुछ कर सकता है। एक तरफ, इस तरह से केवल सबसे अच्छा विचार बचता है, दूसरी तरफ, कुछ करना वास्तव में मुश्किल है।



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



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

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

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



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

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



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

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



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

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

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

इस संतुलन की तलाश में, यह पता चला है कि कुछ को फिर से बदलने की आवश्यकता है। इस बीच, टीम फिर से नाटकीय रूप से बढ़ रही है।



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



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

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

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

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



टीमें अस्थायी, तेज हैं, वे इस समय कुछ सबसे महत्वपूर्ण चीजों पर ध्यान केंद्रित कर सकती हैं।



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



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

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

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

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

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

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



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



ठीक है, सब कुछ कैसे काम करना चाहिए पर सहमत हुए। लेकिन अगर हमारे पास एक उत्पाद के बारे में एक संरचनात्मक बॉस और एक मालिक है, तो कैसे मूल्यांकन करें कि क्या सब कुछ ठीक हो गया है? सर्गेई बेरेज़नोय ने पिछले शनिवार से पहले वर्ष के बारे में विस्तार से बात की। मैं संक्षेप में सामान्य विचार को दोहराऊंगा।

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



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

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

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

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



, : « , , ?». , . , , . , - , , .

, . , , . ? , , , , .

, . , - , , . , . , , — , , , : «, , . ».

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

: — , , , , . — . .