इंटरनेट का आविष्कार होने के बाद से सॉफ्टवेयर विकास में 100 गुना सुधार हुआ है, लेकिन 1990 के दशक से लोग बग की रिपोर्ट कैसे करते हैं, यह नहीं बदला है। क्या आपने कभी इसका अनुभव किया है? एक इंजीनियर एक टिकट उठाता है, और कुछ जांच के बाद, वे निर्धारित करते हैं कि यह उनके अंत में ठीक काम करता है, और उनके पास बग को पुन: पेश करने के लिए पर्याप्त जानकारी नहीं है। वे टिकट पर एक टिप्पणी जोड़ते हैं, एक अलग कार्य पर स्विच करते हैं, और बग रिपोर्टर द्वारा उन्हें अधिक जानकारी प्रदान करने की प्रतीक्षा करते हैं। यह चक्र कई बार दोहराता है, और हर बार टिकट में नई जानकारी होने पर, इंजीनियर को यह याद रखना पड़ता है कि उन्होंने कहाँ छोड़ा था और धागे को उठाने की कोशिश करनी चाहिए। इस तरह के संदर्भ स्विच इंजीनियरों के लिए दर्दनाक हैं, और इस तरह की परेशानी के लिए सामान्य बग-रिपोर्टिंग प्रक्रिया पोस्टर चाइल्ड लगती है। एक बग का वास्तविक जीवन कल्पना कीजिए कि एक साथी कर्मचारी इंजीनियरिंग स्लैक चैनल में एक लॉगिन समस्या की रिपोर्ट करता है, और इंजीनियरों के एक जोड़े ने जांच के लिए सब कुछ छोड़ दिया। अपने सर्वोत्तम प्रयासों के बावजूद, वे इस मुद्दे को दोहरा नहीं सकते। वे ब्राउज़र और डिवाइस के प्रकार जैसी अधिक जानकारी का अनुरोध करते हैं। फिर वे कर्मचारी को कैश साफ़ करने और पेज को रीफ़्रेश करने जैसे विभिन्न समस्या निवारण चरणों को आज़माने का निर्देश देते हैं। Async चैट आगे और पीछे अक्सर एक घंटे या उससे अधिक समय लेती है। आखिरकार, इंजीनियरिंग टीम को कर्मचारी के साथ उनके कंप्यूटर पर समस्या की पहचान करने का प्रयास करने के लिए डिबगिंग कॉल शेड्यूल करना पड़ता है। कॉल के दौरान, कर्मचारी अपनी स्क्रीन साझा करता है, और इंजीनियर उनका मार्गदर्शन करते हैं कि क्या हो रहा है यह जानने के लिए देव उपकरणों में कंसोल और नेटवर्क टैब कैसे खोलें। आखिरकार, इंजीनियर देखते हैं कि नेटवर्क टैब में 401 त्रुटि है, जो कहती है, "गलत पासवर्ड।" संक्षेप में, समस्या यह नहीं थी कि लॉगिन टूट गया था, यह था कि फ्रंट एंड "गलत पासवर्ड" त्रुटि संदेश को बुलबुला करने और उपयोगकर्ता को प्रदर्शित करने में विफल रहा। एक साधारण फ्रंट-एंड एरर जिसे पहचानने और हल करने में पांच मिनट लगने चाहिए थे, उसके लिए कुछ इंजीनियरों को दोपहर का समय देना पड़ा। वक्त है बदलाव का आज की बग-रिपोर्टिंग प्रक्रिया पुरातन बनी हुई है। 1990 के दशक के बाद से, दुनिया ने स्लैक जैसे इंस्टेंट मैसेजिंग और जूम की तरह वीडियो-कॉलिंग का आविष्कार किया है, और विश्व स्तर पर दूरस्थ कार्य को अपनाया है। बग संचार डिजिटल हो गया है। बग ट्रैकिंग लिखित फाइलों से जीरा टिकटों तक चली गई है। और फिर भी, बग रिपोर्टिंग अभी भी आगे-पीछे के पेस्की से भरी हुई है जो इंजीनियरिंग समय बर्बाद करती है। हम सभी ने अस्पष्ट बग रिपोर्ट से निपटने की हताशा का अनुभव किया है जिसमें समस्या को हल करने के लिए आवश्यक संदर्भ का अभाव है। इसलिए एक साल पहले, हममें से कुछ लोगों ने बेहतर तरीके की कल्पना करना शुरू किया। क्या होगा यदि हम एक नया उपकरण बना सकें जो बग रिपोर्टिंग को आधुनिक बनाता है और अस्पष्ट बग रिपोर्ट की समस्या को हल कर सकता है, आगे-पीछे संचार की आवश्यकता को कम कर सकता है, और इंजीनियरों का समय और ऊर्जा बचा सकता है? और इसलिए, के लिए विचार पैदा हुआ था। बग-रिपोर्टिंग प्रक्रिया को अधिक उत्पादक और कुशल बनाने के लिए डिज़ाइन किया गया एक उपकरण। हम एक ऐसा समाधान बनाना चाहते थे जो इंजीनियरों को संचार समस्याओं के बजाय तकनीकी बगों को हल करने में मदद करे। जाम इसलिए, हम एक ऐसा टूल बनाने के लिए तैयार हुए, जो किसी को भी, चाहे उनकी तकनीकी पृष्ठभूमि कुछ भी हो, बग के बारे में समृद्ध प्रासंगिक तकनीकी डेटा कैप्चर करने में सक्षम करेगा, ताकि इंजीनियर जल्दी से मुद्दों की पहचान कर सकें और उनका समाधान कर सकें। हम एक ऐसा टूल बनाना चाहते थे जो इंजीनियरों के जीवन को आसान बना दे, साथ ही उन लोगों की भी मदद करे जो उन्हें समस्याओं की रिपोर्ट करते हैं और अधिक प्रभावी भी हों। जैसा कि हमने पिछले साल की शुरुआत में जैम का विकास और परीक्षण किया था, हमने अपनी टीम के काम करने के तरीके को गति देने की क्षमता देखी। उदाहरण के लिए - बग के इस Jam को हमारे अपने कोड में लें। लाइव डिबग करने के लिए कॉल पर कूदने की आवश्यकता के बजाय, हमारे इंजीनियर बग रिपोर्ट से ही देख सकते हैं कि समस्या क्या थी। हमने जाम को अन्य इंजीनियरिंग टीमों के साथ साझा करना शुरू किया, और हम प्रतिक्रिया से वास्तव में उत्साहित थे। Ramp, T-Mobile, और Dell जैम को अपनाने वालों में सबसे पहले थे और उन्होंने बहुमूल्य प्रतिक्रिया प्रदान की जिससे हमें उत्पाद को आकार देने में मदद मिली। उनके इनपुट पर ध्यान देते हुए, अब हमें यह कहते हुए गर्व हो रहा है कि जैम के 14,000 से अधिक उपयोगकर्ता हैं और गिनती जारी है। लेकिन हमारा काम पूरा होने से बहुत दूर है। हम जानते हैं कि बग-रिपोर्टिंग प्रक्रिया इंजीनियरों के लिए हताशा का एक प्रमुख स्रोत हो सकती है, और हम इसे बदलने के लिए प्रतिबद्ध हैं। यदि आप अस्पष्ट बग रिपोर्ट से तंग आ चुके हैं, तो हम आपको Jam को आज़माने के लिए आमंत्रित करते हैं और हमें बताएं कि आप क्या सोचते हैं। हम इंजीनियरिंग के लिए बेहतर भविष्य बनाने के मिशन पर हैं और इसे पूरा करने के लिए हमें आपकी प्रतिक्रिया की आवश्यकता है। आप मुझसे व्यक्तिगत रूप से dani@jam.dev पर संपर्क कर सकते हैं और इस यात्रा में हमारे साथ शामिल हो सकते हैं।
