ओह, माई कोड: आईटी लीडर कैसे बनें

तकनीकी निदेशक कैसे बनें, आपातकालीन स्थितियों में क्या करें, उच्च वेतन और कैरियर विकास कैसे प्राप्त करें, साथ ही साथ Am.ru विकास कैसे काम करता है - हम इस बारे में बात करते हैं प्रोग्रामर "ओह, माय कोड" के लिए टॉक शो के चौदहवें अंक में।


कार्यक्रम के मेजबान मीडिया परियोजनाओं के तकनीकी निदेशक पावेल शचरबिन हैं, अतिथि - अलेक्जेंडर मेल्निचुक, Am.ru तकनीकी निदेशक।

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

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

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

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

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

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

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

एक दिलचस्प आग्रह को निकाल दिया गया।
सपने, सपने ...

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

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

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

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

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

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

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

यदि किसी कर्मचारी को किसी अन्य टीम के साथ समन्वय की आवश्यकता होती है, तो वह स्टैंड-अप पर आता है और कहता है कि उनके पास ऐसी और ऐसी समस्या है, जो मदद मांगती है। हम ऐसे कर्मचारियों को "स्काउट" कहते हैं।

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

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

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

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

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

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

आपने एंडॉन पद्धति का उल्लेख किया। यह क्या है
हर किसी में कोई न कोई खासियत होती है। मैं तकनीकी निदेशक हूं, फ्रंट-एंड डेवलपर्स, मोबाइल डेवलपर्स, सिस्टम एडमिनिस्ट्रेटर, DevOps, आदि हैं। ऐसा लगता है कि अगर मैं सी ++ प्रोग्रामर हूं, तो मैं सी ++ में लिखूंगा। लेकिन अगर फ्रंट ने जेएस को तोड़ दिया? “ जेएस क्या है? मानविकी से कुछ समझ से बाहर है, मैं ऐसा नहीं करूंगा। - लेकिन मैं आम तौर पर एक सिस्टम प्रशासक या DevOps है। मुझे इससे कोई लेना-देना नहीं है, अपना खुद का JS खींचो । ”

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

आपने कहा कि किसी प्रकार की आंतरिक प्रणाली उपयोगिता के कारण समस्या उत्पन्न हुई। आपने कंटेनरीकरण का उपयोग नहीं किया, जो अब बहुत लोकप्रिय है?
नहीं।

क्या अब आपके पास प्रोडक्शन का काम है?
हां।

यही है, आपने सक्रिय रूप से डॉकर पर स्विच किया और इसका उपयोग किया?
यह हमारे काम की मुख्य दिशाओं में से एक है।

आपके इंप्रेशन क्या हैं?
सब ठीक है। मैं यह भी नहीं जानता कि हम इसके बिना कैसे रहेंगे। पहले, हमारे पास PHP थी - चलो स्क्रिप्ट से छुटकारा पाएं, और यह शुरू हुआ। और अब आप किसी भी तरह से कंटेनरों के बिना नहीं रह सकते।

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

एक बार एक डेवलपर ने एक निजी बातचीत में कहा: “ मैं अधिक पैसा पाने, शक्ति पाने और इसी तरह से एक तकनीकी विशेषज्ञ या तकनीकी निदेशक बनने का सपना देखता था। अब मैं एक सपाट ढांचे में काम करता हूं, हमारे पास तकनीक नहीं है। लेकिन एक तकनीकी निदेशक है जो प्रबंधकीय कार्य करता है, और डेवलपर्स तकनीकी निर्णय लेते हैं। मुझे कहां निशाना लगाना चाहिए? मैं कैसे रहता हूँ? जीवन सिद्धांत टूट गए हैं। यह स्पष्ट नहीं है कि आगे कहां जाना है । ”

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

टीम लीडर कैसे बनें?
आप बस नहीं हो सकते हैं। टीमवर्क का मतलब वही करना है जो आपको पसंद है। मेरे व्यवहार में, ऐसे मामले सामने आए हैं, जब किसी व्यक्ति को उसके अनुरोध पर डरपोक ठहराया गया था। खैर, हम एक ज्ञापन लिखते हैं, हम श्रम में प्रवेश को बदलते हैं, वेतन बढ़ाते हैं। वहीं, व्यक्ति का कहना है कि वह टीम लीडर है, लेकिन टीम उसे नहीं पहचानती है।

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

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

हमारे छोटे ब्लिट्ज सर्वेक्षण। आप कौन सा ओएस चुनेंगे?
मैक ओएस

सबसे अच्छा आईडीई क्या है?
जेटब्रेन्स।

अंतिम एप्लिकेशन, वेबसाइट, स्टार्टअप जिसने आपको प्रभावित किया है?
Tinkoff बैंक से मोबाइल बैंकिंग।

कौन सा बेहतर है: एक स्टार्टअप या एक बड़ी कंपनी?
यदि आप बस आराम से रहना चाहते हैं और भुगतान करना चाहते हैं, तो एक बड़ी कंपनी में जाएं। यदि आप लगातार क्रोध करते हैं, आप आंदोलन, एड्रेनालाईन, रोमांच चाहते हैं, तो एक स्टार्टअप आपका सब कुछ है। यदि आप बहुत सारा पैसा चाहते हैं तो किसी स्टार्टअप में जाने की आवश्यकता नहीं है। यह ऐसा नहीं है।

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

रोबोट कब आपकी जगह लेंगे?
हम कह सकते हैं कि उन्हें पहले ही बदल दिया गया है। मैंने एक रोबोट वैक्यूम क्लीनर खरीदा।

आप कार्यों को कैसे महत्व देते हैं: घंटों में या स्टोरी पॉइंट्स में?
दोनों स्टोरी पॉइंट्स में, और घंटों में। जो चाहता है।

आखिरी बात क्या आप बर्दाश्त नहीं कर सकते थे?
सुबारू आरोही।

आपके पास कितने बिटकॉइन हैं?
शून्य।

इस विषय में कोई दिलचस्पी नहीं है?
यह प्रचार है।

आपके मित्र अक्सर am.ru के बारे में क्या पूछते हैं?
जब हम दुनिया को संभालते हैं।

और कब?
जल्द ही आ रहा है