"हमेशा विकास करना होगा": एक स्टार्टअप में विकास के बारे में एवगेनी कुवशिनोव (मानवेच) के साथ एक साक्षात्कार

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

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

- सबसे पहले, हमें संक्षेप में बताएं कि आप मानस्टेच में क्या करते हैं और कंपनी खुद क्या करती है।

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

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

आप देख सकते हैं कि सामान्य उदाहरण में मैसेंजर में बॉट कैसे काम करते हैं, एक विशिष्ट उदाहरण का उपयोग करते हुए: होल्जेस के लिए समय में, हमने एक विशेष बॉट बनाया।



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

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

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

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

- विकास के विषय की ओर मुड़ना: कंपनी कब तक दिखाई दी है, और यह उस समय से हमारे समय तक कैसे बढ़ी है?

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

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

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

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

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

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

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

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

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

- कंपनी के तेजी से विकास के साथ, आप शायद इस तथ्य पर आते हैं कि कई लोगों के लिए काम करने वाली प्रक्रियाएं दर्जनों लोगों के पास जाने पर काम करना बंद कर देती हैं। संगठनात्मक दृष्टिकोण से आपका विकास कैसे बदल गया है?

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

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

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

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

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

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

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

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

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

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

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

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

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

- संक्षिप्त उत्तर है हां, एक सुपरनोवा, शांत और दिलचस्प है, हम इसका हर तरह से स्वागत करते हैं। लेकिन, निश्चित रूप से, नई प्रौद्योगिकियों की शुरूआत के लिए कुछ मापदंड हैं।

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

कभी-कभी ऐसी चीजें होती हैं जो अभी तक रिलीज तक नहीं पहुंची हैं। हमने रिएक्ट में पैनल बनाने के लिए लाइब्रेरी का उपयोग करना शुरू किया, जब यह अभी भी पर्याप्त कच्चा था, और, जहां तक ​​मुझे याद है, यहां तक ​​कि थोड़ा सा दान किया गया था। हमने कुछ प्रकार के बीटा के साथ बैबेल 7 का उपयोग करना शुरू कर दिया क्योंकि इससे हमें पिछले एक की तुलना में थोड़ी तेजी से परियोजना का निर्माण करने की अनुमति मिली।

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

- "प्रगति की नोक" के बारे में अधिक: मैं यह मान लेना चाहता हूं कि एक स्टार्टअप आपको शांति से सांस लेने की अनुमति देता है "आपको विरासत कोड से निपटना नहीं है।" क्या ऐसा है?

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

- स्टार्टअप विकास "साइकिल निर्माण" में कितना योगदान देता है? जबकि विशाल कंपनियां सब कुछ अंदर कर रही हैं, क्या आप इसके लिए तैयार नहीं हैं? या क्या स्टार्टअप एक ऐसी जगह है जहाँ हर कोई अपनी बात करता है?

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

— , ? , - «»?

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

. ManyChat React, Baobab. , React . view React, store Baobab. , , .

2017 . React, Redux middleware – Thunk Fetch API. , . , , , , .

— , , , . -, «» ?

— c , Flow, — Flow Builder. , :



, , 2D-. Flow Builder PixiJS — WebGL/Canvas.

. , . PixiJS requestAnimationFrame . , , , , . ( 12- MacBook, , ). , , , .

, , -, - , - , , , . 2D-.

— «»? , , ?

— , , , , , … , HTML, Canvas WebGL , . Pixi, .

: , Canvas, - WebGL. Pixi , , . , - . , issue, GitHub , , , .

, , , Canvas , HTML CSS. , Flexbox layout', . . Canvas, : Canvas, textarea, CSS scale , : Canvas - , HTML.

, . , Pixi - , , Flow Chart . - - , : , . , , , , . .

— . , , , . - , - ?

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

: - -, - - , , , . , , . , , - -. , , , , . -, , , , .