ट्राइब्स, गिल्ड्स, बिल्ड ट्रेन एंड नो टीडीडी: कैसे मोबाइल डेवलपमेंट में काम करता है उबर, स्पॉटिफाई, ओडनोकलास्निक और अवितो

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

---

फिलिप उवारोव, Spotify पर Android डेवलपर। कंपनी पिछले छह महीनों से काम कर रही है - प्लेटफ़ॉर्म टीमों में से एक जो Spotify पर अन्य डेवलपर्स का समर्थन करती है। स्वीडन में रहता है। Spotify से पहले, उन्होंने एक स्वीडिश स्टार्टअप में काम किया, और इससे पहले भी Avito में।

ओड्नोकलास्निक में अरेटम ओलकोव, लीड आईओएस डेवलपर। वह वर्तमान में एक उत्पाद के iOS विकास का नेतृत्व कर रहा है। विकास के अलावा, वह वास्तुकला, डिजाइन, कार्य आवंटन, डिजाइन के साथ समन्वय, बैकएंड एपीआई, आदि के लिए जिम्मेदार है। कुल मिलाकर, Odnoklassniki में अब लगभग 60 मोबाइल इंजीनियर हैं जो छोटी टीमों में विभाजित हैं। आर्टेम की टीम - 11 लोग।

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

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

---

चलो सुविधाओं के साथ शुरू करते हैं। कंपनी में डेवलपर्स के बड़े कर्मचारियों के साथ टीम के काम में क्या अंतर है?

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

मैक्सिम एफिमोव (उबेर): मेरी राय में, सबसे विशेषता विशेषता काम की गति है।

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

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

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

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

आपकी टीम कंपनी के भीतर दूसरों के साथ कैसे तालमेल बिठाती है?

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

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

मैक्सिम एफिमोव (उबेर) : हमारे पास छोटी टीमें हैं, जिनमें से प्रत्येक में 20 से अधिक लोग नहीं हैं। वे संरचनात्मक इकाइयों में एकजुट हैं जो बड़े क्षेत्रों के लिए जिम्मेदार हैं, उदाहरण के लिए, एक मोबाइल एप्लिकेशन। इसी समय, टीमें स्वयं काफी स्वायत्त हैं, क्योंकि अगर हम प्रत्यक्ष अधीनता के साथ एकल नियंत्रण प्रणाली के लिए सब कुछ कम करते हैं, तो हमें एक बहुत ही अक्षम प्रणाली मिलेगी।

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

आर्टेम ओल्कोव (ओडनोक्लास्निक): हम एक अलग सेवा में लगे हुए हैं। तो मान लीजिए कि हम एक बड़ी कंपनी के भीतर एक स्टार्टअप हैं। बेशक, हम एक ही बुनियादी ढांचे में रहते हैं। और बाकी सब चीजों में, हम बहुत अलग हैं। एकीकरण के ढांचे के भीतर भी, हम अक्सर अपने स्वयं के उपकरणों के सार्वजनिक एपीआई का उपयोग करते हैं।

क्या बड़ी टीमों की कोई समस्याएँ हैं? आपको क्या करना है?

एवगेनी सुवोरोव (एविटो) : मेरी राय में, एक बड़ी टीम में प्रक्रियाएं मुख्य रूप से प्रभावित होती हैं।

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

और इसका मतलब है कि उच्च गुणवत्ता वाले निरंतर एकीकरण, निरंतर वितरण, परीक्षण स्वचालन।

फिलिप उवरोव (स्पॉटिफ़) : मुझे लगता है कि सबसे बड़ी समस्या कंपनी के भीतर ज्ञान का प्रसार है। मुझे इस बात का अंदाजा नहीं है कि कुछ दूर की टीमों में क्या हो रहा है। और विपरीत दिशा में भी यही सच है: कई टीमों को पता नहीं है कि हमारे पास Spotify पर एक एनालिटिक्स टीम है। यह वह जगह है जहाँ पैमाने को महसूस किया जाता है।

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

आर्टेम ओल्कोव (ओडनोक्लास्निकी): हां, वास्तव में दो समस्याएं हैं: आधुनिकीकरण सहित ज्ञान का हस्तांतरण और कार्यों का समन्वय।

क्या बड़ी कंपनियों के पास इन समस्याओं को हल करने के लिए कोई सिद्ध तरीके हैं?

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

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

आर्टेम ओल्कोव (सहपाठियों): हमने अपराधियों का उच्चारण नहीं किया है।

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

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

दूसरी समस्या - क्रियाओं का समन्वय - सक्षम प्रबंधन द्वारा हल किया जाता है।

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

एवगेनी सुवोरोव (एविटो): हम सप्ताह में 2 बार बैठकें आयोजित करते हैं। हम स्वचालन से प्यार करते हैं, और यह कार्य भी स्वचालित है। एक ऐसी प्रक्रिया है जहां सप्ताह के दौरान लोग उन विषयों पर फेंकते हैं, जिनके बारे में वे iOS या Android डेवलपर्स की एक सामान्य बैठक में बात करना चाहते हैं। और अगर कोई उपपंजी है, तो हम जा रहे हैं। बैठकों के दौरान, उत्पाद टीम उन विशेषताओं के बारे में बात करती है, जो उन्होंने उत्पाद में कार्यान्वित की हैं, क्योंकि अन्यथा उन सभी चीज़ों पर नज़र रखना मुश्किल है जो होती हैं।

हम शुरू से ही मिले, लेकिन यह कंपनी की वृद्धि के साथ था कि ये बैठकें सबसे अधिक प्रासंगिक हो गईं।

इसके अलावा चैट रूम हैं जहां आप किसी भी विशिष्ट मुद्दों पर चर्चा कर सकते हैं।

किस सिद्धांत से किसी कंपनी में कई डेवलपर्स को विभाजित करने के लिए समझ में आता है - मंच द्वारा, कार्यक्षमता द्वारा, या किसी अन्य तरीके से?

आर्टेम ओल्कोव (ओडनोक्लास्निक): यह अब भी निर्भर करता है कि आप क्या करते हैं और आप कैसे पैसा बनाते हैं।

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

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

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

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

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

एवगेनी सुवरोव (एविटो): मैं सहमत हूं । इस तरह की संरचना काफी सफल है और हमने अभी हाल ही में इसे अपने एविटो में लागू किया है, कम से कम व्यवसाय के किराने के हिस्से में।

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

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

उसी समय, हमारे पास अभी भी छोटी प्लेटफ़ॉर्म टीमें हैं, जिन्हें हम इसे "क्षैतिज" निर्णय कहते हैं, जो सभी उत्पाद टीमों को रोल आउट करते हैं।

क्या टीम पुनर्गठन अक्सर होता है?

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

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

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

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

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

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

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

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

एवगेनी सुवोरोव (एविटो): मेरी राय में, जब वरिष्ठों की भर्ती करते हैं, तो आपको डर नहीं होना चाहिए कि उनके सिर में उनका अपना राजा है या वे उनका पालन नहीं करेंगे।

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

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

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

निर्धारण, सिंक्रनाइज़ेशन, कार्य वितरण

क्या एक बड़ी कंपनी (यहां तक ​​कि छोटी टीमों में) के डेवलपर्स की योजना और सिंक्रनाइज़ेशन बहुत अधिक ऊर्जा लेता है?

फिलिप उवरोव (स्पॉटिफ़) : यह केवल उत्पाद द्वारा टीमों का विभाजन है, न कि कार्य द्वारा: हम केवल कंपनी के भीतर अपने छोटे उत्पाद की योजना बनाते हैं और हम अक्सर इस बात की परवाह नहीं करते हैं कि बाकी मिलियन डेवलपर क्या करते हैं।

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

मैक्सिम एफिमोव (उबेर): हमारे मामले में - बहुत बड़ा नहीं है। जब मैंने आउटसोर्सिंग पर काम किया था तो शायद यह उससे 1.5-2 गुना अधिक था।

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

एवगेनी सुवोरोव (एविटो): हमने शुरू में लगातार रिलीज के साथ सिंक्रनाइज़ेशन समस्या को हल किया। नतीजतन, सिंक्रनाइज़ेशन खुद अब थोड़ा सा लेता है। सब कुछ लगभग स्वचालित है।

क्या मुझे कार्यों को एक विशेष तरीके से वितरित करने की आवश्यकता है ताकि कोड की गुणवत्ता को नुकसान न हो?

फिलिप उवरोव (स्पॉटिफ़) : बड़ी टीमों में, यह जिम्मेदारी के क्षेत्र द्वारा उत्पाद को वितरित करने के लिए समझ में आता है। इस प्रकार, हमेशा ऐसे लोग होंगे जो जिम्मेदारी से उनसे संपर्क करेंगे क्योंकि वे बाद में इसके साथ रहेंगे। उनका संदर्भ नहीं बदलता है, अर्थात् , ( 10 , 5 , ).

« », - , backend- .

(Avito): , code review. , backend- — Python, PHP, Go — Avito. , .. , — .

- , ?

(): , . , , , — : , , , , .

(Avito): , , — , , .

, . , - , . . .

backend- , — — . , .

- / ? ?

(Spotify) : . , , Gradle Bazel Teamcity , . , .

(Uber): Uber- , . , , Kotlin. , , . . . , « » : « Kotlin-». Kotlin , .

, . , - , . , .

(Avito): , . . , , ().

Technology Radar. : « , 5 , .. ». , Technology Radar, , , , - , , - , - , - . , , . , Technology Radar .

?

(Uber): , . , 10 - - . . 100 , , 99. , , , .

( )?

(Avito): , — , , , . — .

- , , .

. Android- — IDE early adopted preview . , .

(Spotify) : , Kotlin — - . , Java Android, Kotlin . , — Facebook — Kotlin- , , , Kotlin .

Flutter.

(): , iOS — , Apple. . , . .

, , — . Unidirectional Data Flow.

Swift?

(): . Swift, 150 Objective-C, .. Swift , .

Objective-C , Swift? , , Swift — HR-PR-, , Objective-C .

(Avito): . Swift . , , , . . Swift , Objective-C, , , .

( )?

(): . Apple , , Swift , open source. , . Objective-C .

( ) — — - , , . , . , — . iOS — , , .

? TDD ?

(Spotify) : , Android , . , .

(): , . Unit- .

Unit- , ( ). (API, UI ..) — .

(Uber): , TDD, . , , — .

(Avito): . , , -. UI- unit- . , — , UI-.

. — . TDD.

TDD . Android- , . AppsConf 2018 TDD.

, .

- ?

(Spotify) : , . 100% - unit- .

(Uber): , . , . .

- «» ?

(Spotify) : — .

, - (proof of concept ), , . , , , .

(Avito): , , QA-, , backend, frontend . . , , QA.

?

(Spotify) : , code review — . CI: , code style — AppsConf 2018.

: pull request, code style, ; , . , git-. — , : , .

(Uber): Code review — , . , . .

(Avito): code review- -. , , -, , , . -.

, . . , . , , (« ?»). , , .

. , . , , . . , - code review. , .

?

(Spotify) : , .

(): , , . , «» «». — , . — — . . - .

. , Android- .

(Uber): , , — . .

build train, . - — . .

. , : . , .

(Avito): — 12 . , . , - ( , -).

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

. , , . . . , , , . .

. AppsConf 2018ApplsConf 2018 . , .