चंचलता के साथ खेलते हुए अपने ग्राहक के 10 मिलियन बजट की निकासी कैसे न करें

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

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

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

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

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

जब हमने पहली रिलीज़ जारी की, तो हमने महसूस किया कि डेमो से पहले बहुत आखिरी दिन लगातार कुछ टूट रहा था। विकास के वर्ष के दौरान, प्रत्येक रिलीज शाखा बैसाखी के एक नारकीय सेट में बदल जाती है (इसे बंद करें, इसे हटा दें) जो तब जादुई रूप से विकसित शाखा में समाप्त हो जाती है। और आवागमन की एक श्रृंखला है (इसे चालू करें, इसे चालू करें)। एक साल के बाद, हम इस निष्कर्ष पर पहुंचे कि हमें एक स्पष्ट शाखा नीति की आवश्यकता है। लेकिन सबसे महत्वपूर्ण बात, एक जिम्मेदार व्यक्ति जो मौजूदा अराजकता को समाप्त करेगा। इसका मतलब था: या तो ग्राहक की अराजक इच्छाओं को मध्यम करना, या अराजक कीड़ों को नरम करना, या प्रत्येक स्टैंड पर किसी न किसी तरह की ग्राफिक विशेषताओं या बटन को अक्षम करने का अपना कॉन्फ़िगरेशन है। एक बयान में प्रत्येक बटन लपेटकर पागल है। हम इस निष्कर्ष पर पहुंचे हैं कि हमें प्लग-इन फीचर-मॉड्यूलर फ्रंट एंड आर्किटेक्चर (अक्षम - सक्षम) की आवश्यकता है। मैंने लंबे समय तक सोचा कि इस तरह की वास्तुकला को कैसे प्राप्त किया जाए। लेकिन एक बात मुझे पक्की समझ में आ गई। हमें एक पूर्ण संदर्भ की आवश्यकता थी। तो js-beans पुस्तकालय का जन्म हुआ (https://www.npmjs.com/package/js-beans)। प्रत्येक स्टैंड का अपना जसन संदर्भ था। प्लग-इन को प्रॉक्सी पैटर्न के माध्यम से एक श्रृंखला (चेन) में एकत्र किया गया था। इसलिए, उदाहरण के लिए, हमारे पास एक अलग बिन के रूप में एक डेटा स्रोत था, और इस बिन की जगह वैकल्पिक प्रॉक्सी डिब्बे के रूप में विभिन्न परिवर्तन किए गए थे, लेकिन इसे स्वयं में इंजेक्ट किया गया। उदाहरण के लिए, यदि आपको एफपीएस प्रदर्शन के परीक्षण के लिए डेटा मॉडल को स्केल करने की आवश्यकता है, तो मैं बस जसन फ़ाइल में स्केलिंग प्लगइन को सक्षम करने के लिए लाइन जोड़ता हूं। उत्पादन पर कुछ टूट गया, लेकिन यह स्थानीय रूप से नहीं चलता है, मैं स्टैंड को फिर से बनाए बिना एक लाइन के साथ लकड़हारा चालू करता हूं (स्टैंड में लगभग 20 मिनट लगते हैं, और एक दर्जन स्टैंड हमेशा सभी के लिए पर्याप्त नहीं होते हैं)। या अगर आपको इस तथ्य के कारण जल्दी से कुछ मॉड्यूल को बंद करने की आवश्यकता है, तो इसे तोड़ा जा सकता है (संदर्भ में वैकल्पिक बीन को अक्षम करें)।

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

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

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

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

हमने नई तकनीकों के साथ खेलने का फैसला किया, जिसमें हमें बहुत कम विशेषज्ञता हासिल थी। वे हमारे लिए अनुशंसित थे। बेशक हम अनुभव हासिल करना चाहते थे। अब मुझे लगता है कि केवल उन्हीं तकनीकों का उपयोग करना बेहतर होगा जिनमें मुझे अनुभव है।

हमने 8 घंटे के कार्य दिवस के आधार पर अनुमान दिया। वास्तविकता में, अनुमान 4 घंटे के कार्य दिवस के आधार पर दिया जाना चाहिए। क्यों किसी को चाय, दिलचस्प कहानियां बताना, नाविक पर शौचालय ढूंढना, फोन पर बात करना, पत्राचार, नई तकनीकों का अध्ययन करना और सबसे महत्वपूर्ण बात यह है कि टीम के भीतर के विवादों में शामिल नहीं है। उत्तरार्द्ध शायद सबसे अपरिहार्य है, और सबसे महंगा है। हालांकि, ईमानदार होने के लिए, ओपन स्पेस के लिए आपको अभी भी कुछ घंटे फेंकने की आवश्यकता है। लगातार बात करने से एकाग्रता में कमी आती है। धन्य है वह ग्राहक जो यह सब समझता है!

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

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

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

मेरा व्यक्तिगत व्यक्तिपरक निष्कर्ष:

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

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

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