संरचित टिकट टेम्प्लेटहरूको साथ टेक डिजाइन बैठकहरू अनुकूलन गर्दै

जब मैले २०२० मा Wayfair मा मेरो जागिर पाएँ, म एक दुबला, स्क्र्यापी टोलीमा सामेल हुन उत्साहित थिएँ जसले ठूलो मात्रामा व्यापार चलाउने b2b उपकरणलाई कायम राखेको थियो। म एउटा भूमिकाबाट आएको हुँ जहाँ मैले प्रायः साइलोमा काम गरेको थिएँ, त्यसैले म फेरि विकास टोलीको हिस्सा हुन पाउँदा विशेष उत्साहित थिएँ। मैले धेरै चाँडै फेला पारे, तथापि, हामीले प्रयोग गरिरहेका उपकरणहरूमा धेरै टोलीसँग यति धेरै विशेषज्ञता थियो कि उनीहरूसँग यो पूर्वनिर्धारित धारणा थियो कि अन्य विकासकर्ताहरूसँग उही पृष्ठभूमि, अनुभव, र ज्ञान थियो। मुख्य मुद्दा यो थियो कि हामीले काम गरिरहेका उपकरणहरू आन्तरिक र स्वामित्वका थिए, त्यसैले धेरै नयाँ विकासकर्ताहरूले उनीहरूलाई साथै अनुभवी devs लाई थाहा थिएन। अब, यो सामान्यतया एक मुद्दा होइन। यद्यपि, यो धेरै समस्याग्रस्त भयो जब जिरा टिकटहरू सिर्जना गरियो, प्राथमिकता, अनुमानित, र केहि विवरणहरू प्रदान गरियो। पक्कै पनि, शीर्षकले सामान्य मुद्दाको व्याख्या गर्यो, र यो लेख्ने अनुभवी विकासकर्तालाई सम्भवतः परिवर्तनहरू गर्न कहाँबाट सुरु गर्ने भनेर ठ्याक्कै थाहा थियो, तर हामी मध्ये जो प्लेटफर्महरूमा नयाँ थियौं उनीहरूले सुरु गर्नको लागि निर्माण गर्न थोरै थिए। यसले दक्षतामा ठूला प्वालहरू निम्त्यायो, जहाँ हामीले थप जानकारीको लागि थप कार्यकालका विकासकर्ताहरूलाई निरन्तर हाउन्ड गरिरहेका थियौं। यस सेटअपको अर्को उप-उत्पादन यो थियो कि हाम्रो प्राविधिक डिजाइन बैठकहरू ड्र्याग गर्ने झुकाव थियो किनकि हामीमध्ये धेरैले अनुमानका लागि प्रस्तुत गरिएका टिकटहरू बारे प्रश्नहरू थिए। वार्तालापमा विवरणहरू निरन्तर बाहिर ल्याइँदै थिए तर कुनै पनि रेकर्ड गरिएको थिएन। यी बैठकहरू तानिन्छन्, र त्यसपछि टिकट तोकिएपछि उही प्रश्नहरू फिर्ता आउनेछन् (जबसम्म नियुक्तिकर्ताले प्रश्नहरू सोधिएको हप्ता अघिको कुराकानीलाई जादुई रूपमा सम्झन सक्दैन)। यो कार्यप्रवाह अविश्वसनीय रूपमा निराशाजनक र अक्षम थियो। तर, आशा छ! हामीले यो मुद्दा पहिचान गरेपछि र छलफल गरेपछि केही समयपछि, बैठकहरू कम समय लाग्ने र बढी प्रभावकारी हुन थाले। टिकटहरू विवरणहरू र कार्य गर्न सजिलो, परीक्षण, र पूरा भएका थिए। हामीले यो कसरी गर्यौं भन्ने यहाँ छ। समस्या: तयारी नगरिएका टिकटहरू र लामो बैठकहरू हाम्रा प्राविधिक डिजाइन मिटिङहरू प्रायः पर्याप्त विवरण नभएका टिकटहरूद्वारा पटरीबाट हट्ने छन्। विकासकर्ताहरू, डिजाइनरहरू, र अन्य सरोकारवालाहरूले अतिरिक्त जानकारी खोज्न वा कार्यको अस्पष्ट पक्षहरू स्पष्ट गर्न धेरै समय खर्च गर्नेछन्। यसले हाम्रो बैठकहरू लम्ब्याउने मात्र होइन तर विकासमा ढिलाइ पनि गर्यो किनकि तोकिएको टिकटहरू बारम्बार बाउन्स हुनेछन्, काम अघि बढ्नु अघि थप स्पष्टीकरण चाहिन्छ। यसको एउटा उत्कृष्ट उदाहरण टिकट हुन सक्छ जुन एक टेन्युर्ड डेभद्वारा रिपोर्ट गरिएको थियो जसले "हामीले फ्लोरिङ स्कसको लागि मूल्य निर्धारण गर्न आवश्यक छ।" स्पष्ट रूपमा, पृष्ठभूमि जानकारीको पर्याप्त मात्रा बिना तपाईंले यो टिकट प्राप्त गर्दा तपाईंले गर्न सक्नुहुने कुनै पनि कुरा छैन। फ्लोर स्कसमा मूल्य निर्धारणको समस्या के हो? के हुने अपेक्षा गरिएको छ? के कार्टमा sku को मात्रा महत्त्वपूर्ण छ? त्यहाँ धेरै खुला प्रश्नहरू छन् र बैठकमा हपिङ बिना काम सुरु गर्ने कुनै तरिका छैन। एक राम्रो टिकट विवरण हुन सक्छ। "फ्लोर स्कसहरू थोक मूल्यमा छन् र हाम्रो प्रणालीले मूल्य निर्धारण/मात्राको गणितलाई राम्ररी ह्यान्डल गरिरहेको छैन जब कार्टमा मात्राले बल्क मूल्य निर्धारण थ्रेसहोल्डहरू नाघेको छ।" अब, यहाँ अझै पनि पर्याप्त विवरण छैन, तर कम्तिमा यसले समस्यालाई राम्ररी बताउँछ। म उदाहरण थकाउन जाँदैछु तर विकासकर्ता (हरू) ले यी सबै विवरणहरू बारम्बार प्रश्नहरू, कुराकानीहरू, र प्रस्तुतीकरणहरूको साथ बाहिर निकाल्नुपर्छ जबसम्म हामीसँग अनुमान गर्न वा टिकटमा काम गर्ने पर्याप्त विवरणहरू नभएसम्म, हालको आधारमा। कार्य। यसले धेरै गुमाएको समयको नेतृत्व गर्यो जुन हामीले, विकासकर्ताहरूको रूपमा, फिर्ता पाउन सकेनौं। समाधान: टिकट टेम्प्लेटहरू लागू गर्दै यो समस्या समाधान गर्न, हामीले भइरहेको कामको प्रकार अनुरूप संरचित टिकट टेम्प्लेटहरूको सेट विकास गरेका छौं। यी टेम्प्लेटहरूले प्रत्येक टिकट-चाहे बग रिपोर्ट, डिजाइन परिवर्तन, सुविधा अनुरोध, वा अप्टिमाइजेसन कार्य-मा छलफल वा काम तोक्नु अघि सबै आवश्यक जानकारी समावेश भएको सुनिश्चित गर्यो। नियम सरल थियो: यदि टेम्प्लेट पूर्ण रूपमा पूरा भएको थिएन भने, टिकट बैठक वा विकासको लागि तयार थिएन। बग रिपोर्टहरू विवरण: समस्याको संक्षिप्त तर विस्तृत विवरण अपेक्षित व्यवहार: स्क्रिनसटहरू वा फिग्मा सन्दर्भहरू सहित, चीजहरूले कसरी काम गर्नुपर्छ भन्ने बारे थप विस्तृत व्याख्या। वास्तविक व्यवहार: के भइरहेको छ र यो अपेक्षित व्यवहारबाट कसरी फरक छ भन्ने बारे विस्तृत विवरण पुन: सिर्जना गर्न चरणहरू: कसरी मुद्दा पुन: सिर्जना गर्ने मा विशिष्ट, विस्तृत, चरणहरू। कसैले उपकरणमा नयाँ इन्कग्निटो विन्डो खोल्न र चरणहरूबाट विचलित नगरिकन मुद्दालाई पुन: सिर्जना गर्न सक्ने गरी सम्पर्क गर्न आवश्यक छ। (वैकल्पिक) विकासकर्ता नोटहरू: यो एक वैकल्पिक खण्ड हो जहाँ हामीले सुझाव गरिएका दृष्टिकोणहरू समावेश गर्न सक्छौं यदि हामीसँग पहिले नै यो कहाँ जानुपर्छ वा यसलाई कसरी विकास गर्नुपर्छ भन्ने बारे राम्रो विचार छ। हामी विकासकर्ताहरूलाई कुनै निश्चित तरिकाले चीजहरू गर्न बाध्य पार्न चाहँदैनौं तर यहाँ कुनै पनि निर्देशनले पछि टिकट कार्यान्वयनको गति बढाउन मद्दत गर्न सक्छ। (वैकल्पिक तर रुचाइएको) बाह्य प्रभावहरू: यो कामलाई प्रभाव पार्न सक्ने कुनै पनि बाह्य स्रोतहरूलाई कलआउट गर्छौं। के त्यहाँ टोलीहरू छन् जसले पहिले नै हाम्रो API मा बगको लागि समाधान सिर्जना गरिसकेका छन् जसलाई हामीले यसलाई ठीक गर्दा सूचित गर्न आवश्यक छ? के यो बग जानकारीको लागि अन्य टोली/एपिस/स्रोतहरूमा निर्भर छ जसले सम्भावित रूपमा यसलाई समाधान गर्न कति समय लाग्छ? (वैकल्पिक) प्रभाव: के यसले टोली वा व्यवसायमा ज्ञात, मापनयोग्य प्रभाव पारेको छ? यो सधैं ज्ञात वा मापन गर्न सजिलो छैन, त्यसैले यो एक वैकल्पिक क्षेत्र हो। तर यदि यो अवस्थित छ भने प्राथमिकताका लागि जान्न महत्त्वपूर्ण छ। डिजाइन परिवर्तनहरू विवरण: समस्याको संक्षिप्त तर विस्तृत विवरण अपेक्षित व्यवहार: अपेक्षित, डिजाइन गरिएको व्यवहारको लागि स्क्रिनसट वा फिग्मा लिङ्कहरू। वास्तविक व्यवहार: स्क्रिनसट वा भिडियोहरू वास्तवमा के भइरहेको छ, साथै के भइरहेको छ र यो अपेक्षित व्यवहारबाट कसरी फरक छ भन्ने विवरणहरू (वैकल्पिक) पुन: सिर्जना गर्ने चरणहरू: यदि यो एक विशिष्ट UI तत्व हो जुन विशेष परिस्थितिहरूमा मात्र देखा पर्दछ, हामीले हाम्रो परिवर्तनहरू कसरी परीक्षण गर्ने भनेर जान्नको लागि यो कसरी/कहिले उपस्थित हुनुपर्छ भन्ने कुरा जान्न आवश्यक छ। (वैकल्पिक) विकासकर्ता नोटहरू: यो एक वैकल्पिक खण्ड हो जहाँ हामीले सुझाव गरिएका दृष्टिकोणहरू समावेश गर्न सक्छौं यदि हामीसँग पहिले नै यो कहाँ जानुपर्छ वा यसलाई कसरी विकास गर्नुपर्छ भन्ने बारे राम्रो विचार छ। हामी विकासकर्ताहरूलाई कुनै निश्चित तरिकाले चीजहरू गर्न बाध्य पार्न चाहँदैनौं तर यहाँ कुनै पनि निर्देशनले पछि टिकट कार्यान्वयनको गति बढाउन मद्दत गर्न सक्छ। (वैकल्पिक) प्रभाव: के यसले टोली वा व्यवसायमा ज्ञात, मापनयोग्य प्रभाव पारेको छ? यो सधैं ज्ञात वा मापन गर्न सजिलो छैन, त्यसैले यो एक वैकल्पिक क्षेत्र हो। तर यदि यो अवस्थित छ भने प्राथमिकताका लागि जान्न महत्त्वपूर्ण छ। सुविधा अनुरोधहरू विवरण: सुविधा के हो मा एक पूर्ण विस्तृत तस्वीर। यसले कसरी काम गर्नुपर्छ, अपेक्षित आगतहरू/आउटपुटहरू के हुन्, आदि। हामीले यहाँ यो सुविधा किन अनुरोध गरिँदैछ भनेर हामीसँग भएको कुनै तर्क पनि समावेश गर्नुपर्छ। विकासकर्ता नोटहरू: विकासकर्ताले ज्ञात फ्रेमवर्क/ढाँचाहरूमा मार्गदर्शन प्रदान गर्न यो खण्ड प्रयोग गर्नुपर्छ जुन हाम्रो बाँकी कोडबेसमा सहज रूपमा फिट हुनको लागि प्रयोग गरिनुपर्छ। हामी विकासकर्ताहरूलाई कुनै निश्चित तरिकाले कोड लेख्न बाध्य पार्न चाहँदैनौं तर यहाँ कुनै पनि निर्देशनले टिकट कार्यान्वयनलाई छिटो बनाउनेछ र थप सुव्यवस्थित PR कुराकानीहरूतर्फ लैजानुपर्छ। (वैकल्पिक तर रुचाइएको) मकअपहरू: यदि हामीसँग उदाहरण पेलोडहरू, स्क्रिनसटहरू, वा फिग्मा सन्दर्भहरू छन् जसले विकासलाई मार्गदर्शन गर्नुपर्दछ यी सबैलाई यहाँ समावेश गर्नुपर्छ। (वैकल्पिक तर रुचाइएको) बाह्य प्रभावहरू: यो कामलाई प्रभाव पार्न सक्ने कुनै पनि बाह्य स्रोतहरूलाई कलआउट गर्छौं। के त्यहाँ टोलीहरू छन् जसले पहिले नै हाम्रो API मा छुटेको सुविधाको लागि समाधान सिर्जना गरिसकेका छन् जसलाई हामीले यसलाई थप्दा सूचित गर्न आवश्यक छ? के यो सुविधाले यो निर्माण गर्न कति समय लाग्छ भन्ने सम्भावित रूपमा प्रभाव पार्न सक्ने जानकारीको लागि अन्य टोली/एपिस/स्रोतहरूमा भर पर्छ? (वैकल्पिक) प्रभाव: के यसले टोली वा व्यवसायमा ज्ञात, मापनयोग्य प्रभाव पारेको छ? यो सधैं ज्ञात वा मापन गर्न सजिलो छैन, त्यसैले यो एक वैकल्पिक क्षेत्र हो। तर यदि यो अवस्थित छ भने प्राथमिकताका लागि जान्न महत्त्वपूर्ण छ। अनुकूलन कार्यहरू विवरण: समस्याको संक्षिप्त तर विस्तृत विवरण हालको अवस्था: कोडले हाल कसरी काम गर्छ र यो किन असक्षम छ भन्ने बारे थप विस्तृत व्याख्या। रुचाइएको राज्य: यस अप्टिमाइजेसनको साथ हामीले के समाधान गर्ने लक्ष्य राखेका छौं, हामी कुन लक्ष्यहरू पूरा गर्न खोजिरहेका छौं भन्ने विस्तृत विवरण विकासकर्ता नोटहरू: यो विकासकर्ताबाट एक गाइड हो जसले अप्टिमाइजेसनको आवश्यकतालाई कल गर्दैछ। यसले विशेष फाइलहरू र परीक्षणहरू बोलाउनु पर्छ जुन सम्पादन गर्न आवश्यक छ साथै विशेष खण्डहरू जुन हामी विश्वास गर्छौं कि कार्यसम्पादनमा अवरोध वा भ्रम पैदा गर्दछ। : परीक्षण यस अप्टिमाइजेसनलाई कसरी प्रमाणित वा प्रमाणित गर्न सकिन्छ भन्ने बारे टिप्पणीहरू। हामीले यो प्रक्रियाबाट वास्तवमा केही प्राप्त गरेका छौं भनेर मात्र हेर्न आवश्यक छैन (र यो हामीले गर्व गर्न सक्ने कुरा हुन सक्छ), तर हामीले यो पनि प्रमाणित गर्न आवश्यक छ कि परिवर्तनहरूले कोडमा भर परेका कुनै पनि ज्ञात बाह्य प्रक्रियाहरूलाई प्रभाव पारेको छैन। परिवर्तन भयो। बाह्य प्रभावहरू: यो कामलाई प्रभाव पार्न सक्ने कुनै पनि बाह्य स्रोतहरूलाई कलआउट गर्छौं। के यो सुविधाले यसलाई निर्माण वा परीक्षण गर्न कति समय लाग्ने सम्भावित रूपमा प्रभाव पार्न सक्ने जानकारीको लागि अन्य टोली/एपिस/स्रोतहरूमा भर पर्छ? प्रभाव: के यसले टोली वा व्यवसायमा ज्ञात, मापनयोग्य प्रभाव पारेको छ? यो सँधै ज्ञात वा मापन गर्न सजिलो छैन, तर एक रिफ्याक्टर वा अप्टिमाइजेसनलाई उचित ठहराउन हामीसँग यो जानकारी हुनु आवश्यक छ। टेम्प्लेटहरूको प्रभाव परिणाम तुरुन्तै थियो। हामीले एक घन्टा लामो प्राविधिक डिजाइन बैठकमा पहिलेको तुलनामा लगभग ३ गुणा बढी टिकटहरू प्राप्त गर्न सक्ने हामीले चाँडै देख्यौं। साथै, यी बैठकहरूमा हामीले गरेका छलफलहरू अझ लाभदायक र प्रभावकारी थिए। हामीले एज-केसहरू, प्रभावित टोलीहरू, र सम्भावित शो-स्टपरहरू वा प्रक्रियामा अवरोधहरू बोलाउन समय लिइरहेका थियौं, थप विवरणहरू बुझ्ने प्रयासमा हाम्रो सबै समय खर्च गर्नुको सट्टा कामको लागि devs तयार गर्दै। हामीले आफैंलाई एउटा ढाँचामा जबरजस्ती गर्यौं जहाँ हामीले यी सबै प्रतिक्रियाहरूलाई टिकटमा विवरण वा टिप्पणीहरूमा रेकर्ड गर्यौं। टेम्प्लेटहरू एक निरन्तर रिमाइन्डर थिए कि यी विवरणहरू महत्त्वपूर्ण थिए र तिनीहरू उपस्थित हुनु आवश्यक छ र फेला पार्न सजिलो छ। एक तरिकामा, यी टेम्प्लेटहरूले हाम्रो दिमागलाई कागजातहरू लिनको लागि पुन: प्रशिक्षित गर्यो- यी टिकटहरू तर्फ पहिलो दृष्टिकोण, यो सुनिश्चित गर्दै कि जसले टिकट लिएको छ, चाहे त्यो जुनियर विकासकर्ता होस् वा अनुभवी इन्जिनियर, केही उच्च-गुणस्तर कोड लेख्न पर्याप्त जानकारी हुनेछ। । अर्को, हामीले याद गर्यौं कि हाम्रो विकास चक्रहरू धेरै संक्षिप्त थिए, हाम्रा अनुमानहरू अधिक सटीक थिए, र हामीले पहिले भन्दा धेरै पटक स्प्रिन्टहरूमा 100% पूर्णता चिन्ह प्राप्त गर्ने प्रतिष्ठित थिए। हामीले हाम्रो बोर्ड लगभग लगातार खाली गर्न सक्षम भयौं। यो व्यवसायको लागि मात्र महत्त्वपूर्ण छैन किनभने तिनीहरूले अद्यावधिकहरू प्राप्त गरिरहेका थिए जब हामीले उनीहरूलाई उनीहरूले प्राप्त गर्नेछौं भने, तर यो टोलीको लागि ठूलो आत्मविश्वास बूस्टर थियो किनकि तपाईंले आफूलाई निरन्तर सफलताको स्थितिमा राख्दै हुनुहुन्छ। हाम्रा सरोकारवालाहरूले हाम्रो सुधारिएको दक्षता र थ्रुपुट देखे र हाम्रो टोली र हाम्रो प्रक्रियामा ठूलो विश्वास प्राप्त गरे। तिनीहरूले यो पनि याद गरे कि हाम्रो कोड उच्च गुणस्तर थियो, किनकि हामीले हातमा रहेको वास्तविक समस्यामा ध्यान केन्द्रित गर्न बढी समय खर्च गर्न सक्षम थियौं। हामीलाई सुरुदेखि नै थाहा थियो कि यसले विकासकर्ताहरूको रूपमा हाम्रो जीवनलाई अझ राम्रो बनाउनेछ, तर यसले हाम्रा व्यापार साझेदारहरूमा पनि कत्तिको सकारात्मक प्रभाव पार्छ भन्ने हामीले बुझेका थिएनौं। अन्य टोलीहरूको लागि मुख्य टेकवेहरू यदि तपाइँ तपाइँको टोली लगातार संक्रमण को कमी को बोझ को लागी जस्तो लाग्छ भने यो संरचित टिकट-टेम्प्लेटहरु को लागी तपाइँको लागि काम गर्न सक्छ कि भनेर अनुसन्धान गर्न लायक हुन सक्छ। कल-आउट गर्न महत्त्वपूर्ण छ कि यसले कारबाही गर्न पर्याप्त विवरणसहित टिकटहरू बाहिर निकाल्न थप विकासकर्तालाई समय लिन्छ। म विश्वास गर्छु कि यो एक उचित लागत हो र यसले लामो समयसम्म ठूलो लागत बचत गर्दछ किनकि यसले तपाईंको कार्यप्रवाहलाई धेरै सुधार गर्दछ, तर यो कल गर्न महत्त्वपूर्ण छ कि यी परिवर्तनहरू सित्तैमा हुँदैनन्। कसैले अनुसन्धान गर्न र उच्च-गुणस्तरको टिकट लेख्नको लागि समय समर्पण गर्नुपर्छ र कोही तपाईंको विकास टोली हुन सक्ने सम्भावना छ। यो भनिएको छ, यो हेर्न सजिलो छ कि यो एक टोलीको लागि कति ठूलो जीत हुन सक्छ। सुरु गर्नको लागि म केही छोटो चरणहरू सिफारिस गर्नेछु। , तपाईलाई साँच्चै समस्या छ कि छैन भनेर मूल्याङ्कन गर्नुहोस्। कहिलेकाहीँ एक वा दुई विकासकर्ताहरूले कागजात वा ज्ञान-स्थानान्तरणको साथ संघर्ष गरिरहेका छन् तर यसले तपाईंको टिकटहरूमा पूर्ण-स्तरीय समस्याको संकेत गर्दैन। हुनसक्छ अन्य चीजहरू जस्तै राम्रो अनबर्डिङ वा कागजातहरूले ती समस्याहरू समाधान गर्न सक्छ। पहिले तपाईंले फेला पार्नुभयो कि यो एक व्यापक मुद्दा हो जसको समाधान आवश्यक छ, अर्को चरण भनेको तपाइँ सामान्यतया प्राप्त हुने टिकटहरू र प्रत्येकमा कस्तो प्रकारको जानकारी आवश्यक छ भनेर वर्गीकरण गर्नु हो। स्पष्ट उम्मेद्वारहरू बगहरू र सुविधाहरू हुन्, यद्यपि तपाइँको कम्पनीको व्यवसायको प्रकृतिमा निर्भर गर्दै, तपाइँसँग अन्य प्रकारका टिकटहरू छन् जुन तपाइँको प्रणाली मार्फत निरन्तर प्रवाहित हुन्छन् र फरक आवश्यकताहरू छन्। हुनसक्छ तपाइँको टोलीले ETL पाइपलाइन प्रबन्ध गर्दछ र तपाइँसँग सम्बन्धित टिकटहरूमा कुन आगतहरू/आउटपुटहरू प्रभाव पार्छ भनेर जान्न आवश्यक छ। हुनसक्छ तपाईको टोलीसँग SDK को स्वामित्व छ र यससँग सम्बन्धित टिकटहरू विशेष/प्राथमिकतामा ह्यान्डल गर्न आवश्यक छ र परिवर्तनले कुन व्यवसायिक कार्यहरू प्रभावित हुन सक्छ समावेश गर्न आवश्यक छ? तपाइँको टोली र तिनीहरूका आवश्यकताहरू जान्नुहोस् ताकि तपाइँ निश्चित रूपमा कुन प्रकारका टेम्प्लेटहरू आवश्यक छ भनेर निर्धारण गर्न सक्नुहुन्छ। दोस्रो, यदि तपाइँसँग यो सबै जानकारी भएपछि, यसलाई लिखित रूपमा राख्नुहोस् जहाँ सबैको पहुँच छ। सायद यो साझा कागजात हो, वा एक विकि पृष्ठ हो जुन टोलीले प्रबन्ध गर्दछ र पहुँच गर्दछ, वा सायद तपाईले जिरामा नै टेम्प्लेटहरू सिर्जना गर्न सक्नुहुन्छ, मानिसहरूलाई तिनीहरूलाई प्रयोग गर्न बाध्य पार्दै। तपाईंको दृष्टिकोण जे भए पनि, तपाईंले टोली र विकासकर्ताहरूबाट खरीद-इन प्राप्त गर्न आवश्यक छ जसको मतलब तिनीहरूले यसलाई हेर्न सक्षम हुन आवश्यक छ। यो सबैभन्दा महत्त्वपूर्ण चरणहरू मध्ये एक हो किनभने यो प्रक्रिया अगाडि बढ्ने छैन जबसम्म तपाईंसँग टिकटहरू लेख्ने जो कोहीबाट 100% खरीद-इन छैन। यी टेम्प्लेटहरू तपाइँको टोलीमा प्रस्तुत गर्नुहोस्, प्रतिक्रिया सङ्कलन गर्नुहोस्, तपाइँलाई यो नयाँ प्रक्रियाले तपाइँ र तपाइँको सरोकारवालाहरूलाई कसरी प्रभाव पार्छ भन्ने सोच्नुहोस्। सुनिश्चित गर्नुहोस् कि टोलीमा सबैलाई नयाँ प्रक्रिया संग सहज छ। अर्को, , तपाईंले यी परिवर्तनहरू लागू गर्नुपर्छ। पर्याप्त विवरण बिना प्रस्तुत टिकटहरू छलफल बिना तुरुन्तै फिर्ता फ्याँक्नु पर्छ। टेम्प्लेट दिशानिर्देशहरू पछ्याउने बारे कडा हुनु महत्त्वपूर्ण छ वा मानिसहरूले सधैं यसको वरिपरि प्राप्त गर्ने कारणहरू फेला पार्नेछन्। "यो मुद्दा धेरै गम्भीर छ, मसँग यो लेख्ने समय छैन" हामीले प्राप्त गर्ने सामान्य गुनासो हो। जे होस्, टेम्प्लेटको आवश्यकतासँग कडा हुनु र यसको वरिपरि पुग्न प्रयास गरिरहेका व्यक्तिहरूसँग काम गर्दै, तपाईंले अन्ततः तिनीहरूलाई जित्नुहुनेछ। अन्तमा Wayfair मा हामीले माथि सूचीबद्ध गरिएका साना परिवर्तनहरू गरेर हाम्रो टोलीको प्रक्रिया र मनोबलमा व्यापक सुधारहरू देख्यौं। मलाई आशा छ कि यसले तपाईंको टोलीलाई पनि मद्दत गर्दछ।

संरचित टिकट टेम्प्लेटहरूको साथ टेक डिजाइन बैठकहरू अनुकूलन गर्दै

About Author

टिप्पणीहरू

ह्याङ्ग ट्यागहरू

यो लेख मा प्रस्तुत गरिएको थियो

Related Stories

Transcripts Don't Lie: HackerNoon's New YouTube Feature Keeps Readers on the Same Page

The HackerNoon Newsletter: For Your Next Blog Post: Start Writing via HackerNoon Blogging Templates (7/26/2025)

The HackerNoon Newsletter: The First Provable AI-Proof Game: Introducing Butterfly Wings 4 (2/10/2025)

The HackerNoon Newsletter: Salt Typhoon: The Hidden Hand Behind the Telecom Gift Card Scam? (6/12/2025)

Transcripts Don't Lie: HackerNoon's New YouTube Feature Keeps Readers on the Same Page

The HackerNoon Newsletter: For Your Next Blog Post: Start Writing via HackerNoon Blogging Templates (7/26/2025)

The HackerNoon Newsletter: The First Provable AI-Proof Game: Introducing Butterfly Wings 4 (2/10/2025)

The HackerNoon Newsletter: Salt Typhoon: The Hidden Hand Behind the Telecom Gift Card Scam? (6/12/2025)

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps