हम कोड द्वारा प्रोटोटाइप। ललाट व्याख्यान

खुश छुट्टियाँ, दोस्तों! नए कार्य वर्ष की शुरुआत की तैयारी में, हम FrontTalks 2018 सम्मेलन से सामग्री की एक श्रृंखला को पूरा कर रहे हैं। यह आंद्रेई सलोमैटिन filipovskii_off द्वारा एक व्याख्यान है - पोलिकॉप्स के एक डेवलपर। एंड्री प्रोटोटाइपिंग के लिए एक संतुलित दृष्टिकोण प्रदान करता है: कारीगरों से बारी करने के लिए जो शोधकर्ताओं में आदेश देते हैं - यह जानने के लिए कि अनिश्चितता के साथ कैसे काम करना है और, संभवतः, एक स्पष्ट योजना के बिना भी कारण बनाए रखने के लिए।

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

इसके बदले हम क्या चाहेंगे? एक उपयोगकर्ता जो इस अंधेरे कमरे का वर्णन करेगा, जो इसे खुद से बेहतर जानता है।

- सभी को नमस्कार! मैं प्रोटोटाइप के बारे में बात करना चाहूंगा: प्रोटोटाइप क्यों बनाते हैं, हमें इससे क्या मिलता है और उदाहरणों का उपयोग करके उन्हें कैसे बनाना है।





मैं एक छोटी कहानी के साथ शुरू करता हूँ। 2012 में, मैं इस स्टार्टअप में शामिल हो गया, एक अद्भुत हिरण। हमारे पास एक विज्ञापन मंच जैसा कुछ था, मैं एक जावा डेवलपर के रूप में आया। यह स्पष्ट है कि यातायात के बड़े खंड, दिलचस्प कार्य, टीम सिर्फ पागल है - सब कुछ अद्भुत है। हम लगभग आठ महीने से काम कर रहे हैं, कीबोर्ड पर सिर है, हम बहुत ही शांत विशेषताएं बनाते हैं, हम जल्दी से सब कुछ बदल देते हैं। लेकिन 2013 में, हिरन खुरों से ऊपर चला गया।

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



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

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



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

लेकिन आउटसोर्सिंग कंपनियों में कस्टम विकास बंद क्यों नहीं होता? या बड़े उद्यम बंद क्यों नहीं हो रहे हैं? वे धीमे-धीमे लगते हैं। एक नियम के रूप में, वहाँ की टीमें कम से कम प्रेरित होती हैं। अंतर क्या है? काम के तंत्र समान हैं: कस्टम विकास में हम टीके लिखते हैं या ग्राहकों से टीके पूछते हैं, वे इसे हमारे लिए पेंट करते हैं, हमें देते हैं, हम मॉक-अप, कोड बनाते हैं, और हम इसे लिखते हैं - एक ही प्रक्रिया। एक स्टार्टअप में ऐसा क्या है कि बड़ी कंपनियों में एज प्रैक्टिस हो सकती है। सभी समान। तो स्टार्टअप्स बाहर क्यों जलाते हैं?

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



कौन 100% सुनिश्चित है कि हम ब्राउज़र और ब्राउज़र एपीआई का उपयोग करके ऐसा कर सकते हैं? एक भी व्यक्ति नहीं। कौन 80% सुनिश्चित है कि हम शायद ऐसा कर सकते हैं? 3-4 हाथ। ५० से ५० तक कौन सुनिश्चित है? बहुमत। किसे यकीन है कि हम ऐसा नहीं कर सकते हैं? शालीनता से।

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



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



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

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

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

और कार्यान्वयन के मुद्दे हैं। मेट्रोनोम के साथ एक उदाहरण। हम 100% नहीं जानते कि यह सैद्धांतिक रूप से संभव है या नहीं।

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

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

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

डिजाइनर भी इससे पीड़ित हैं। वे भविष्य के बारे में सोचना पसंद करते हैं, सही लेआउट बनाते हैं, आदि हम विशेषज्ञ हैं, हालांकि वास्तव में हमें किसी और के बनने की आवश्यकता हो सकती है।

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

यह पहला तरीका है। इस अनिश्चितता पर एक बैज लटका देना आवश्यक है, यह कहना कि यह कितना बड़ा या छोटा है, इसे हल करने के लिए कितना काम करना आवश्यक है, आदि।

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



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

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

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



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

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



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

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

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

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

हम बहुत जल्दी प्रतिक्रिया प्राप्त करने की कोशिश करते हैं। और न केवल कोई प्रतिक्रिया, बल्कि गुणात्मक, मात्रात्मक नहीं।



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

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



एक कंपनी का उदाहरण जो मात्रात्मक प्रतिक्रिया पर बहुत अधिक निर्भर करता है, वह है Booking.com। मेरी राय में, उनकी साइट पर काम करने के लिए कुछ है।

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

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



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

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

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



मेट्रोनोम का एक और उदाहरण। Polychops के लिए पहला विचार पोलरिम्स के साथ काम करने के लिए एक मेट्रोनोम है। हमने लगभग 20 मिनट में पहला प्रोटोटाइप बनाया, फ्लैश पर लिखा। इस तरह उसने देखा। यहां तक ​​कि एक आवाज भी थी। हम बस गए और इसे साथी संगीतकारों को दिखाया, पूछा - आपको यह कैसे पसंद है? यह एकमात्र महत्वपूर्ण चीज है।



फिर हमने ब्राउज़र में एक वास्तविक मेट्रोनोम बनाया, यह काम किया, एनीमेशन, ब्ला ब्ला, सब कुछ सुंदर है।


लेकिन इसमें लगभग डेढ़ महीने का समय लगा और पिछले प्रोटोटाइप में 20 मिनट का समय लगा।

इंटरफेस पर ध्यान दें।



समय बचाने के लिए, एक डिज़ाइन सिस्टम का उपयोग करें। Polychops से एक त्वरित उदाहरण।



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



चोरी। प्रतिस्पर्धियों से चोरी न करें। प्रतियोगियों से चोरी करना व्यर्थ है। यदि प्रतियोगियों के लिए कुछ काम करता है, तो आपको इसकी जांच करने की आवश्यकता नहीं है, आपको बस इसे कॉपी करने की आवश्यकता है। उन उत्पादों से चोरी करें जो आपके समानांतर हैं, जो वास्तव में आपके उत्पाद नहीं हैं, लेकिन कुछ समान हैं।



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

. , . .



: , . , , .



, , . , , . , , , , , . .



— . , , . , .



, , — . . , React . React, React. , , , Redux Apollo, . . .



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



, , . . , . — , , .

, . , . . , . . . — , . , .

? « ?» — , . ?



. , . . 10% , , 10%, , — .

. , 90% , . , , 10%. — , . .

, . Productive Mobile , . , , - , .

. React, — React Native. , , — React, React Native. - : «, React Native, , ». .

? . , , 10 React Native , React Native-. , - , , . , , , «write once — use anywhere». Android iOS . . , , , . — , - , - . — .

, , … ?

Polychops - , . , , , , , . - , , . . .

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

यदि आप सफल होते हैं और आप एक महान उत्पाद बनाते हैं, तो मुझे उम्मीद है कि कुछ बिंदु पर मैं आपके बहुत खुश उपयोगकर्ताओं में से एक होगा। आपका धन्यवाद