आप पूछते हैं, फिक्सिट क्या है?
तिमाही में एक बार, ~45 सॉफ्टवेयर इंजीनियरों वाला मेरा संगठन एक सप्ताह के लिए सभी नियमित काम बंद कर देता है। इसका मतलब है कि कोई रोडमैप कार्य नहीं, कोई डिज़ाइन कार्य नहीं, कोई मीटिंग या स्टैंडअप नहीं।
इसके बजाय, हम उन छोटी-छोटी चीजों को ठीक करते हैं जो हमें और हमारे उपयोगकर्ताओं को परेशान कर रही हैं:
- एक त्रुटि संदेश जो दो वर्षों से अस्पष्ट है
- जब उपयोगकर्ता एक ही समय में स्क्रॉल और ज़ूम करता है तो एक अजीब गड़बड़ी होती है
- एक परीक्षण जो अपेक्षा से अधिक धीमी गति से चलता है, सभी के लिए सीआई को धीमा कर देता है
नियम सरल हैं: 1) किसी भी बग में 2 दिन से अधिक का समय नहीं लगना चाहिए और 2) सारा काम या तो छोटे एंड-यूज़र बग/फीचर्स या डेवलपर उत्पादकता पर केंद्रित होना चाहिए।
हमारे पास बग के लिए एक “अंक प्रणाली” और एक लीडरबोर्ड भी है जो दिखाता है कि लोगों के पास कितने अंक हैं। और विभिन्न उपलब्धियों के लिए टी-शर्ट का वादा किया गया है: पहला बग फिक्स, सबसे अधिक अंक, सबसे कष्टप्रद बग, आदि। यह एक सरल संरचना है, लेकिन यह आश्चर्यजनक रूप से अच्छी तरह से काम करता है।
हमने क्या हासिल किया
इस फिक्सिट से कुछ आँकड़े:
- 189 बग ठीक किये गये
- 40 लोगों ने भाग लिया
- 4 प्रति व्यक्ति बंद किए गए बग की औसत संख्या थी
- एक व्यक्ति द्वारा बंद किए गए बग की अधिकतम संख्या 12 थी
Q4’25 फिक्सिट के लिए बग बर्नडाउन चार्ट
यहां कुछ मुख्य अंश दिए गए हैं (दुख की बात है कि मेरे संगठन में कई लोग आंतरिक-सामना वाली चीजों में काम करते हैं इसलिए मैं उनके काम को साझा नहीं कर सकता!):
- मैंने 2021 से एक सुविधा अनुरोध बंद कर दिया है! यह एक क्लासिक फिक्सिट मुद्दा है: एक छोटा सा सुधार जो कभी भी प्राथमिकता सूची में नहीं आया। इसके लिए मुझे लगे एक दिन अमल करना। एक दिन किसी ऐसी चीज़ के लिए जिसके लिए वह वहां बैठी थी चार साल. और यह पर्फ़ेटो के प्रत्येक उपयोगकर्ता के अनुभव को एक छोटा लेकिन महत्वपूर्ण बढ़ावा देने जा रहा है।
- मेरे सहकर्मी ने टीम उत्पादकता में सुधार के लिए यह छोटा सा बदलाव किया। प्रत्येक यूआई डेवलपर को सीआई के निर्माण को खोलने के लिए दो अतिरिक्त क्लिक लेने से बचाने के लिए गिटहब एक्शन में कोड की केवल ~25 लाइनें। टीम की प्रतिक्रिया अपने आप में बहुत कुछ कहती है:
इतना आसान बदलाव लेकिन टीम को यह पसंद आया!
- मैंने हमारे एसडीके का एक नया “समामेलित” संस्करण प्रदान करने के लिए इस समस्या को भी ठीक किया, जिससे इसे परियोजनाओं में आसानी से एकीकृत किया जा सके। यह उन चीजों में से एक है जो हमें उपयोग करने या न करने का निर्णय लेने वाले व्यक्ति के बीच अंतर हो सकता है, लेकिन इसे बनाने में केवल एक घंटे का काम लगा (एआई के उदार उपयोग के साथ!)।
फिक्सिट्स के लाभ
उत्पाद के लिए: शिल्प कौशल और देखभाल
मैं जिस भी उत्पाद पर काम करता हूं उसका बहुत ध्यान रखता हूं। इसका अर्थ है “हमें क्या बनाना चाहिए?” जैसे बड़े प्रश्न पूछना। और “हम इसे तेजी से कैसे बना सकते हैं?” लेकिन इसका अर्थ छोटे प्रश्न पूछना भी है: “क्या यह त्रुटि संदेश वास्तव में सहायक है?” या “क्या मैं इसका उपयोग करके निराश हो जाऊँगा?”
किसी भी अच्छे उत्पाद की पहचान विवरण पर ध्यान देना है: एक एहसास कि किसी ने चीजों के बारे में सोचा है, और टुकड़े एक साथ फिट होकर एक समग्र बनाते हैं। और विपरीत सत्य है: यदि कोई विकल्प न हो तो खुरदरे किनारों वाला उत्पाद सहन किया जा सकता है, लेकिन निराशा की भावना हमेशा बनी रहेगी और “काश मैं कुछ और उपयोग कर पाता”।
फिक्सिट्स उन विवरणों पर काम करने का एक शानदार मौका है जो अच्छे उत्पादों को महान उत्पादों से अलग करते हैं। छोटी-छोटी बातें जो आपका औसत उपयोगकर्ता जानबूझकर नोटिस नहीं कर सकता है, लेकिन यदि वे गलत हैं तो निश्चित रूप से नोटिस करेगा।
व्यक्ति के लिए: करना, सोचना नहीं
मुझे कभी-कभी उस अहसास की याद आती है जो मैंने अपने करियर के आरंभ में महसूस किया था जब मुझे चीजों को ठीक करने का मौका मिला था। कुछ टूटा हुआ देखें, उसे ठीक करें, उसी दिन भेज दें।
आप किसी बड़ी कंपनी में जितने अधिक वरिष्ठ होंगे, आप उतना ही कम काम करेंगे। आपका अधिकांश समय यह सोचने में बीत जाता है कि आगे क्या बनाना है, आगे की तिमाहियों की योजना बनाना, ट्रेडऑफ़ को नेविगेट करना और संरेखण प्राप्त करना।
फिक्सिट्स ने मुझे शुरुआती करियर का एहसास वापस दिला दिया है। आप बग देखते हैं, आप उसे ठीक करते हैं, आप उसे शिप करते हैं, आप उसे बंद करते हैं, आप आगे बढ़ते हैं। काम के बारे में कुछ बहुत ही संतुष्टिदायक है जहां सवाल यह नहीं है कि “हमें क्या करना चाहिए?” बल्कि “क्या मैं इसे बेहतर बना सकता हूँ?” और आपको उस प्रश्न का उत्तर एक सप्ताह में कई बार देना होता है।
टीम के लिए: मनोबल और भावना
लोग फिक्सिट चैटरूम में लाइव अपडेट साझा कर रहे हैं
दो समय क्षेत्रों में 40 लोगों का एक साथ मिलकर सभी बग्स को ठीक करना एक अन्य आयाम जोड़ता है।
कार्यालय का माहौल अलग होता है: आम तौर पर हम सभी अलग-अलग परियोजनाओं को लेकर असमंजस में रहते हैं, लेकिन फिक्सिट के दौरान टीम भावना मजबूत होती है। लोग चैट रूम में अपने बग समाधान साझा करते हैं, पहले और बाद के स्क्रीनशॉट पोस्ट करते हैं और किसी नई सुविधा का प्रदर्शन करने के लिए मॉनिटर के पास इकट्ठा होते हैं या किसी विशेष रूप से खराब बग के बारे में शिकायत करते हैं जिससे वे जूझ रहे हैं।
शुक्रवार से दैनिक अद्यतन
लीडरबोर्ड इस ऊर्जा को बढ़ाता है। प्रतिस्पर्धा की एक दोस्ताना भावना है क्योंकि लोग त्वरित जीत को संतुलित करने की कोशिश करते हैं और उन खतरनाक कीड़ों के बारे में सोचते हैं जिनके बारे में वे कहानियाँ साझा कर सकते हैं।
पिछला दिन कैसा गुजरा, इसके बारे में हर सुबह एक संक्षिप्त अपडेट भी होता है:
- कुल बग ठीक हो गए
- कितने लोगों ने कम से कम एक बग ठीक किया है
- हमने कितने अलग-अलग उत्पादों में चीज़ें ठीक की हैं
- जो इस समय लीडरबोर्ड में शीर्ष पर है
यह सब वास्तविक गति पैदा करता है, और लोग इस प्रयास में चुंबकीय रूप से आकर्षित महसूस करते हैं।
फिक्सिट कैसे चलाएं
मैंने पिछले कुछ वर्षों में 6 फ़िक्सिट्स में भाग लिया है और मैंने इस बारे में बहुत कुछ सीखा है कि उन्हें सफल क्या बनाता है। यहां कुछ चीजें हैं जो आपकी सोच से कहीं ज्यादा मायने रखती हैं।
तैयारी महत्वपूर्ण है
फिक्सिट का अधिकांश काम सप्ताह शुरू होने से पहले ही हो जाता है।
पूरे वर्ष, हम हर किसी को बग का सामना करने पर उन्हें “अच्छे फिक्सिट उम्मीदवार” के रूप में टैग करने के लिए प्रोत्साहित करते हैं। फिर फिक्सिट से एक सप्ताह पहले, प्रत्येक उपटीम इन बगों से गुजरती है और उन्हें आकार देती है:
- छोटा (आधे दिन से भी कम)
- मध्यम (एक दिन से भी कम)
- बड़ा (2 दिन से कम)।
वे तदनुसार अंक प्रदान करते हैं: 1, 2, या 4।
हम उच्च-प्राथमिकता वाले बगों की एक संक्षिप्त सूची भी बनाते हैं जिन्हें हम वास्तव में ठीक करना चाहते हैं। लोग वहां से शुरू करते हैं और काम पूरा हो जाने पर पूरी सूची की ओर बढ़ते हैं। यह पूर्व-कार्य महत्वपूर्ण है: यह लोगों को ठीक करने के लिए लक्ष्यहीन रूप से बग खोजने के कारण अपना पहला दिन बर्बाद होने से बचाता है।
2 दिन की कठिन सीमा
हमारे शुरुआती सुधारों में से एक में, किसी ने एक सीधी बग जैसी दिखने वाली चीज़ को उठाया। इसमें कुछ घंटे लगने चाहिए थे, शायद आधा दिन। लेकिन यह खरगोश के बिल में बदल गया। अन्य प्रणालियों पर निर्भरता, अप्रत्याशित किनारे के मामले, कोड जिन्हें वर्षों से नहीं छुआ गया था।
उन्होंने पूरा फिक्सिट सप्ताह इस पर बिताया। और फिर फिक्सिट के बाद पूरा सप्ताह इसे खत्म करने की कोशिश करता रहा। बग फिक्स के रूप में जो शुरू हुआ वह एक मिनी प्रोजेक्ट में बदल गया। काम बहुमूल्य था! लेकिन वे फिक्सिट के पूरे मुद्दे से चूक गए। पूरे सप्ताह कोई समापन बग नहीं। कोई गति नहीं. शिपिंग सुधारों से कोई डोपामाइन प्रभावित नहीं होता। बस एक लंबा नारा.
इसीलिए अब हमारे पास 2 दिन की कठिन सीमा है। यदि कुछ बढ़ रहा है, तो अपना नुकसान कम करें। एक उचित बग फ़ाइल करें, इसे बैकलॉग में ले जाएँ, कुछ और चुनें। सीमा काम के बेकार होने के बारे में नहीं है – यह फिक्सिट को फिक्सिट जैसा महसूस कराने के बारे में है।
लोगों की संख्या मायने रखती है
हमने हमेशा 40 लोगों के साथ फिक्सिट नहीं किया। आरंभ में, यह एक संगठन-व्यापी प्रयास नहीं था, केवल 7 लोगों की मेरी उपटीम थी। यह ठीक से काम कर रहा था: बग ठीक हो गए और उत्पाद को बेहतर बनाने में गर्व की अनुभूति हुई। लेकिन यह थोड़ा खोखला महसूस हुआ: हमारे संगठन की बड़ी तस्वीर में, ऐसा महसूस नहीं हुआ कि किसी और ने ध्यान दिया या परवाह की।
~40 लोगों पर, यह एक महत्वपूर्ण द्रव्यमान की तरह महसूस होता है जो चीजों को महत्वपूर्ण रूप से बदल देता है। जादुई संख्या संभवतः 7 और 40 के बीच है। और यह संभवतः टीम के आधार पर भिन्न होती है। लेकिन संख्या जो भी हो, सामूहिक ऊर्जा मायने रखती है। यदि आप इसे 5 लोगों के साथ आज़मा रहे हैं, तो यह अभी भी करने लायक हो सकता है, लेकिन संभवतः यह वैसा महसूस नहीं होगा।
gamification
अंक और लीडरबोर्ड एक नौटंकी से कहीं अधिक हैं, लेकिन उन्हें सावधानी से संभालना होगा।
हमारे लिए क्या काम करता है:
- बातें स्थूल हैं, सटीक नहीं: हम सटीक प्रयास को मापने की कोशिश करने के बजाय जानबूझकर 1/2/4 अंक का उपयोग करते हैं; लक्ष्य “मोटे तौर पर सही और मजेदार” है, सटीक प्रदर्शन मूल्यांकन नहीं।
- सिर्फ आयतन का नहीं, चौड़ाई का भी जश्न मनाएं। हम केवल “अधिकांश बिंदुओं” के लिए ही नहीं, बल्कि “पहला बग फिक्स”, “सबसे कष्टप्रद बग फिक्स” जैसी चीजों के लिए भी टी-शर्ट देते हैं। इससे नए या कम अनुभवी इंजीनियर लगे रहते हैं।
- पुरस्कारों पर दृश्यता. दैनिक अद्यतन या आंतरिक पोस्ट में एक चिल्लाहट अक्सर वास्तविक टी-शर्ट से अधिक मायने रखती है।
- संपूर्ण समीक्षाओं से कोई लगाव नहीं. यह महत्वपूर्ण है: फिक्सिट स्कोर करते हैं नहीं प्रदर्शन समीक्षाओं में फ़ीड करें. जैसे ही वे ऐसा करेंगे, लोग इसे खेलना शुरू कर देंगे और अच्छा माहौल खत्म हो जाएगा।
हमारे पास व्यवहार में बहुत कम “गेमिंग” है। सामाजिक मानदंड लोगों को ईमानदार रखने का अच्छा काम करते हैं और 40 की उम्र अभी भी इतनी छोटी है कि लोगों में “उद्देश्य के प्रति वफादारी” की भावना होती है।
एआई कारक
फिक्सिट्स के साथ बड़ी चुनौती संदर्भ स्विचिंग है। आप जिस पर काम कर रहे हैं उसे लगातार बदलने का मतलब है लगातार कोडबेस के नए हिस्सों का पता लगाना, नई समस्याओं के बारे में सोचना।
एआई टूल्स ने इसे बड़े पैमाने पर कम किया है। वे जो कोड लिखते हैं, वह प्रासंगिक फ़ाइलों को शीघ्रता से खोजने और जो बदलने की आवश्यकता है उसे संक्षेप में प्रस्तुत करने की उनकी क्षमता से कम महत्वपूर्ण है। वे सही या गलत हो सकते हैं, लेकिन उस शुरुआती बिंदु का होना वास्तव में संज्ञानात्मक भार को कम करता है। और कभी-कभी (शायद ही कभी) वे एक बार में ही ठीक कर देते हैं।
यह दस्तावेज़ परिवर्तन उपरोक्त का एक आदर्श उदाहरण था: हमारे दस्तावेज़ों के लिए एक अद्यतन जो नए योगदानकर्ताओं को पकड़ता है और एआई एक-शॉट में समाधान करने में सक्षम था।
दूसरी ओर, मेरे रिकॉर्ड पृष्ठ परिवर्तन में यह मुझे प्रोटोटाइप देने के लिए अधिक उपयोगी था कि कोड कैसा दिखना चाहिए और मुझे इसके द्वारा उत्पन्न खराब यूएक्स और “अति-उत्पन्न” कोड की प्रवृत्ति को ठीक करने के लिए महत्वपूर्ण प्रयास करना पड़ा। फिर भी, इसने मुझे शुरुआती लाइन पर बहुत तेजी से पहुंचा दिया।
फिक्सिट्स की आलोचनाएँ (और मैं उन्हें अब भी क्यों पसंद करता हूँ)
मैं निश्चित रूप से ऐसे लोगों से मिला हूं जो सवाल करते हैं कि क्या फिक्सिट्स वास्तव में एक अच्छा विचार है। कुछ आलोचनाएँ उचित हैं लेकिन कुल मिलाकर मुझे अभी भी लगता है कि यह इसके लायक है।
“क्या यह सिर्फ यह स्वीकार करना नहीं है कि आप बाकी समय बग्स को नजरअंदाज करते हैं?”
कुछ हद तक, हाँ, यह इस तथ्य की स्वीकृति है कि प्रबंधकों और इंजीनियरों दोनों द्वारा “पेपरकट” बग को कम महत्व दिया जाता है। यह सुनिश्चित करना बहुत आसान है कि एक बड़ा प्रोजेक्ट सफल हो और उपयोगकर्ताओं और टीम के लिए छोटी-मोटी परेशानियों को नज़रअंदाज करना आसान हो।
फिक्सिट्स इसे कुछ हद तक संतुलित करने का एक तरीका है और कहा जाता है कि “वास्तव में वे बग भी मायने रखते हैं”। इसका मतलब यह नहीं है कि हम नियमित कार्य के दौरान महत्वपूर्ण बग ठीक नहीं करते हैं; हम बिल्कुल ऐसा करते हैं। लेकिन फिक्सिट्स मानते हैं कि “यह थोड़ा परेशान करने वाला है लेकिन कभी भी इतना जरूरी नहीं है” वर्ग की समस्याओं से निपटने के लिए एक जगह होनी चाहिए।
हमारे द्वारा सबसे पहले फिक्सिट्स शुरू करने का पूरा कारण यह है कि हमने देखा कि इन बगों पर कभी कार्रवाई नहीं होती है। इसे देखते हुए, मुझे लगता है कि इसके लिए कुछ स्पष्ट समय निकालना एक अच्छी बात है।
“क्या पूरे एक सप्ताह के लिए रोडमैप कार्य को रोकना बर्बादी नहीं है?”
यह निश्चित रूप से एक समझौता है। 40 इंजीनियर-सप्ताह एक है बहुत जनशक्ति की और एक तर्क दिया जा रहा है कि इसका उपयोग वास्तव में रोडमैप समस्याओं को हल करने के लिए किया जाना चाहिए।
लेकिन मुझे लगता है कि यह उपयोगकर्ताओं के लिए उत्पादों की पॉलिश के महत्व को कम करता है। हमने लगातार पाया है कि उत्पाद बाद में काफ़ी बेहतर महसूस करता है (जिसमें उपयोगकर्ताओं द्वारा नोटिस की गई चीज़ों के बारे में सकारात्मक टिप्पणियाँ भी शामिल हैं!) और एक भावना है गर्व एक अच्छी तरह से काम करने वाला उत्पाद होने में।
पर्फ़ेट्टो यूआई “रिकॉर्ड” पृष्ठ को बेहतर बनाने के लिए मेरे पीआर पर एक उपयोगकर्ता की प्रतिक्रिया
साथ ही, टीम की उत्पादकता में से कई यौगिक (तेज़ परीक्षण, स्पष्ट त्रुटियां, सुचारू वर्कफ़्लो) को ठीक करते हैं ताकि लाभ सप्ताह के बाद भी आगे बढ़ें।
यह केवल बड़ी कंपनियों में काम करता है!
मैं सहमत हूं कि छोटी टीमों या स्टार्टअप के लिए पूरा एक सप्ताह बहुत अधिक हो सकता है। लेकिन आप अभी भी इस विचार को छोटे टुकड़ों में उधार ले सकते हैं: महीने में एक बार “फ़िक्सिट फ्राइडे”, या प्रत्येक तिमाही में 2-दिवसीय मिनी-फ़िक्सिट। मूल विचार एक ही है: जिस चीज़ के बारे में लोग शिकायत करते हैं उसे ठीक करने के लिए संरक्षित, सामूहिक समय, लेकिन कोई भी संबोधित करने के लिए समय निर्धारित नहीं करता है।
फिक्सिट्स आत्मा के लिए अच्छे हैं
फिक्सिट्स का आधिकारिक औचित्य यह है कि वे उत्पाद की गुणवत्ता और डेवलपर उत्पादकता में सुधार करते हैं। और निःसंदेह वे ऐसा करते हैं।
लेकिन अनौपचारिक कारण जो मुझे उनसे पसंद है वह सरल है: चीजों को ठीक करना अच्छा लगता है। यह मुझे एक सरल समय में वापस ले जाता है, और अच्छे उत्पादों के निर्माण में विचार और ध्यान लगाना मेरे लोकाचार का एक बड़ा हिस्सा है कि सॉफ्टवेयर इंजीनियरिंग कैसे की जानी चाहिए। मैं हर समय इस तरह काम नहीं करना चाहूँगा। लेकिन मैं ऐसी जगह भी काम नहीं करना चाहूँगा जिसके लिए कभी समय ही न मिले।
<a href