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

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



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

चलो शुरू हो जाओ!



स्पीकर के बारे में: निकोले क्रैपीवनी (@ साइबरबेलिन ) पिछले आठ वर्षों से बुश में काम कर रहे हैं, उनमें से पांच टीम प्रबंधन और निर्माण विकास प्रक्रियाओं में शामिल हैं।


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

संचार

के साथ शुरू करने के लिए, चलो एक कंपनी के बढ़ने पर संचार के बारे में थोड़ा सैद्धांतिक रूप से बात करते हैं।

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

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

इस तथ्य के बावजूद कि इस प्रक्रिया में, जो पूरी तरह से संचार पर, वार्तालापों में बनाया गया था: "चलो इसे करते हैं," "चलो इसे तेजी से करते हैं," "चलो ऐसा करते हैं," कुछ समस्याएं हैं, ऐसी टीम को निस्संदेह इसके फायदे हैं।

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

ये केवल मूल्य हैं जो हर व्यवसाय देखना चाहता है: संसाधनों का सबसे लचीला समीकरण, न्यूनतम समय-से-बाज़ार और कम परिचालन लागत।

कंपनी बढ़ रही है - संचार "फटे" हैं।

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



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

यह एक छोटा परिचयात्मक सैद्धांतिक हिस्सा था।

अब आइए एक नज़र डालते हैं कि हम किन चक्रों से गुजरे, हमें किन समस्याओं का सामना करना पड़ा और हमने उन्हें कैसे हल किया।

संदर्भ की शर्तें

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



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

• लक्ष्य, हम यह कार्यक्षमता क्यों कर रहे हैं।
• हम किन प्लेटफॉर्म, उत्पाद, देशों को लॉन्च करने की योजना बना रहे हैं।
• उपयोग मामलों के प्रारूप में कार्यात्मक का विवरण: मुख्य मामले + "जटिल मामलों" की एक पूर्वनिर्धारित सूची, जिसके बारे में सभी लोग भूल जाते हैं।
• टोकन (कॉपीराइटर द्वारा अलग से संसाधित)।
• संचार: क्या इस कार्यक्षमता के लिए ईमेल / पुश सूचनाएँ होंगी, और यदि हां, तो कौन सी हैं।
• कंपनी में मार्केटिंग / अन्य परियोजनाओं के आधार पर रिलीज योजना।
  
• Analytics: हम परिणामों का मूल्यांकन कैसे करेंगे, परिवर्तन की सफलता का आकलन करने के लिए हमें कौन से व्यावसायिक मीट्रिक जोड़ने होंगे।

इस प्रकार, वर्तमान रूप में, उत्पाद और तकनीकी टीम के बीच बातचीत को काफी दृढ़ता से औपचारिक रूप दिया जाता है और हमें कार्य को स्थानांतरित करने की प्रक्रिया में कुछ महत्वपूर्ण बिंदुओं को न खोने में मदद करता है।

सर्वर क्लाइंट

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

प्रलेखन

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

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

रिलीज वापस नहीं

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



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

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



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

• उत्पाद टीम से टीके (पीआरडी) विकसित करने का कार्य प्राप्त करता है;
• प्रोटोकॉल डिजाइन टीम प्रलेखन तैयार करती है;
• प्रलेखन के अनुसार क्लाइंट और सर्वर भागों का विकास शुरू होता है।

ऐसी प्रक्रिया के साथ, सर्वर और क्लाइंट विकास स्वतंत्र रूप से जा सकते हैं, और हम अक्सर इसका उपयोग करते हैं।

सांख्यिकी समस्या

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

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

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

आंकड़ों को एकत्र करने और उनका विश्लेषण करने की प्रक्रिया को औपचारिक रूप देने की आवश्यकता है।



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

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



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

लोड साझा करना

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



15 लोगों की टीम में, सब कुछ काफी सरल है। हम मानते थे कि हर कोई सब कुछ करता है और मुख्य रूप से इस आधार पर कार्यों को वितरित करता है कि अब कौन मुक्त है - वह क्या करता है। 15 तक क्यों?

यह माना जाता है कि एक या टीम के नेता या तकनीकी नेता को अधिकतम 7-9 लोगों की टीम का नेतृत्व करना चाहिए। यह पर्याप्त संख्या में अधीनस्थों की एक आनुभविक रूप से स्थापित संख्या है।

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



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

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

इस विकल्प में, हम अभी काम कर रहे हैं। टीम में 30 लोग, 5 समूह और 22 घटक हैं जो हम उनके बीच साझा करते हैं। हालांकि हम इस प्रारूप में आगे की वृद्धि की सीमा नहीं देखते हैं, हम एक निश्चित पैमाने पर इसका पालन करेंगे।



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

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



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



: — , - . .

:

• . .
• , .
• , , — .
• .

:

• .
• BI, ;
• MAPI .
• , — .

200 . , , . , :)

. , , .



Time-to-marker . .



. , , , - . , , .



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

-, , . - .

• . - . .
• . 10 , . : . . .
  
• - . bus- , . , , , .
  

, ( — ), . , OX . . OY .

, .



. - — . - , time-to-market , . - , , - , - , . , , . .



. - . , , . . , workflow. (, ) . - . , , .



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

. , , .



70–80 . , , . , . , - , .



.

— , - — .

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

—

, , . , . , .



. , . , , , . , - , , , server-side , . , , - , . , server-side, , . 14 , . - , server-side. , server-side 50/50. , , , . , , , - , , . , , .



.

— , . , , - , , .

. , , , , . « ».

. , — , , , . 50/50 10- .



, — . , . , 3 . - , 12 . 3 — , . , , , , , , , - , . — . . 11:00, — 9:00. , .

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



, , « ». - , , - . :

• : — , ..
• — , , , : « ». , .

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



कोई भी इस तथ्य को रद्द नहीं करता है कि आपको अधिक बार मिलने की आवश्यकता है । यहाँ सब कुछ मानक है:

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

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

हम कैसे रहते हैं।

हम आपको संत TeamLead Conf पर किसी और के संगठनात्मक अनुभवों के एक नए हिस्से की जासूसी करने के लिए आमंत्रित करते हैं। कार्यक्रम में बहुत प्रसिद्ध कंपनियों के भाषण शामिल हैं: Sberbank-Technologies, Avito, JetBrains, Spotify ... हाँ वे सभी शांत हैं!

यह रिपोर्ट दर्जनों रिपोर्ट्स में से एक है, यदि आप तब तक इंतजार नहीं करना चाहते जब तक कि हम उन्हें डिक्रिप्ट करने के लिए हमारे हाथ न लगायें और उन्हें Habré पर प्रकाशित करें, तो हमारे YouTube चैनल पर कॉन्फ्रेंस प्लेलिस्ट देखें ।

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