👃🏾 🙃 🚶🏽 पड़ोसियों को अपनी परियोजना पर काम करने के लिए कैसे प्राप्त करें, या बैंक के लिए इनरसोर्स 👧🏽 👨🏼 🙍🏽

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

एक आंतरिक स्रोत क्या है?

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

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

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

बेशक, Sberbank एकमात्र कंपनी नहीं है जो ऐसा कुछ करने के लिए हुई है। 2015 में, इनरसोर्स सोर्स समुदाय बनाया गया था , जिसने दृष्टिकोण को लोकप्रिय बनाया और खोज इंजन में खोजने के लिए शब्द से अंतर को हटा दिया। इस समुदाय ने दर्जनों कंपनियों के अनुभव को इकट्ठा किया है और अपनी कंपनी में इनरसोर्स लागू करने के लिए प्रभावी सिफारिशें की हैं, और एक वर्ष में दो बार एक अनुभव विनिमय सम्मेलन आयोजित करता है। अभी भी कई जानी-मानी प्रौद्योगिकी कंपनियां हैं जो कि मुख्यधारा बनने से पहले ~~Pechenegs और Polovtsy के बाद से~~ ऐसा कर रही हैं ।

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

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

मैं इसे क्यों एकत्र करूंगा?

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

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

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

इस सबका क्या करना है?

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

दो। सभी इंजीनियरिंग टूल्स (JIRA, Confluence, Bitbucket, Nexus) पर एक एकल खोज इंजन के साथ एक "छाता" बनाएं, आंतरिक और बाहरी सेगमेंट (हाँ, बदनाम अल्फा और सिग्मा) को मिलाकर।

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

क्या सुझाव दिया गया था?

डेवलपर्स के साथ संवाद करने की प्रक्रिया में, हमने अपने भीतर ऐसी बंद टीम के मुख्य कारण की पहचान की: उत्पादों के बीच बातचीत के मौजूदा तरीके। संबंधित प्रणालियों के शोधन की कोई भी चर्चा तीन परिदृश्यों में से एक के अनुसार हुई।

"रुको"

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

समझौता

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

"अस्थायी स्थायी ठूंठ"

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

हमने एक चौथा रास्ता प्रस्तावित किया। निष्पादन समय को कम करते हुए, उनकी संवेदनशील पर्यवेक्षण के तहत आसन्न टीम के कोड आधार में परिशोधित करें।

InnerSource

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

हमारी राह

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

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

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

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

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

HR : Google, , 10 % .
PR : Microsoft, open source.
: , - Delphi GraphQL, 10 % , !
, API, JIRA- .

कुछ त्रुटि के साथ, हमने BitBucket में हो रहे अंतर-टीम इंटरैक्शन को ट्रैक करना सीखा और जानकारी प्राप्त की कि हमारे पास हर महीने जोड़े जाने वाले इनरसोर्स परिवर्तनों के 30-50 नए लेखक हैं। बैंक में डेवलपर्स की संख्या के मामले में आंकड़ा बहुत प्रभावशाली नहीं है, लेकिन ये केवल व्यावसायिक कार्यों में सुधार हैं।

अपेक्षित रूप से, विभिन्न एकीकरण बसों और ETL सेवाओं में डेटा-चालित परिवर्तन बहुत लोकप्रिय हो गए। यह बड़ी संख्या में कार्यों और सुधार की कम लागत से आसानी से समझाया गया है।

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

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

अंतभाषण

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

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

हम मानते हैं कि परिणामी लाभ पूरी तरह से निवेश किए गए प्रयास को हतोत्साहित करते हैं, और अपने आप में खुलेपन के अनगिनत फायदे हैं। हम अपने पथ को और अधिक विस्तार से बताने और अनुभवों का आदान-प्रदान करने के लिए तैयार हैं, राइट-कॉल - innersource@sberbank.ru । चुम्बन, Sberbank।