कनबन काम क्यों करता है — और कैसे जानें कि आपकी टीम इसके लिए तैयार है या नहीं

ज़्यादातर टीमें कनबन इसलिए अपनाती हैं क्योंकि किसी ने एक ब्लॉग पोस्ट पढ़ ली थी। समझदारी भरा सवाल यह है कि कनबन जिन समस्याओं को हल करता है, क्या वही आपकी टीम की असल समस्याएँ हैं।

एक ऐसा पल होता है जिसे ज़्यादातर टीमें पहचानती हैं, आमतौर पर तब जब टीम में आठ-नौ से ज़्यादा लोग हो जाते हैं। काम हो रहा होता है — ईमेल भेजे जाते हैं, फ़ीचर शिप होते हैं, क्लाइंट संभाले जाते हैं — लेकिन किसी को साफ़ पता नहीं होता कि बाकी सब क्या कर रहे हैं। प्रोजेक्ट जमा होते जाते हैं। चीज़ों का वादा किया जाता है और फिर चुपचाप भुला दिया जाता है। हर मीटिंग से पहले आप बीस मिनट यह पता लगाने में लगाते हैं कि कोई काम असल में कहाँ अटका है। जवाब अक्सर यही मिलता है: "कहीं तो है।"

कनबन इसी समस्या को हल करने के लिए बनाया गया था। रणनीति तय करने, सही लोगों को हायर करने या संस्कृति बनाने की समस्या नहीं — बल्कि यह जानने की ठोस, थका देने वाली, परिचालन से जुड़ी समस्या कि आपकी टीम किस काम में लगी है और रास्ते में क्या रुकावट आ रही है।

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

कनबन वास्तव में कहां से आया

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

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

सॉफ़्टवेयर डेवलपर्स ने, ख़ासकर 2000 के दशक की शुरुआत में Microsoft जैसी कंपनियों में, इन विचारों को नॉलेज वर्क के अनुरूप ढालना शुरू किया। कार्ड टास्क बन गए। फ़ैक्टरी के स्टेशन वर्कफ़्लो के चरण बन गए। और साइनबोर्ड एक बोर्ड बन गया — पहले भौतिक, फिर डिजिटल — जहाँ टीम का कोई भी व्यक्ति एक नज़र में देख सकता था कि क्या चल रहा है, क्या इंतज़ार में है और क्या पूरा हो चुका है।

कनबन बोर्ड आपको वास्तव में क्या दिखाता है

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

एक कंटेंट टीम ये चरण रख सकती है: आइडिया, ब्रीफ़, ड्राफ़्ट में, समीक्षा में, शेड्यूल्ड, प्रकाशित। एक सॉफ़्टवेयर टीम "प्रगति में" को डेवलपमेंट, कोड रिव्यू और QA के अलग-अलग कॉलम में बाँट सकती है। एक कंसल्टिंग टीम डिस्कवरी, प्रपोज़ल, सक्रिय, क्लाइंट के जवाब का इंतज़ार और बंद को ट्रैक कर सकती है। चरणों में असली हैंडऑफ़ और असली इंतज़ार की जगहें झलकनी चाहिए — यानी वे जगहें जहाँ काम एक के हाथ से दूसरे के हाथ में जाता है, या तब तक रुका रहता है जब तक कुछ और न हो जाए।

बीच के कॉलम के कार्ड पर ध्यान दें — गोदाम की ऑडिट रिपोर्ट, आठ दिन से अटकी हुई, "अवरुद्ध" चिह्नित। बोर्ड के बिना वाले सिस्टम में यह टास्क किसी को पता चलने से पहले दो हफ़्ते और पड़ा रह सकता है कि वह आगे नहीं बढ़ रहा। कोई किसी तीसरे पक्ष का इंतज़ार कर रहा है। या किसी मैनेजर से फ़ैसला चाहिए, जिसे पता ही नहीं कि रुकावट वही हैं। बोर्ड रुकावट को सामने ला देता है। ज़्यादातर काम यही है।

वह नियम जो इसे कारगर बनाता है: WIP सीमाएँ

अगर कोई एक अवधारणा है जो कनबन को सही ढंग से इस्तेमाल करने वाली टीमों को उन टीमों से अलग करती है जिनके पास बस एक ज़्यादा सुंदर टू-डू लिस्ट है, तो वह है वर्क-इन-प्रोग्रेस की सीमाएँ — संक्षेप में WIP सीमाएँ। विचार यह है कि हर कॉलम में एक समय में अधिकतम कितने आइटम रह सकते हैं, यह तय होता है। जब कोई कॉलम भर जाता है, तो जब तक कुछ बाहर न निकले, आप उसमें और काम नहीं जोड़ सकते।

यह सुनने में उल्टा लगता है। प्रगति में ज़्यादा टास्क रखने का मतलब क्या यह नहीं कि ज़्यादा काम हो रहा है? नहीं। जब लोग एक साथ बहुत सारी चीज़ों पर काम करते हैं, तो असल में यह होता है कि हर चीज़ में ज़्यादा समय लगता है। कॉन्टेक्स्ट स्विचिंग महँगी पड़ती है। अधूरे काम से कोऑर्डिनेशन का बोझ बढ़ता है। और जब दस चीज़ें "प्रगति में" हों, तो यह बताना बहुत मुश्किल हो जाता है कि कौन-सी सच में आगे बढ़ रही हैं और कौन-सी बस अटकी हैं, पर उन पर निशान नहीं लगा।

आपके "प्रगति में" कॉलम पर तीन की WIP सीमा का मतलब है कि जब चौथा काम किसी की डेस्क पर आता है, तो टीम में किसी को फ़ैसला लेना पड़ता है: मौजूदा कामों में से कौन-सा पहले पूरा होगा? यह प्राथमिकता तय करने पर मजबूर करता है। यह बातचीत करने पर मजबूर करता है। और इसका नतीजा अक्सर यह होता है कि अलग-अलग आइटम जल्दी पूरे होते हैं, भले ही नई चीज़ें शुरू करने की रफ़्तार धीमी पड़ जाए।

कनबन बनाम Scrum: वह सवाल जो टीमें हमेशा पूछती हैं

अगर आपने सॉफ़्टवेयर टीमों या आधुनिक ऑपरेशंस की सोच के आसपास कुछ समय बिताया है, तो आप शायद Scrum से मिल चुके होंगे — वह फ़्रेमवर्क जो काम को दो हफ़्ते के तय स्प्रिंट में बाँटता है, जिसमें प्लानिंग सेशन, रेट्रोस्पेक्टिव, और Scrum Master व Product Owner जैसी तय भूमिकाएँ होती हैं। कई टीमें Scrum और कनबन को एक-दूसरे की प्रतिद्वंद्वी पद्धतियाँ मानकर सोचती हैं कि उन्हें एक चुनना ही होगा। असल में फ़र्क इससे कहीं सरल है।

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

फिर भी, कई टीमें दोनों को मिलाकर इस्तेमाल करती हैं। वे प्रोडक्ट डेवलपमेंट के लिए स्प्रिंट-शैली के प्लानिंग चक्र अपनाती हैं, और ऑपरेशनल व सपोर्ट के उस काम के लिए कनबन बोर्ड चलाती हैं जो इस बात की परवाह किए बिना आता रहता है कि आप किस स्प्रिंट में हैं। यह एकदम सही हाइब्रिड तरीका है।

वे तीन सवाल जिनका जवाब आपका बोर्ड तीस सेकंड में दे देना चाहिए

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

अगर बोर्ड देखने के तीस सेकंड के भीतर आप तीनों सवालों के जवाब नहीं दे पाते, तो शायद बोर्ड को ठीक से अपडेट नहीं रखा जा रहा। सबसे आम गड़बड़ी वह बोर्ड है जहाँ टास्क बनते तो हैं पर कभी आगे नहीं बढ़ते — वह असली काम का जीता-जागता नक्शा बनने के बजाय नेक इरादों का कब्रिस्तान बन जाता है। जो बोर्ड अप-टू-डेट नहीं है, वह बिना बोर्ड के होने से भी बुरा है, क्योंकि वह दृश्यता का झूठा एहसास पैदा करता है।

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

कनबन क्या नहीं करता

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

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

जो यह ज़रूर करेगा, वह है उस अनिश्चितता को घटाना जो ज़्यादातर टीमों की रफ़्तार धीमी करती है। "कौन किस पर काम कर रहा है," "क्या यह हो गया," और "मुझे आगे क्या उठाना चाहिए" जैसे सवाल उन संगठनों में ढेर सारा कम-मूल्य वाला संवाद पैदा करते हैं जिनके पास कोई साझा, दिखाई देने वाला सिस्टम नहीं है। कनबन इस शोर का ज़्यादातर हिस्सा ख़त्म कर देता है। और जिन टीमों में यही शोर सबसे बड़ी समस्या है, उनके लिए फ़र्क बहुत बड़ा होता है।

शुरुआत कैसे करें — तीन दिन की वर्कशॉप के बिना

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

अपनी टीम से वहीं से शुरू करें जहाँ वह असल में है, उसी काम के साथ जो आपके पास असल में है। तीन कॉलम बनाएँ: बैकलॉग, प्रगति में, पूरा हुआ। अपनी टीम के साथ तीस मिनट बैठकर हर मौजूदा काम को एक कार्ड पर डालें। एक नियम पर सहमत हों: जब आप कुछ शुरू करें, तो वह बोर्ड पर जाए। जब वह आगे बढ़े, तो आप कार्ड को आगे बढ़ाएँ। दो हफ़्ते तक इसके अलावा कुछ और न करें।

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

लंबी रेस: फ़्लो मेट्रिक्स

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

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

ज़्यादातर छोटी और मझोले आकार की टीमें यहाँ तक कभी नहीं पहुँचतीं। वे कनबन को विज़िबिलिटी के टूल की तरह इस्तेमाल करती हैं — जो अपने आप में कीमती है — और आगे नहीं बढ़तीं। यह ठीक है। लेकिन अगर आप स्टेकहोल्डर्स से यह वादा करना चाहते हैं कि कोई काम कब पूरा होगा, या यह समझना चाहते हैं कि कुछ काम उम्मीद से तीन गुना ज़्यादा समय क्यों लेते हैं, तो ज़रूरत पड़ने पर ये मेट्रिक्स वहाँ मौजूद हैं।