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

अधिकांश टीमें कनबन को अपनाती हैं क्योंकि किसी ने एक ब्लॉग पोस्ट पढ़ी। बुद्धिमान सवाल यह है कि क्या कनबन समस्याएं हल करता है वह वास्तव में आपकी टीम की समस्याएं हैं।

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

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

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

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

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

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

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

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

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

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

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

नियम जो इसे काम करता है: WIP सीमाएं

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

यह प्रतिकूल महसूस करता है। निश्चित रूप से प्रगति में अधिक कार्य डालने में सक्षम होना अधिक हो रहा है? यह नहीं है। जो वास्तव में होता है जब लोग बहुत सी चीजों पर एक साथ काम करते हैं, तो सब कुछ अधिक समय लेता है। संदर्भ स्विच करना महंगा है। अधूरा काम समन्वय ओवरहेड बनाता है। और जब दस चीजें "प्रगति में" हैं, तो यह बताना बहुत कठिन है कि कौन सी वास्तव में चल रही हैं और कौन सी सिर्फ फंसी हुई हैं लेकिन चिह्नित नहीं हैं।

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

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

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

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

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

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

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

यदि आप बोर्ड को देखने के तीस सेकंड के भीतर तीनों का उत्तर नहीं दे सकते, तो यह शायद ठीक से बनाए नहीं जा रहा है। सबसे आम विफलता मोड एक बोर्ड है जहां कार्य बनाए जाते हैं लेकिन कभी नहीं चले — यह अच्छे इरादों का एक कब्रिस्तान बन जाता है बजाय वास्तविक काम का एक जीवंत नक्शा। एक बोर्ड जो वर्तमान नहीं है बोर्ड के बिना बेहतर है, क्योंकि यह दृश्यमानता का एक गलत अर्थ बनाता है।

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

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

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

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

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

कैसे शुरू करें — तीन दिन की कार्यशाला के बिना

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

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

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

लंबा खेल: प्रवाह मेट्रिक्स

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

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

अधिकांश छोटी और मध्य-आकार की टीमें कभी यहां नहीं पहुंचती हैं। वे कनबन को एक दृश्यमानता उपकरण के रूप में उपयोग करते हैं — जो अपने आप में मूल्यवान है — और आगे नहीं जाते। यह ठीक है। लेकिन यदि आप अपने आप को हितधारकों को प्रतिबद्धताओं के बारे में बनाने के लिए चाहते हैं कि कब कुछ किया जाएगा, या यह समझना चाहते हैं कि कुछ काम अपेक्षित से तीन गुना अधिक क्यों लेता है, मेट्रिक्स वहां हैं जब आपको इनकी आवश्यकता हो।