हमें बोतल कहां से मिली?

फ़्लोकोन, या बोतल - प्रबंधन तकनीक, कार्यों सहित। धारा, परियोजना, विकास, नियमित कार्य, आदि।

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

सबसे अच्छा, यह मुझे एक कहानी के रूप में प्रस्तुत करने के लिए लगता है, क्योंकि बोतल का जन्म मेरे कैरियर के साथ निकटता से जुड़ा हुआ है, इसलिए बोलने के लिए। मैं ऐसा करूंगा। पीछा किया।

PMBOK

पहली परियोजना और कार्य प्रबंधन तकनीक जो मुझे पता था कि PMBOK कहा जाता था। यह दूर का वर्ष 2006 था।

उन दिनों, PMBOK परियोजना प्रबंधन में लगभग एकाधिकार था। रिज्यूमे और रिक्तियों में, यह केवल सुना गया कि PMBOK। तब हवा पर कोई लचीली पद्धति नहीं थी, हालांकि वे पहले से ही कहीं मौजूद थे।

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

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

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

पीला किनारा

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

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

कुछ के साथ शुरू करने के लिए स्टार्टर किट के रूप में कार्य करता है। एक प्रोग्रामर गोदाम के प्रमुख के पास आता है, या स्टोर कीपर, या सामग्री लेखाकार, उनसे बात करना शुरू करता है, और यह पता चला है ... खैर, यह जानने के लिए बहुत कुछ है कि नोटबुक भयानक ताकत के साथ समाप्त हुई।

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

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

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

CORE पी.एम.

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

सार PMBOK की तरह ही है। योजना के प्रतिलोम को मुख्य कहा जाता है। प्रत्यक्ष रूप से अलग, बड़ी, जटिल और नौकरशाही प्रक्रिया का आविष्कार किया गया था, योजना में बदलाव कैसे करें।

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

स्मार्ट चाचा

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

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

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

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

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

जब मैंने इस आंकड़े की गणना की, तो वे सदमे में थे। और इस तथ्य से कि उन्होंने आखिरकार इस आंकड़े को देखा, और यह कितना भयानक निकला। उन्होंने कुछ और हिस्सों और मशीनों की गिनती करने के लिए कहा - लेकिन मेरे बारे में क्या?

तब उत्पादन की गुणवत्ता में मौलिक सुधार लाने के लिए मेरी उपस्थिति के दौरान एक साधारण प्रयास सहित कई दिलचस्प चीजें थीं। लेकिन वह बात नहीं है।

एक महत्वपूर्ण विचार मेरे पास तब आया: स्मार्ट चाचा बहुत कुछ जानते हैं, लेकिन एक बहुत बुरा काम नहीं करते ।

विधियाँ पूर्ण हैं - दोनों गुणवत्ता प्रबंधन में, और कार्य / परियोजना प्रबंधन में, और सामान्य प्रबंधन में। किसी भी प्रभावी प्रबंधक से पूछें - मैं आपको इस तरह के और इस तरह की तकनीक के अनुसार कैसे और क्या करना है, इस पर व्याख्यान दूंगा। और संक्षेप में पूछें - क्या वह वही करता है जो कार्यप्रणाली में लिखा गया है? वहां अंजीर।

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

रूसी प्रबंधन मॉडल

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

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

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

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

दूसरा - रूसी लोग तथाकथित में सबसे अच्छा काम करते हैं क्लस्टर सेल यानी। छोटी टीमों को बहुत अधिक नियंत्रित नहीं किया गया। खुली जगह हमारे लिए नहीं है। जैसा कि आप समझते हैं, एक ही सिद्धांत को एक घोटाले में रखा गया है।

तीसरा, रूसी लोग एक लानत की बात नहीं करते हैं जैसा कि उन्हें बताया गया है। किसी भी कार्यप्रणाली को लागू करते समय यह एक महत्वपूर्ण विचार है। आप निर्देश देते हैं कि कैसे कार्य करें, लोगों को रिहा करें और परिणाम की प्रतीक्षा करें, लेकिन ऐसा नहीं है। क्योंकि लोग आपके निर्देशों को फेंक देते हैं और जैसा वे करते थे वैसा ही करते हैं।

इस पुस्तक के बाद की बोतल अविश्वसनीय रूप से समृद्ध है। सच है, इन "रूसी" समस्याओं को हल करने के तरीकों को अपने दम पर मांगा जाना था। मैंने नियंत्रण पाया।

को नियंत्रित करना

नियंत्रण एक संख्या-आधारित नियंत्रण है। मेरी पसंदीदा तकनीकों में से एक। मैं मुख्य बात पर जोर देता हूं: नियंत्रण नियंत्रण नहीं है। यह प्रबंधन है।

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

नियंत्रण का वह हिस्सा जो सूचना आवश्यकताओं को तैयार करता है, अर्थात्। संख्या, उन्हें प्राप्त करने के तरीके, प्रतिलिपि प्रस्तुत करने की गुणवत्ता, गुणवत्ता, अध्ययन की गहराई, आदि।

आंकड़ा उच्च गुणवत्ता वाला होना चाहिए, लेकिन आप शायद ही कभी ऐसे देखें। मैंने पहले ही इस बारे में कई लेख लिखे हैं, मैं खुद को नहीं दोहराऊंगा। बस इसके लिए मेरा शब्द लें - आप मानदंड को बहुत बार नियंत्रित करके बहुत उच्च गुणवत्ता वाले आंकड़े नहीं पाएंगे। शायद इसलिए कि किसी ने विकिपीडिया पर नियंत्रण लेख नहीं पढ़ा है।

इसलिए, बोतल में नियंत्रण दिखाई दिया। यह सार्वभौमिक है, और इसलिए किसी भी तकनीक द्वारा आवश्यक किसी भी संख्या के गठन को नियंत्रित किया गया है।

सीमा प्रबंधन

सीमा प्रबंधन, या सीमा प्रबंधन, व्यापार प्रणालियों को बदलने के बारे में एक अल्पज्ञात विज्ञान है। हालांकि, हो सकता है, अब कुछ पहले से बदल गया हो - मैंने कई साल पहले इसका अध्ययन किया था, एरिक ट्रिस्ट और किसी और के कार्यों के बारे में लेखों के अनुसार, मुझे अंतिम नाम याद नहीं है। अब इंटरनेट कहता है कि इस विषय पर किसी प्रकार की अंग्रेजी भाषा की पुस्तक है - मैं कुछ नहीं कह सकता, मैंने इसे पढ़ा नहीं है।

नीचे की रेखा बिलकुल सरल है: सीमाएँ । व्यापार प्रणालियों के अंदर, प्रक्रियाएं, यहां तक ​​कि एक व्यक्ति में - बहुत सी सीमाएं। शारीरिक, भावनात्मक, ऊर्जा आदि।

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

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

मैं प्रकाशित, आइसबर्ग और तैराकी गलियों की विधि से कुछ लेकर आया हूं।

सीमा प्रबंधन का बोतल पर, और उसके लगभग सभी हिस्सों पर - कार्य जीवन चक्र के प्रबंधन पर, प्राथमिकताओं के संगठन पर, नियमित प्रबंधन पर बहुत मजबूत प्रभाव था।

क्या-क्या-क्या अपने आप नरक

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

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

सबसे पहले, यह पूरी कंपनी के लिए एक प्रणाली थी, और प्रोग्रामरों की एक छोटी टीम के लिए नहीं। दूसरे, सिस्टम ने अपने लक्ष्य को प्राप्त किया - इसने कार्यकारी अनुशासन को पहले अभूतपूर्व ऊंचाइयों तक बढ़ाया।

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

प्रणालीगत सोच

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

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

उदाहरण के लिए, आपने माना कि एक व्यक्ति एक कार्य करता है, और दूसरा उसे पूरा करने का उपक्रम करता है। अच्छा, अच्छा। दूसरा व्यक्ति केवल कार्य नहीं देख सकता है। और अगर वह देखता है, तो वह नहीं पढ़ेगा। और अगर वह पढ़ता है, तो वह कहेगा कि उसने नहीं पढ़ा। या समझ में नहीं आता। या यह उसका काम नहीं है। आदि

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

ये आकस्मिक गुण हैं। वे सट्टा डिज़ाइन के दौरान दिखाई नहीं देते हैं, वे तब दिखाई देते हैं जब सिस्टम काम करना शुरू करता है।

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

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

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

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

समुराई कोडेक्स और बुक ऑफ़ फाइव रिंग्स

सुनने में अजीब लग रहा है, लेकिन ये वो किताबें थीं जिन्होंने बोतल को बोतल बना दिया। अब मैं संक्षेप में बताऊंगा।

जीवन में एक सभ्य समुराई ने ऐसा किया। सबसे पहले मैं किसी गुरु के साथ मार्शल आर्ट का अध्ययन करने गया। उसने तब तक पढ़ाई की जब तक वह उससे आगे नहीं निकल गया। और यहाँ हमारे पास एक सभ्य समुराई है जो एक निश्चित स्कूल (सादृश्य द्वारा - PMBOK) की तकनीक का मालिक है।

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

ऐसा कई बार हुआ। और कुछ निश्चित समय पर, समुराई की अपनी शैली थी।

सामान्य तौर पर, वह हर किसी के लिए पैदा नहीं हुआ था, यह सामान्य है। कुछ "एक चेहरे के बिना" बने रहे, कई प्रसिद्ध स्कूलों (केवल एमबीए के इस प्रकार) के स्वामी होने के नाते।

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

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

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

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

व्यापार प्रोग्रामिंग

व्यवसाय प्रोग्रामिंग व्यवसाय में सुधार के लिए सरल तरीकों और प्रथाओं का एक समूह है। कम से कम पूरे, कम से कम एक निश्चित भाग।

ऐसा हुआ कि व्यावसायिक प्रोग्रामिंग बोतल के समानांतर विकसित हुई, और मूल आईटी विभाग को छोड़कर, सुधार की वस्तु सब कुछ थी।

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

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

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

जमघट

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

सही स्क्रैम कहता है: कार्य को 4 गुना तेज करना संभव और आवश्यक है। गलत कुछ भी नहीं कहता, बस आपको कुछ नियम देता है।

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

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

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

लेकिन सबसे अच्छा बोतल में छोड़ दिया गया था। घोटाले में सबसे अच्छा क्या है? यह सही है, कार्य माप प्रणाली पोकर योजना है। हमारी दुनिया में प्रोग्रामर के कार्यों के मूल्यांकन के लिए अधिक सभ्य कुछ भी नहीं है।

पहले इस्तेमाल की गई घड़ी प्रणाली बहुत खराब है, क्योंकि मुद्रास्फीति या अनुमानों का अपस्फीति लगातार उत्पन्न होती है। अंक बहुत अधिक स्थिर हैं।

बोतल में शेष स्क्रैम तत्वों में से, शायद, केवल एक स्प्रिंट बने रहे, योजना विकल्पों में से एक के रूप में। जिसने भी 1 सी के साथ काम किया है वह जानता है कि स्प्रिंट सबसे आम अंतरिक्ष-कैलेंडर योजना है, अर्थात। एक निश्चित अवधि के लिए एक निश्चित मात्रा में उत्पादों को बेचा / खरीदा / उत्पादित किया जाना चाहिए।

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

स्ट्रीम घोटाले

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

समस्याग्रस्त इकाइयों में से एक आपूर्ति थी। मुझे अभी भी समझ में नहीं आया कि यह इतना कठिन क्यों है - कार्य सरल है। तब मुझे स्क्रैम में दिलचस्पी थी, और इसे खरीद के लिए इस्तेमाल करने का फैसला किया।

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

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

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

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

एक झरना क्या है? यह एक धारा है। तो प्रवाह का विचार प्रकट हुआ। धन्यवाद, व्लादिमीर व्लादिमीरोविच।

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

बात सरल है।आपूर्तिकर्ता के लिए कार्य हमेशा बाहर से आते हैं - बिक्री और उत्पादन की जरूरतों से। इन कार्यों के लिए प्राथमिकता प्रणाली बहुत सरल है। और काम का सार और भी सरल है - बाड़ से दोपहर के भोजन तक।

झाड़ियों की आवश्यकता है - ऑर्डर झाड़ियों। हमें बोल्ट की आवश्यकता है - ठीक है, आप जानते हैं कि क्या करना है। और इसी तरह अनंत को। क्योंकि प्रवाह।

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

परिणाम गुणवत्ता और उपलब्धि की गति में डगमगा रहा था - एक महीने में उन्होंने "सामान्य" प्रबंधन के वर्षों के दौरान खेप गोदाम को पहले अप्राप्य स्तर तक भर दिया।

खैर, यहाँ, कुछ बिंदु पर, यह मुझ पर हावी हो गया कि आंतरिक स्वचालन पर कोई परियोजनाएं नहीं हैं, लेकिन एक धारा है। परियोजनाओं में आंतरिक स्वचालन का टूटना एक सम्मेलन है जो PMBOK के लिए 1Snikov के महान प्रेम की विरासत के रूप में आया है। परियोजनाओं की जरूरत होती है जहां पैसा, समय, बजट, औपचारिकताएं और नौकरशाही होती है। यदि यह सब आंतरिक स्वचालन में है, तो स्पष्ट रूप से कुछ किया जाना चाहिए।

सामान्य तौर पर, धाराएँ और उनके प्रबंधन ने दृढ़ता से बोतल में प्रवेश किया। आगे देखते हुए, मैं कहता हूँ कि फ़्लोकोन नाम वाक्यांश प्रवाह नियंत्रण से लिया गया है।

सिस्टम की कमी का सिद्धांत (CBT)

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

बेशक, मुख्य सिद्धांत सीबीटी से बोतल में मिला - प्रतिबंधों के अस्तित्व को समझने, और इसके साथ काम करने के साधन। मैं सचेत रूप से "प्रतिबंध हटाने" नहीं लिख रहा हूँ, क्योंकि सीबीटी में न केवल उन्मूलन, बल्कि प्रतिबंधों का संरक्षण, और कभी-कभी उनका कृत्रिम निर्माण भी शामिल है।

यह टीओसी था जिसने मुझे न केवल कार्य के चरण में देखा, बल्कि "किट" पर भी - प्रत्यक्ष निष्पादक के काम से पहले और बाद में क्या हुआ। यह कोई रहस्य नहीं है कि अक्सर किसी कार्य को पूरा करने में 15 मिनट लगते हैं, और परिणाम को स्वीकार करने, समन्वय करने, स्वीकार करने में कुछ दिन लगते हैं। और ये सभी कुछ दिन, ग्राहक, या कार्य के आरंभकर्ता, प्रतीक्षा कर रहे हैं।

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

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

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

दिग्गजों के कंधों पर खड़ा है

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

मैं केवल एक महत्वपूर्ण उद्धरण दूंगा।

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

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

टिप्पणियों

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

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

जैसा कि जेडी तकनीक के लेखक मैक्सिम डोरोफीव ने एक मजाकिया चित्र में लिखा है, * ओपू के माध्यम से समय सीमा समाप्त होने की प्रतीक्षा करने का क्या मतलब है, अगर आप तुरंत * ओप्यू के माध्यम से कर सकते हैं, लेकिन क्या सब कुछ ठीक करने का समय होगा?

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

ऐसे कई उदाहरण हैं, और उन सभी ने बोतल को प्रभावित किया है। और वे प्रभावित करना जारी रखते हैं, क्योंकि एक बार यह समझने के बाद कि मेरी खुद की टिप्पणियां किताबों से बदतर नहीं हैं, मैं अब नहीं रुक सकता - पूर्णता की कोई सीमा नहीं है।

बेरहम स्वचालन

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

दरअसल, इस अनुभव ने मुझे एक तकनीक के रूप में बोतल को वितरित करने के लिए प्रेरित किया। मैंने जानकारी और विधियों को व्यवस्थित करना शुरू कर दिया, बोतल और उसके तरीकों के बारे में लेख लिखे और अपने अभ्यास के बारे में बात की।

नई व्यवस्था की व्यवस्था

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

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

लेकिन मुझे लंबे समय तक इस प्रणाली के साथ काम नहीं करना पड़ा, क्योंकि हमारी कंपनी ने GitHub के माध्यम से ग्राहकों के साथ संवाद किया। यदि आप जानते हैं, तो कुछ प्रकार का कार्य प्रबंधन भी है जिसे समस्याएँ कहा जाता है।

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

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

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

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

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

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

एक और नई प्रणाली का स्थानांतरण

तब मुझे याद आया कि दुनिया में 1 सी है, और 1 सी: वर्कफ़्लो जैसे शानदार उत्पाद। यदि किसी को नहीं पता है, तो यह एक ऐसा कार्यक्रम है जिसमें आप किसी भी प्रक्रिया को कॉन्फ़िगर कर सकते हैं। तदनुसार, इसमें कोई भी कार्यप्रणाली शामिल नहीं है, केवल एक तकनीक है, और किसी को इसे एक तकनीक बताना चाहिए।

यहां, बस, लोग अगले 1Snu सम्मेलन में जा रहे थे, और मैंने वहां भाग लेने का फैसला किया। मैंने एक मानक लिया, खाली 1 सी: दस्तावेज़ प्रवाह, और उसमें अपनी खुद की कार्यप्रणाली स्थापित करना शुरू किया - एक बोतल। सम्मान और प्रशंसा 1C: दस्तावेज़ प्रबंधन - इसे स्थापित करने में कई घंटे लग गए, और हमें एक सुंदर सभ्य कार्य प्रबंधन प्रणाली मिली जो अत्यधिक बोतल से मेल खाती है।

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

परिणाम अभी भी सकारात्मक है। उन्होंने गीथहब में कार्यों के उपयोग के साथ मिलकर दिखाया कि बोतल को अन्य प्रणालियों में पूरी तरह से एकीकृत किया जा सकता है। इसलिए हमने अपने सिस्टम पर टीमों को तेज करने के लिए परामर्श और कई परियोजनाएं प्राप्त कीं।

खुद की व्यवस्था

परामर्श, ज़ाहिर है, मज़ेदार है, लेकिन लंबी और महंगी है। अधिकांश लोग अपने पुराने कार्य प्रबंधन प्रणाली को फेंकने के लिए बहुत खेद नहीं करते हैं, जो कि कम उपयोग का है। खैर, लोग दो में एक चाहते हैं - और कार्यप्रणाली, और कार्यक्रम, जिसमें "सब कुछ पद्धति के अनुसार है।"

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

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

और फिर से बहता है

मैंने पहले कभी कोई कंपनी नहीं चलाई। वास्तव में, मैं अभी भी यह नहीं कह सकता कि मैं प्रभारी हूं - यहां हम में से दो हैं, और अधिकारों और जिम्मेदारियों को लगभग आधे में विभाजित किया गया है। लेकिन हमें कंपनी के जीवन के सभी मुद्दों से निपटना है, न कि केवल विकास या कार्यान्वयन।

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

मामलों की इस स्थिति ने हमें बोतल पर पुनर्विचार किया और इसमें दो नई इकाइयां शुरू कीं - प्रवाह और संतुलन।

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

मैं एक नया उत्पाद विकसित करने के लिए, उदाहरण के लिए, एक सप्ताह के लिए बाहर नहीं बैठना चाहूंगा। क्या होगा? कोई पैसा नहीं होगा, क्योंकि शैतान नए उत्पाद को जानता है जब वह बेचना शुरू करता है। हमें ग्राहकों के साथ काम करना चाहिए।

यदि आप ग्राहकों के साथ काम करना शुरू करते हैं, तो एक पतन भी होगा, क्योंकि उसी सेवाओं पर व्यवसाय बनाना काफी जोखिम भरा है।

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

ऐसे प्रवाह हैं जिन्हें मापा और नियोजित किया जा सकता है। उदाहरण के लिए, महीने में 100 घंटे - सेवाओं के लिए, 300 अंक - नए उत्पादों के विकास के लिए, और बीच में - 4 लेख। प्रत्येक धारा की अपनी इकाई और माप की विधि है, और इसका अपना लक्ष्य है। और बोतल को कंपनी के समान विकास को सुनिश्चित करते हुए, इन प्रवाह को संतुलित करना चाहिए।

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

इसलिए बोतल एक कार्य प्रबंधन तकनीक से कंपनी प्रबंधन तकनीक में विकसित हुई है। खैर, यह पहले से ही सीधा नहीं है - यह प्रक्रिया अभी भी जारी है, लेकिन परिणाम प्रभावशाली हैं।

विकास प्रबंधन

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

जब हमें कोई समस्या होती है, तो अंतराल दिखाई देता है - हम बहुत जल्दी और जल्दी से काम करते हैं, और उत्पाद बाजार में प्रवेश नहीं करते हैं। जैसा कि वे घबराहट के बारे में चुटकुले में कहते हैं, यह समझना बाकी है कि हम किस तरह की बकवास कर रहे हैं।

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

और कौन भूल गया?

मुझे लगता है कि यह गोल करने का समय है। यदि आप इस जगह पर पढ़ते हैं, तो आपके पास बहुत सम्मान है। मैंने अभी तक बहुत कुछ नहीं लिखा है, लेकिन मुख्य बात, जैसे, इस सामग्री में परिलक्षित हुई थी।

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

हां, उन तरीकों के प्रिय लेखक, जिनसे मैंने बोतल के लिए कुछ उपयोगी लिया था, लेकिन इस लेख में उल्लेख नहीं किया है, इसके लिए मैं माफी चाहता हूं।

परिणाम क्या है?

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

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

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

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

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

तो, सब ठीक हो जाएगा।