कस्टम विकास में "एक ही लक्ष्य"

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

लक्ष्य की परिभाषा

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



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

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

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

* शुद्ध लाभ
* निवेश का रिटर्न = (निवेश पर रिटर्न - निवेश मूल्य) / निवेश मूल्य
* नकदी का प्रवाह

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

यह सब सरल और उचित लगता है, लेकिन सवाल उठता है - निरंतर सुधार की प्रक्रिया शुरू करने के लिए क्या करने की आवश्यकता है?

एलियाहू गोल्डरात संकेतक

वैकल्पिक संकेतकों पर विचार करना प्रस्तावित है:

• राजस्व सृजन दर
• संबंधित पूंजी
• परिचालन व्यय की दर

परिभाषाएं:

राजस्व पीढ़ी दर वह गति है जिसके साथ प्रणाली बिक्री के माध्यम से धन उत्पन्न करती है।
कनेक्टेड पूंजी खरीदी गई वस्तुओं में सिस्टम द्वारा निवेश किए गए सभी पैसे हैं जिन्हें बेचा जा सकता है
ऑपरेटिंग खर्च वे सभी पैसे हैं जो सिस्टम संबंधित पूंजी को राजस्व उत्पादन में बदलने के लिए खर्च करता है।

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

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

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

आश्रित घटनाएँ और सांख्यिकीय विचलन

इससे पहले कि हम आईटी कंपनी के अभ्यास के लिए उपरोक्त सिद्धांत को लागू करने की कोशिश करें और निरंतर सुधार प्रक्रिया के कार्यान्वयन पर व्यावहारिक सलाह विकसित करें, आइए दो और महत्वपूर्ण अवधारणाओं पर विचार करें:

• आश्रित घटनाएँ
• सांख्यिकीय विचलन

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

प्रतिबंधों के सिद्धांत का मुख्य संकेत कहता है: एक श्रृंखला अपने सबसे कमजोर लिंक से अधिक मजबूत नहीं है।

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

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

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

ऐसी स्थिति में सबसे बेवकूफी वाली बात यह होगी कि सिस्टम की गति अंततः उस औसत गति के बराबर होगी जिस पर हमने अपनी घटनाओं को जोड़ दिया है - विकास के चरण। समस्या सांख्यिकीय विचलन है। डिजाइनरों को कभी-कभी सिरदर्द होता है, और कभी-कभी म्यूज उनके विपरीत जाता है। प्रोग्रामर अपेक्षा से अधिक कोड जारी कर सकते हैं, या अचानक छुट्टी पर जा सकते हैं, आदि।

तब क्या होता है? चलो 4 सॉसर लेते हैं - वे उत्पादन के चरणों, सिक्कों का एक गुच्छा और पासा होंगे। सिक्के को एक ढेर से दूसरे में स्थानांतरित किया जाना चाहिए, बारी-बारी से 1, 2, 3, और 4 का दौरा किया। 4. पहले चरण में, हम एक हड्डी फेंकते हैं और ढेर से कई सिक्के पहले तश्तरी में स्थानांतरित करते हैं जैसा कि हमारे पास है। फिर हम हड्डी को एक बार और फेंक देते हैं और पहली तश्तरी से दूसरे में शिफ्ट कर देते हैं क्योंकि इस बार जितने सिक्के गिराए गए थे, लेकिन पहले तश्तरी में हमारे पास इससे ज्यादा नहीं थे। और इतने पर, जब तक कि सिक्के "संसाधित" नहीं हो जाते।

चूंकि सॉसर के बीच सिक्कों की आवाजाही की औसत गति (1 + 2 + 3 + 4 + 5 + 6) / 6 = 3.5 है, इसलिए माना जा सकता है कि 20 पुनरावृत्तियों के लिए हमें 20 * 3.5 - लगभग 70 सिक्के मिलते हैं।

प्रयोग ने एक वास्तविक "राजस्व पीढ़ी दर" दिखाया: 59 सिक्के संसाधित और एक और 10 जुड़े हुए पूंजी में फंस गए (हालांकि उनके पास शुरू से अंत तक जाने का हर मौका था)। इस प्रकार, सिस्टम ने अपेक्षित औसत शक्ति का केवल 84% पर काम किया:



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

इसके अलावा, हमने इस बात पर ध्यान नहीं दिया कि सांख्यिकीय विचलन से उत्पन्न होने वाली संबद्ध पूंजी ने सिस्टम के संचालन के दौरान परिचालन खर्च की गति को बढ़ा दिया, जिसका अर्थ है कि वास्तविक स्थिति और भी खराब है।

निष्कर्ष

अंत में, मैं कई धारणाएं बनाऊंगा जो मैंने अपने लिए बनाई हैं और चर्चा में लाना चाहूंगा।

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

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

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

इन पंक्तियों तक पहुंचने वाले सभी लोगों के लिए, मैं आपके द्वारा किए गए बौद्धिक कार्यों के लिए धन्यवाद कहना चाहता हूं और नए विचारों के लिए अपने दिमाग को व्यापक रखना चाहता हूं। दुनिया तार्किक है, हम केवल आवश्यक शर्तों को सही ढंग से समझ सकते हैं और, एक अपरिहार्य परिणाम के रूप में, वांछित परिणाम प्राप्त कर सकते हैं।