दर्जनों परिकल्पनाओं का त्वरित परीक्षण: कैसे हम दिनचर्या से बाहर हो जाते हैं और दूसरे शहर में चर्चा करते हैं

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

फायदे के एक समूह के अलावा, इस तरह की प्रणाली के दो स्पष्ट नुकसान हैं:

1. यह कोरी उबाऊ है, और बोरियत वह नहीं है जो हमें कोड लिखने के लिए प्रेरित करती है।
2. कई परिकल्पनाएं जमा हो रही हैं, जो सामान्य प्रक्रिया के अनुसार, बैकलॉग के अंत में कहीं गिरती हैं, लेकिन जिनमें से प्रत्येक एक त्वरित परिणाम दे सकता है। या शायद नहीं। उनमें से कुछ दिलचस्प हैं।

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

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

इसलिए, हमने पहले ही तीन बार एक विदेशी शहर की यात्रा की है और वहां काम किया है।

इसकी आवश्यकता क्यों है?

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

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

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

यह अच्छी तरह से काम करता है, लेकिन सीमाएं जो आपने ऊपर देखीं।

एक पूर्ण विकास में, यह लिया जाता है कि, बीटा के परिणामों के अनुसार, परियोजना प्रबंधक संतुष्ट है।

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

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

"विशेष बलों" की आवश्यकता है क्योंकि यदि समस्या को हल करने के लिए डेवलपर का 100% समय आवंटित नहीं किया जाता है, तो यह खराब हो जाता है। अनुभव से देखते हुए। लेकिन हम ऐसा नहीं कर सके।

हमने TRIZ को लिया और सुझाव दिया कि हमें समय के भाग पर ध्यान केंद्रित करने की आवश्यकता है, मुख्य कार्य "लंबे समय में"। हमें ऐसा करने से रोकता है, जैसा कि हमने कार्यालय में किया था? संदर्भ, निरंतर विक्षेप और नियम, टीम के सदस्यों का निरंतर रोजगार और लंबी प्रतिक्रिया।

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

इसलिए, हमने 14 लोगों की एक टीम के साथ एक प्रयोग करने और इस्तांबुल जाने का फैसला किया।

इस्तांबुल प्रयोग

इस्तांबुल क्यों? हमें एक शहर की आवश्यकता थी जो खाद्य आवश्यकताओं को पूरा करे:

1. लगातार देरी के बिना जल्दी से उड़ान प्राप्त करें (ग्रह का दूसरा पक्ष फिट नहीं होता है, अप्रत्याशित मौसम वाले द्वीप फिट नहीं होते हैं)।
2. पहुंच अपेक्षाकृत सस्ती है (आइसलैंड आमतौर पर उपयुक्त नहीं है)।
3. वर्ष के इस समय शहर मॉस्को से अधिक आकर्षक है (हर कोई सिर्फ यात्रा के लिए कार्यालय से बाहर निकलना पसंद नहीं करता है, ओम्स्क उपयुक्त नहीं है, लेकिन इस शहर के निवासी मुझे माफ कर देंगे)।
4. कई दिलचस्प चीजें हैं जिनके लिए आपको दूर की यात्रा करने की आवश्यकता नहीं है (नॉर्वे उपयुक्त नहीं है)।
5. टीम सर्वसम्मति से इस शहर में जाना चाहती है।

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

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

खैर, अंत में, हम अभी भी यात्रा के बारे में भावुक लोग हैं।

मौके पर उन्होंने केंद्र के पास एक बड़ा घर किराए पर लिया।

किसने किया? डेवलपर्स में से एक ने अपना निजी समय इस सब को व्यवस्थित करने में बिताया। मुझे यकीन नहीं है कि यह इसलिए था क्योंकि वह व्यावसायिक यात्रा की प्रक्रिया का अध्ययन करना चाहता था (हमने इसे सिर्फ बढ़ावा दिया), या बस इसलिए कि वह सभी की मदद करना चाहता था।

एक हफ्ते के लिए उन्होंने रसोई को चेतावनी दी कि हमें सड़क पर स्नैक्स की जरूरत है, लेकिन आने वाले दिनों में भोजन पर भार घट जाएगा।

हमने शुक्रवार सुबह काम किया, हमेशा की तरह, 12:30 बजे हम हवाई अड्डे पर गए, लगभग 15 बजे - प्रस्थान, 18 बजे हम वहाँ थे।



हम घर पहुंचे, वहां पहले से ही वाई-फाई तैनात था, मैंने अपने साथ सामग्री छपवाई थी। सभी कॉर्पोरेट लैपटॉप के साथ। हमने खाया, बैठकर मुख्य बातों पर चर्चा की। वास्तव में, यह एक बहस थी कि उत्पाद में क्या और कैसे करना है। यही है, हमने तय किया कि बैकलॉग में क्या मिलना चाहिए। मैं "त्वरित" परिकल्पनाओं, और भाग्य, और दीर्घकालिक कार्यों की प्राथमिकताओं पर चर्चा करना चाहता था।

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

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

रन-इन परिकल्पना का एक उदाहरण

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

व्यावहारिक रूप से, ऐसे प्रगतिशील स्टेशन हैं जो बस फोन से टिकट दिखाते हैं। उनके पास अभी भी उनके विवरण में यह डेटा है, और आपको बस वहां और उस व्यक्ति के दस्तावेज़ को देखने की आवश्यकता है। लेकिन रूढ़िवादी स्टेशन हैं और जो लोग "बाबा यगा के खिलाफ" हैं। और सभी स्टेशनों के अपने ऐसे रूप हैं।

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

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

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

फिर हमने ऐसे बस स्टेशनों की "श्वेत सूची" बनाने का फैसला किया जहां इलेक्ट्रॉनिक पंजीकरण कार्य करता है। ट्रिपल चेक: यात्री की याद, हमारे गुप्त ग्राहक की कॉल, स्टेशन प्रबंधन से सीधा सवाल।

यदि कानून इलेक्ट्रॉनिक टिकट की अनुमति देने के मामले में वास्तविकता से पीछे है, लेकिन स्टेशन के अनुसार टिकट वसूली के माध्यम से एक समाधान है, तो क्यों नहीं स्वचालित और अपने स्वयं के त्वरित और सुविधाजनक बैसाखी बनाते हैं?

सामान्य तौर पर, हमें साइट पर ऐसे स्टेशन और चिह्नित टैग मिले।



समय-समय पर सत्यापन दोहराया जाता है।

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

फिर हमने उन स्टेशनों में सिस्टम में छोटे बोनस दिए जिनके पास ऐसा निशान है ताकि ऐसा करने के लिए आर्थिक प्रोत्साहन मिल सके।

नतीजतन, यह पता चला कि हम जल्दी से संयुक्त (ठीक है, वास्तव में हम नहीं, लेकिन वे खुद संयुक्त थे, विशेष रूप से, हमारे उपकरण के साथ) काफी कुछ स्टेशन और वाहक जो पहले से ही इलेक्ट्रॉनिक पंजीकरण स्वयं करते हैं।

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

परिणाम क्या है?

पहले अनुभव के नुकसान:

• माइनस टिकट और आवास।

लाभ:

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

Nezhdanchiki:

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

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

पहले पुनरावृत्ति में सात परिकल्पनाओं का चयन और परीक्षण किया गया, जिनमें से तीन में परिणाम सामने आए। उदाहरण के लिए, बसों की दिशा में।

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

उस समय, बैकलॉग में विशिष्ट कार्य थे, उदाहरण के लिए, ऐसी दिनचर्या:

• बस स्टेशनों के साथ दो एकीकरण चलाएं।
• तीन वर्तमान एकीकरण का अद्यतन करें।
• लिथुआनियाई बस वाहक को एकीकृत करें।
• अपने खाते में 16 वाहक के लिए कनेक्टर बनाएं।

सामान्य तौर पर, यह काम करता है, लेकिन हम कार्यालय से "अलगाव में" काम करने और आपके पास होने पर कहीं यात्रा करने के आपके अनुभव को सुनना पसंद करेंगे।