प्रस्तावना

प्रक्रिया प्रबंधकों के रूसी-भाषी पेशेवर समुदाय में, रूसी में कानबन विधि पर बहुत कम साहित्य है। हमने इस अन्याय को ठीक करने का फैसला किया और हम रूसी में अपने दृष्टिकोण से सबसे महत्वपूर्ण लेख प्रकाशित करेंगे, जिसने विधि के विकास को प्रभावित किया।

एक सामूहिक सीखने की प्रक्रिया के रूप में अपनी प्रक्रिया को समझना

और श्रृंखला में पहला लेख कैसे अधिक कुशलता से अपने काम की प्रक्रियाओं का एक दृश्य बनाने के लिए और एक बोर्ड का अनुभव करता है। मूल लेख के लेखक अलेक्सी झेग्लोव हैं और यहां पाया जा सकता है।

काम को एक सामूहिक बनाने की एक सामान्य प्रवृत्ति और इच्छा है। हालाँकि, जब मैं कार्यालय में लोगों से उनके काम की प्रक्रिया खींचने के लिए कहता हूं, तो वे अक्सर ऐसा कुछ प्रदान करते हैं (मैं सरल करता हूं):

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

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

कुछ लोग इस प्रक्रिया को एक बोर्ड पर देखने की कोशिश कर रहे हैं जिसे वे "कंबन" कहते हैं:

फिर वे खुद से पूछते हैं: क्या होगा, उदाहरण के लिए, परीक्षक विश्लेषक या डेवलपर को काम की वस्तु वापस लौटाता है? कार्ड जगह पर रहना चाहिए या चलना चाहिए? क्या होगा यदि हमारे पास WIP सीमा है (ये संख्या कॉलम हेडर में हैं)? क्या होगा यदि यह कॉलम पहले से ही सीमा तक भरा हुआ है, तो दूसरा कार्ड वापस जाना चाहिए?

क्या कोई बेहतर तरीका है?

यह प्रश्न काफी सामान्य है और पेशेवर सेवा कार्य की प्रकृति की गलतफहमी में निहित है। विशेष नौकरियों के बीच प्रसारण की एक श्रृंखला के बजाय, यह मुख्य रूप से जानकारी बनाने और ज्ञान संचय करने के बारे में है। यह एक बाधा बन जाता है जब प्रक्रिया को फ्लोचार्ट की तरह बनाने की कोशिश की जाती है। काम के निष्पादन के बाद, कल्पना करने की कोशिश करने के साथ-साथ एक सीमा भी।

सॉफ़्टवेयर उत्पाद की नई कार्यक्षमता प्रदान करने के उदाहरण में, निम्न ज्ञान बनाया जा सकता है (इस क्रम में आवश्यक नहीं):

काम के माहौल का सटीक विन्यास (ओएस, वेब सर्वर, डेटाबेस सर्वर, थर्ड-पार्टी सॉफ्टवेयर)
विकसित कार्यक्षमता के व्यवहार के प्रमुख उदाहरण, मामलों का उपयोग, स्वीकृति मानदंड, निष्पादन योग्य विनिर्देश आदि।
( , . .)
-
: , , ..
, .

किसी भी पेशेवर सेवा में हर कोई अपने स्वयं के ज्ञान की सूची के साथ आ सकता है जो वे अपनी वितरण प्रक्रिया में बनाते हैं। जब काम पूरा हो जाता है, तो यह सब ज्ञान पहले से ही मौजूद है, लेकिन जब हम ग्राहक की जरूरतों या किसी चीज की आपूर्ति के लिए अनुरोध पर काम करना शुरू कर रहे हैं, तो यह सब गायब है।

यदि हमने इस ज्ञान को संचित करने की प्रक्रिया की कल्पना करने की कोशिश की, तो परिणाम इस तरह दिख सकता है:

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

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

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

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

ध्यान दें कि नई प्रक्रिया आरेख में तीन टिपिंग बिंदु कार्यात्मक विशेषज्ञों या विभागों के बीच स्थानांतरण नहीं हैं। ये प्रमुख गतिविधि में परिवर्तन और अंत: क्रिया के पैटर्न में परिवर्तन हैं।

निष्कर्ष

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

इसके बजाय, हम अपनी वितरण प्रक्रिया को जानकारी प्राप्त करने और ज्ञान बनाने के रूप में देख सकते हैं। अपने आप से सवाल पूछते हुए कि हम जो कार्य करते हैं , उस ज्ञान को संचित करने के लिए हम क्या कार्य करते हैं , जो हम वितरित करते हैं , हम संयुक्त क्रियाओं के अनुक्रम के रूप में अपनी प्रक्रिया की कल्पना कर सकते हैं।

आगे क्या होगा?

सॉफ्टवेयर विकास की दुनिया के बाहर की प्रक्रियाओं के लिए, अगले कुछ लेखों में, मैं ज्ञान संचय की प्रक्रिया के प्रतिबिंब का उदाहरण देना चाहूंगा।

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

अलेक्सी पिमेनोव के लिए बहुत धन्यवाद औरStepev।

कंबन विधि: एक सामूहिक सीखने की प्रक्रिया के रूप में आपकी प्रक्रिया को समझना

प्रस्तावना

एक सामूहिक सीखने की प्रक्रिया के रूप में अपनी प्रक्रिया को समझना

क्या कोई बेहतर तरीका है?

निष्कर्ष

आगे क्या होगा?

More articles: