हम लगातार उपयोगकर्तावॉयर को बेहतर बनाने के लिए ट्रेलो और Google डॉक्स का उपयोग कैसे करते हैं

जब मैं पिछली बार छुट्टी से लौटा, तो मुझे पता चला कि UserVoice के हमारे उत्पाद प्रबंधक देहाना ने Google डॉक्स में मेरे पसंदीदा रोडमैप को ट्रेलो बोर्ड के साथ बदल दिया है।

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

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

हमारी प्रक्रिया

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

हालांकि, इससे पहले कि हम अपने सभी बोर्डों के कार्यों पर करीब से नज़र डालें, चलो विकास के "संचार प्रणाली" में "रक्त कोशिकाओं" के बारे में बात करते हैं: ट्रेलो कार्ड।

पत्ते

प्रत्येक कार्ड उपयोगकर्ता कहानियों में से एक का प्रतिनिधित्व करता है। यह एक सुधार, प्रसंस्करण या बग के लिए एक कार्य हो सकता है।

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

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

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


हमारे असली चश्मे से लिंक करें

हमारी रसोई

वर्तमान विकास बोर्ड वह बोर्ड है जिस पर "इतिहास बना है।" निम्नलिखित स्तंभ उस पर स्थित हैं:

अगला ऊपर

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

प्रगति में

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

क्यूए

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

लॉन्चपैड (लॉन्च पैड)

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

लाइव ("लॉन्च" (सप्ताह नहीं))

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

अन्य बातों के अलावा, हम तीन लेबल का उपयोग करते हैं जिन्हें कार्ड से जोड़ा जा सकता है:

• बग - बग
• मंचन - स्वास्थ्य जाँच
• उत्पादन - शुरू करना

बहुत आसान है, है ना? यह विकास दृष्टिकोण कानबन प्रणाली के समान है। अब देखते हैं कि इस बोर्ड में कार्ड कैसे मिलते हैं।

माँ, कार्ड कहाँ से आते हैं?

4 अलग-अलग बोर्डों से नए कार्ड दिखाई दे सकते हैं:

उत्पाद रोडमैप

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

इनबॉक्स (आने वाले विचार)

• दो कॉलम हैं: एक कंपनी के सदस्यों के विचारों के साथ, और दूसरे हमारे उपयोगकर्ताओं के विचारों के साथ ( UserVoice हेल्पडेस्क पर संबंधित समर्थन टिकटों के संदर्भ में और हमारे UserVoice उपयोगकर्ता प्रतिक्रिया मंच पर आने वाले विचार)।
• हम इनबाउंड विचारों (नीचे देखें) पर हमारी साप्ताहिक समीक्षा बैठक के दौरान इस बोर्ड के विचारों को देखते हैं।

कीड़े ("कीड़े")

इस बोर्ड में 3 सूचियाँ हैं:

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

• यदि बग "स्वीकृत" हो जाता है और ग्राहक सेवा टीम यह निर्णय लेती है कि यह बग "क्रिटिकल" है (आप हमारी पोस्ट " हमारी महत्वपूर्ण समस्या वृद्धि प्रक्रिया " को पढ़कर यह पता लगा सकते हैं कि हम इस समस्या को कैसे हल करते हैं) बोर्ड वर्तमान विकास और तत्काल हमारे "ऑन-ड्यूटी डेवलपर।"

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

इंजीनियरिंग ("विकास")

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

कौन कहता है कि केंद्रीय योजना काम नहीं कर रही है? (योजना बोर्ड)

योजना बोर्ड वह बोर्ड होता है जिस पर मैं अपना अधिकांश समय हमारे पीएम और यूएक्स मैनेजर के साथ बिताता हूं। इसमें निम्नलिखित कॉलम शामिल हैं:

अगला ऊपर

• निम्नलिखित परियोजनाओं की एक सूची जिसे हम विकास में लॉन्च करना चाहते हैं, लगभग अनुमानित प्राथमिकता पर रखा गया है।

युक्ति ("विनिर्देश")

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

डिज़ाइन ("डिज़ाइन")

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

तैयार ( «समाप्त»)

• यहां आइडिया के सर्जक और डिजाइन टीम द्वारा सत्यापित कार्ड हैं। कभी-कभी वे इंटरफ़ेस आरेख या अन्य आवश्यक कलाकृतियों के साथ होते हैं। अब आप करंट डेवलपमेंट बोर्ड (चर्चा की बैठक में चर्चा और समीक्षा के बाद) पर अगली अप सूची में जाने के लिए तैयार हैं।

प्लानिंग के अलावा किसी भी बोर्ड पर, कार्ड हमेशा बाएं से दाएं की ओर जाते हैं। लेकिन इस बोर्ड पर, कार्ड अक्सर डिज़ाइन या रेडी से स्पेक कॉलम पर जाते हैं (कभी-कभी बार-बार) इससे पहले कि वे वर्तमान विकास बोर्ड को हिट करते हैं।

हमारी बैठकें (या हम एक बोर्ड से दूसरे कार्ड कैसे स्थानांतरित करते हैं)

हमारे पास केवल कुछ साप्ताहिक बैठकें हैं:

सोमवार सुबह - उत्पाद की बैठक (30 मिनट)

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

शुक्रवार की सुबह - इनबॉक्स समीक्षा बैठक (30 मिनट)

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

शुक्रवार दोपहर - योजना बैठक (1 घंटा)

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

हर सुबह - स्टैंड-अप (10 मिनट)

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

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

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

सबक सीखा

हमेशा @ कार्ड पर टिप्पणियों में किसी को देखें यदि आप वास्तव में एक उत्तर प्राप्त करना चाहते हैं
यदि आप किसी को विशेष रूप से संदर्भित किए बिना कार्ड पर एक टिप्पणी लिखते हैं, तो इसका मतलब है कि आपने इसे भविष्य के लिए अपने लिए एक नोट के रूप में लिखा था। यदि आप चाहते हैं कि कोई व्यक्ति आपकी टिप्पणी पर ध्यान दें, तो संकेत करें कि यह Trello में @ प्रतीक के साथ किसका होना चाहिए।

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

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

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

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

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

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

अपनी सफलता का जश्न मनाने की कोशिश करें।
यह समझना महत्वपूर्ण है कि हमेशा काम किया जाता है। हर हफ्ते हम कार्ड के लिए एक अलग कॉलम बनाते हैं, जिसे ऑपरेशन में लगाया जाता है, ताकि यह स्पष्ट हो सके कि हमने इस सप्ताह क्या हासिल किया है। हम उन सभी की तस्वीरों का भी उपयोग करते हैं जिन्होंने सोमवार को हमारी बैठकों में सफलतापूर्वक कार्य पूरा किया।

मुझे उम्मीद है कि यह लेख आपके लिए उपयोगी रहा होगा। इस मजबूत प्रक्रिया को बनाने के लिए डेजाना बजिक (पीएम), जोशुआ रुड (यूएक्स मैनेजर) और जोनाथन नोवाक (लीड डेवलपर) का धन्यवाद।

अनुवादक से उपयोगी लिंक:

“ ट्रेलो उत्पादकता गाइड। उपयोगी एक्सटेंशन और सेटिंग्स » »

« आप चुस्त विकास के लिए ट्रेलो का उपयोग कैसे करते हैं? "- स्क्रू के लिए ट्रेलो का उपयोग करने के लिए Quora- थ्रेड

" पांच युक्तियाँ "