30 टीमों के लिए 10 टाइपसेटर्स। क्या तुम पागल हो?

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

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

जिनके पास बहुत सारे पत्र हैं, उनके लिए एक वीडियो है ।



और अब थोड़ा संदर्भ। हम एक उत्पाद को विकसित करने के लिए समर्पित एक वरिके उत्पाद कंपनी हैं। यह कार्यों और परियोजनाओं पर सहयोग करने के लिए एक एकल पृष्ठ अनुप्रयोग (एसपीए) है। कुल में, कंपनी में 700 से अधिक लोग हैं, और 300 से अधिक इंजीनियर विकास पर काम कर रहे हैं। सभी कर्मचारियों को 30 उत्पाद टीमों में विभाजित किया गया है - उनमें से प्रत्येक स्क्रैम पद्धति के अनुसार काम करता है और विभिन्न विशेषज्ञों से युक्त होता है: बैक-एंड, फ्रंट-एंड, टेस्टर, लेआउट डिजाइनर, यूएक्स-डिजाइनर, आदि। प्रत्येक टीम अपने स्वयं के उत्पाद पर काम करती है। इन सभी टुकड़ों को फिर एक बड़े उत्पाद में इकट्ठा किया जाता है, जिसका उपयोग दुनिया भर की 16 हजार से अधिक कंपनियों द्वारा किया जाता है।

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

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

इस तथ्य के बावजूद कि केवल 30 टीमें व्रीके में काम करती हैं, दस के कोडर केवल 20 की जरूरतों को पूरा करते हैं। तथ्य यह है कि सभी टीमें इंटरफ़ेस को बदलने के लिए कार्यों पर काम नहीं करती हैं, इसलिए उनमें से केवल 20 अपने स्थायी लेआउट डिजाइनर के साथ "सशस्त्र" हैं।

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

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

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

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

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

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

1. सभी लोगों को समान रूप से उच्च स्तर का होना चाहिए। हर कोई आवश्यक तकनीकों के पूरे सेट का उपयोग करता है, सभी शक्तियों और सीमाओं को जानता है, प्रक्रियाओं में अच्छी तरह से वाकिफ है और एक ही दृष्टिकोण का पालन करता है। फिर, वास्तव में, आप किसी भी इंजीनियर को कार्य दे सकते हैं, और वह इसे और साथ ही किसी अन्य सहयोगी को हल करेगा;
2. हर कोई समान रूप से कोड लिखता है। ठीक है, या कम से कम बस एक ही है। फिर, वास्तव में, जब पहले पैराग्राफ के साथ संयुक्त, हम एक सुसंगत, अच्छी तरह से बनाए रखा कोड है कि किसी भी टीम के सदस्य के साथ काम कर सकते हैं;
3. हर कोई जानता है कि कौन क्या करता है। यह कार्य के बीच स्विच करते समय प्रवेश सीमा को कम करता है, और फिर, वास्तव में, यहां तक ​​कि अगर कोई बीमार हो जाता है या किसी अन्य कारण से वर्कफ़्लो के "बाहर गिर जाता है", तो सहकर्मियों में से कोई भी हाथ पर होगा: यह तथाकथित बस निर्माता की संभावना कम कर देता है;
4. टीम के सदस्य "शेयर नवोदित"। टीमों की संख्या बढ़ रही है, जैसा कि इंजीनियरों की आवश्यकता है। ऐसे लोगों को पहले से ही नियुक्त करना मुश्किल है जो पहले तीन बिंदुओं के अनुरूप हैं, इसलिए यह अच्छा होगा यदि मौजूदा लोग मौजूदा ज्ञान को बनाए रखते हुए नवोदित या क्लोनिंग साझा कर सकते हैं। फिर हाँ, स्केलिंग के साथ कोई समस्या नहीं होगी;
5. सबको उड़ना सिखाओ। विभिन्न देशों में कई कार्यालयों के साथ एक कंपनी के लिए, विभिन्न कार्यालयों के लोगों को एक जगह पर इकट्ठा करने में सक्षम होना आवश्यक है, क्योंकि संचार स्थापित करने के लिए गैर-मौखिक संचार का मूल्य शायद ही कम करके आंका जा सकता है। और यह अच्छा होगा यदि दोस्तों, जब उन्हें किसी के साथ सिंक्रनाइज़ करने की आवश्यकता होती है, तो कॉमिक्स में, बस "दूसरे कार्यालय में बाहर" उड़ सकता है। फिर, शायद, दुनिया भर में टीमों के वितरण के साथ कोई समस्या नहीं होगी।

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

ऐसा लगता है कि इन सभी बिंदुओं को पूरा करना असंभव है, खासकर आखिरी दो। लेकिन हम, Wrike में लेआउट विभाग में, इसके करीब हैं। और अब मैं आपको उन 7 प्रथाओं के बारे में बताऊंगा जो हमें उस आदर्श के जितना संभव हो सके उतना करीब होने में मदद करते हैं।

1. दक्षताओं की वर्तमान सूची

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

यह क्या देता है? उम्मीदवारों के लिए स्पष्ट आवश्यकताएं - उनका ज्ञान जितना निकट होगा, आवश्यक दक्षताओं की सूची से बेहतर होगा।

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

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

दक्षताओं की पूरी सूची के साथ, हमने उन्हें आसानी से 13 दिशाओं में वर्गीकृत किया है। यहाँ वे हैं:

• Google की क्षमता;
• पर्यावरण (उपकरण, गिट, सेवा, आदि);
• एचटीएमएल;
• सीएसएस;
• सामान्य दृष्टिकोण (HTML / CSS);
• यूआई किट;
• स्क्रम;
• कोणीय + डार्ट;
• कोड की समीक्षा;
• जे एस;
• प्रोग्रामिंग मूल बातें;
• यूआई / इंटरफेस;
• हॉटकी।

और अगर वही HTML / CSS सामान्य उद्योग मानक हैं, और हम उम्मीद कर सकते हैं कि उम्मीदवार उनसे परिचित होंगे, तो काफी विशिष्ट बातें थीं। उदाहरण के लिए, हमारी आंतरिक UI किट लाइब्रेरी। या हमारे आंतरिक विशिष्ट उपकरण, पर्यावरण की विशेषताएं, विशेष समस्याओं को हल करने के लिए दृष्टिकोण की विशेषताएं आदि। वही डार्ट एंगुलर (डार्ट पर हम जो उत्पाद लिखते हैं उसका अगला सिरा) एक दुर्लभ वस्तु है, कुछ लोगों ने इसके साथ काम किया और एक संभावित उम्मीदवार से परिचित होने के लिए इनमें से कम से कम एक मानक की अपेक्षा कम से कम भोली है। यह पता चला है कि भले ही हम एक अनुभवी विशेषज्ञ को काम पर रखते हैं, फिर भी वह अपने कार्यों के सफल समापन के लिए आवश्यक चीजों का एक अच्छा आधा हिस्सा नहीं जानता है। यह पता चला है कि एक नए व्यक्ति को एक टीम में भर्ती करना और उसे प्रशिक्षित करना हमेशा थोड़ा प्रशिक्षण होता है। और अधिक ज्ञान संचित है, प्रशिक्षण अधिक जटिल और लंबा है।

यह पता चला है कि तकनीकी विशेषज्ञता के लिए 100% हमारी आवश्यकताओं को पूरा करने वाले व्यक्ति को खोजना असंभव है, और हमें उसे सीखने की आवश्यकता होगी। तो, एक शुरुआत के लिए कुछ सीखने का कौशल होना चाहिए। और ये व्यक्तिगत विशेषताएं हैं, तथाकथित शीतल कौशल।

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

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

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

2. एकीकृत प्रशिक्षण के साथ जहाज पर

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

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

सामान्य तौर पर, हमारे ऑनबोर्डिंग की प्रक्रिया एक अलग लेख के लिए एक विषय है, लेकिन अब मैं एक प्रमुख बात पर ध्यान देना चाहता हूं: दक्षताओं का गुलाब।

पहले से तैयार की गई योग्यता समूहों के आधार पर, हम किसी भी कर्मचारी या यहां तक ​​कि प्रत्येक दिशा में एक उम्मीदवार का मूल्यांकन कर सकते हैं और इस तरह के रेडियल आरेख का निर्माण कर सकते हैं:



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

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

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

और, परिणामों के अनुसार, इस प्रशिक्षण से गुजरने के बाद, गुलाब का पुनर्निर्माण किया जा रहा है, और प्रगति स्पष्ट हो रही है।



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

यह क्या देता है? शुरुआती लोगों के लिए एक स्पष्ट विकास योजना। इस प्रकार, हम सभी "पुराने" और "नवागंतुकों" के बीच अंतर को कम करते हुए, एक ही स्तर पर लाते हैं।

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

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

3. नियमित प्रशिक्षण गतिविधियाँ

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

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



इस तरह के चार्ट को देखते हुए, किसी क्षेत्र में एक विशेषज्ञ से संपर्क करना आसान है और अपने ज्ञान को सभी के साथ साझा करने के लिए कहें।

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

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

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

4. अनिवार्य क्रॉस-समीक्षा

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

ताकि ऐसा न हो और समान कार्य लगभग सभी एक ही द्वारा हल किए जाते हैं, प्रत्येक कार्य और मर्ज अनुरोध एक अनिवार्य समीक्षा कोड के माध्यम से होता है।

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

क्रॉस रिव्यू क्या देता है?

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

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

5. कोड शैली और स्वचालित लाइनिंग

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

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

स्वचालित लाइनिंग क्या देता है?

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

दूसरे, कोड की समीक्षा करना और पास करना आसान है - एमआर में बस कोई त्रुटि नहीं है और कोई कोड शैली त्रुटियां नहीं हो सकती हैं और आप कार्य के सार पर सटीक रूप से ध्यान केंद्रित कर सकते हैं।

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

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

6. डेली स्टैंड-अप

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

यह महत्वपूर्ण है कि स्टैंड-अप जल्दी से गुजर जाए, दिन में 15 मिनट से अधिक नहीं। क्योंकि प्रति दिन 15 मिनट भी, 10 लोगों से गुणा करने पर प्रति माह 40-50 मानव-घंटे की लागत मिलती है। यह एक व्यक्ति के काम के पूरे एक सप्ताह की तरह है। इसलिए, रैली को यथासंभव छोटा और प्रभावी होना चाहिए। और केवल अगर ऐसे मुद्दे हैं जिनके लिए एक अलग चर्चा की आवश्यकता होती है, तो वे दैनिक के ढांचे से बाहर हो जाते हैं और दूसरों के समय को बर्बाद किए बिना इच्छुक लोगों द्वारा अलग से चर्चा की जाती है।

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

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

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

7. विभाग की परियोजनाओं में सभी की भागीदारी

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

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

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

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

हर कोई अपने लिए उस परियोजना को चुन सकता है जो उसे रुचिकर लगे। इस प्रकार, एक व्यक्ति खुद को उसके हित के क्षेत्र में विकसित करता है, और पूरे विभाग को पंप करता है।

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

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

और उड़ानों के बारे में क्या?

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

लेकिन क्या होगा यदि आपकी कंपनी अभी तक ऐसी प्रथाएं नहीं करती है?

यदि आप टीम लीडर या लीडर हैं, तो सलाह बहुत सरल है: "यहां चेकलिस्ट है, इसे ले लो और इसे लागू करो।" मुझे लगता है कि प्रत्येक नेता अपने कर्मचारियों की वृद्धि और कोड की गुणवत्ता में रुचि रखता है।

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

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