अनुसंधान और विकास के बीच अंतराल को पाटना

एक Onfido बायोमेट्रिक्स टीम स्टोरी

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

गैर-एकीकृत टीमों के लक्षण

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

इसने व्यवसाय में विभिन्न दर्द बिंदुओं को महसूस किया:

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

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

हमने टीमों को कैसे एकीकृत किया

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

टीम ने एक उत्पाद प्रबंधक, एक टीम लीड, तीन रूबी / एलिक्सिर डेवलपर्स और एक मशीन लर्निंग रिसर्चर के रूप में शुरुआत की। जब उत्पाद और अनुसंधान लंदन में थे, इंजीनियर लिस्बन में थे।

टीम का विकास। चेहरे गायब करना = पदोन्नति, अन्य टीमों के लिए कदम, और इंटर्नशिप का अंत। सौभाग्य से किसी को भी नहीं छोड़ना पड़ा

कार्यों के बीच संबंध निर्माण

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

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

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

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

हमारे लक्ष्यों को संरेखित करना

पूरी टीम ने त्रैमासिक उद्देश्य और कुंजी परिणाम (OKRs) को एक साथ लिखा था, जो कि जितना संभव हो उतना संभव था परिणाम आउटपुट केंद्रित होने के बजाय केंद्रित थे। यह कहना है: "इस सुविधा को जहाज" के बजाय "मीट्रिक x% स्थानांतरित करें"।

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

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

तनाव का समाधान

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

कुछ चीजों ने टीमों को एक साथ लाने में मदद की और आखिरकार एक पूरी तरह से क्रॉस फंक्शनल टीम के निर्माण का नेतृत्व किया:

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

मशीन सीखने वाले अनुसंधानकर्ताओं के साथ टीमों के लिए अनुकूलित स्क्रम समारोह

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

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

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

शोधकर्ता अक्सर यह नहीं समझ पाएंगे कि इंजीनियर क्या बात कर रहे थे। वे कम शामिल थे और व्यापक मंच वास्तुकला में रुचि रखते थे जिसमें उनके मॉडल को अंततः एकीकृत किया जाएगा।

यह इतना खराब हो गया कि शोधकर्ताओं ने स्टैंडिंग स्किप करना शुरू कर दिया क्योंकि उन्हें यह मूल्यवान नहीं लगा, जिससे टीम में खराबी पैदा हो गई।

जिन परिवर्तनों ने मदद की:

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

टिप्पणियाँ बंद करना

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

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

यह अब तक कितनी मजेदार यात्रा रही है!

जूम पर खड़े हो जाओ। किसी ने कुछ मजेदार कहा होगा।

आप लगभग एक साल पहले लिखे गए डैनियल सेरानो (3 मिनट पढ़ा) द्वारा इस कहानी का एक सॉफ्टवेयर डेवलपर दृश्य पढ़ सकते हैं, इसलिए उपरोक्त सभी परिवर्तन तब तक लागू नहीं किए गए थे।

पुनश्च: यह पता लगाना कि मैं इन सभी तस्वीरों में चार अलग-अलग बाल कटाने से कैसे गुज़रा।