Yandex.Health में विकास नियम

यह कई लोगों को लगता है कि यांडेक्स एक बड़ी अखंड निगम है, जिसमें कठोर विनियमित प्रक्रियाएं हैं, लेकिन ऐसा नहीं है। हम लगातार नई दिशाएँ तलाश रहे हैं, नई परियोजनाएँ शुरू कर रहे हैं और नए बाज़ार आज़मा रहे हैं। Yandex.Health चिकित्सक के साथ ऑनलाइन परामर्श के लिए सेवा क्लासिक आंतरिक स्टार्टअप में से एक है।

मैं ऐसे समय में स्वास्थ्य के विकास का नेतृत्व करने के लिए आया था जब सेवा अभी भी आंतरिक विकी पर संक्षिप्त विवरण के साथ एक पृष्ठ थी। इस पोस्ट में मैं उन विकास दृष्टिकोणों को साझा करना चाहता हूं जो हमने सेवा पर ढाई साल में विकसित किए हैं।

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

नीचे दिए गए सभी बिंदु किसी न किसी तरह से पीड़ित हैं, लगभग हर एक का वास्तविक जीवन से एक मामला है।

कोड गुणवत्ता और वास्तुकला

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

नई तकनीक

नई प्रौद्योगिकियां शांत हैं, चलो उनका उपयोग करते हैं। लेकिन हमारा उत्पाद परीक्षण का आधार नहीं है। यदि आप एक नया एल्गोरिथ्म या प्रौद्योगिकी लागू करना चाहते हैं, तो यह निम्नलिखित परिस्थितियों में किया जा सकता है:

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

संचार

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

समय प्रबंधन

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

नश्वर पाप

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

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

कुल मिलाकर

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