व्यवस्था प्रबंधन

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

"कैप्टन एविडेंस" व्यवस्था लागू नहीं की जा रही है

उनके साथ दर्द, पहली जगह में, समझौते पूरे नहीं हुए हैं - हर कोई यह जानता है, यहां तक ​​कि हमारे दोस्त, कैप्टन साक्ष्य, जो इस लेख में हमारी मदद करेंगे।

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

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


स्पीकर के बारे में: स्टास मिखाल्स्की 1998 से वेब विकास में लगे हुए हैं। वह बिग जूनियर में एक जूनियर पर्ल प्रोग्रामर से विकास के निदेशक के पास गए। उन्होंने उच्च उपस्थिति के साथ कई दर्जन परियोजनाओं के विकास में भाग लिया और अपना समर्थन प्रदान किया।

यह समस्या क्यों है?

हमारी टीम से और व्यवसाय और नेतृत्व, टीम के नेताओं के रूप में, परिणाम की प्रतीक्षा कर रहे हैं। किसी कार्य को समय पर पूरा करने से परिणाम नहीं मिल सकता है, लेकिन यह एक अलग कहानी है।

काम और परिणाम दो अलग-अलग चीजें हैं, लेकिन इस दूसरी बार के बारे में बात करते हैं।

परिणाम कार्य का परिणाम है - कार्यों, परियोजनाओं, उपप्रोजेक्टों का पूरा होना। विभिन्न विभाजन संभव हैं, लेकिन एक तरह से या किसी अन्य, कार्य में कुछ क्रियाएं शामिल हैं, जिनमें से प्रत्येक वास्तव में एक समझौते का परिणाम है।

ऐसा लगता है - सब कुछ स्पष्ट है: जब हम कार्रवाई नहीं करते हैं, तो हम समझौतों को तोड़ते हैं।

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

- अगर हमने खुद तय किया कि वे हमसे यह उम्मीद करते हैं - क्या यह एक समझौता है?
- हां, खुद के साथ एक समझौता, लेकिन यह एक विशेष मामला है।

अब सबसे दिलचस्प बात वास्तव में विपरीत है: एक असफल समझौता = विफल कार्रवाई।

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

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

इसके विपरीत, यदि हम सीखें कि सही व्यवस्था कैसे बनाई जाए, तो:

• बहुत समय बचाओ;
• सभी नियंत्रण, disassemblies, आदि के लिए ओवरहेड को काफी कम करें;
• हम वास्तव में अपना काम कर सकते हैं।

क्या करें?

"सुनिश्चित करें कि व्यवस्थाएँ लागू हैं"

कप्तान साक्ष्य

यह सभी के लिए स्पष्ट है, यहां तक ​​कि साक्ष्य के कप्तान, आपको बस यह सुनिश्चित करने की आवश्यकता है कि समझौतों को लागू किया जाए, और आपको ऐसा करने की आवश्यकता नहीं है ताकि वे कार्यान्वित न हों।

यह कैसे प्राप्त किया जा सकता है इसका क्लासिक मॉडल:

1. कारणों को समझें।
   
2. इन कारणों को दूर करने के लिए पहचानें और कार्रवाई करें और परिणाम बदलें।
   

आइए थोड़ा और विस्तार से बात करते हैं। तीन अभिनेता हैं:

1. से निपटने के लिए एक व्यवस्था ।
   
2. व्यवधान जो एक व्यवस्था के लिए होता है।
   
3. असफलता के कारण।
   

यदि आप सभी तरफ से यह सब देखते हैं, तो आप शायद समझ सकते हैं कि समस्या क्या है और स्थिति को कैसे सुधारें। मुझे उम्मीद है कि स्थिति में हस्तक्षेप की आवश्यकता है, हर कोई इससे सहमत है।

एक व्यवस्था क्या है?

व्यवस्था में दो भाग होते हैं: प्रतिबद्धता और वादा। उनके बीच का अंतर यह है कि एक प्रतिबद्धता बनती है, एक वादा किया जाता है ।

एक वादा एक अपमान है, यह किसी के लिए एक संदेश है कि मैंने एक प्रतिबद्धता बनाई है। सिद्धांत रूप में, यह भी नहीं दिया जा सकता है, क्योंकि यह सिर्फ एक अधिसूचना संदेश है। लेकिन मैं यह दायित्व निभाता हूं। इसलिए, एक वादा के बिना एक प्रतिबद्धता एक प्रतिबद्धता के बिना एक वादा से बेहतर है। हम उत्तरार्द्ध का सामना अक्सर करते हैं।

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

वास्तव में, यह अभी भी बहुत अधिक जटिल है, क्योंकि व्यवस्था प्रकार में भिन्न हैं:

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

ये पूरी तरह से अलग समझौते हैं, लोग उनके साथ अलग तरह से व्यवहार करते हैं, और आपको उनके साथ पूरी तरह से अलग तरीके से काम करने की जरूरत है।

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

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

इसलिए, यह समझना बहुत महत्वपूर्ण है कि हम किस तरह के समझौते के बारे में बात कर रहे हैं। विस्तार की डिग्री इस बात पर निर्भर करती है कि हम किस प्रकार के समझौते को समाप्त करने की कोशिश कर रहे हैं।

अवरोधों

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

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

व्यवधान भी अलग हैं।

असफलता मेरी पसंदीदा, सबसे ईमानदार और सबसे हानिरहित तरह की विफलता है। हम सहमत थे, व्यक्ति ने वादा किया था और नहीं किया - ऐसा होता है। यह एक साधारण ब्रेकडाउन है, क्योंकि उसके साथ सब कुछ स्पष्ट है।

अधिक अप्रिय विकल्प हैं, जैसे औपचारिक निष्पादन।

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

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

फॉर्म के औपचारिक कार्यान्वयन से प्रतिस्थापन थोड़ा अलग है, लेकिन वास्तव में यह समझौते का उल्लंघन करने का एक ही प्रयास है। पूर्ण कार्य की दृश्यता के बजाय, एक प्रतिस्थापन बनाया जाता है। समय लॉगिंग के उदाहरण का उपयोग करते हुए, यह कुछ इस तरह लगता है: “प्रत्येक कार्य के समय को रिकॉर्ड करने के लिए, मुझे 5 मिनट चाहिए। कुल मिलाकर, यह सप्ताह में दो घंटे है। अरे अच्छा है उसका। मैंने एक ऐसा काम किया है जिसका इरादा 4 घंटे में नहीं था। लेकिन मैंने जितना वादा किया था, उससे अधिक किया और न ही मैंने समय नहीं दिया।

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

मैं दोहराता हूं: एक उत्कृष्ट समझौता एक माइनस काम है, जिसके परिणामस्वरूप माइनस है।

कैसे अधूरी व्यवस्था की दुनिया में जीवित रहने के लिए?

आप बस याद दिला सकते हैं: "क्या आपको याद है कि हम घड़ी लॉग करते हैं?"। जब बदलते व्यवहार की बात आती है, तो एक अनुस्मारक एक अच्छी रूपरेखा है। व्यवहार मॉडल का समर्थन करने वाले सबसे चालाक हैंग पोस्टर हैं: "प्रतिज्ञा समय - बीवर को बचाया!"। वास्तव में, हम आपको केवल यह याद दिलाते हैं कि इस समय इसकी स्थिति की जाँच किए बिना, एक समझौता हुआ था।

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

आप देख सकते हैं :

• परिणाम से;
• कदम से कदम;
• गतिकी पर।

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

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

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

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

नियंत्रण करने के बजाय, आइए बेहतर समझें कि वास्तव में ब्रेकडाउन क्यों होता है - क्यों जिसने हमसे वादा किया था, उसे पूरा नहीं किया।

टूटने का कारण

यह शायद एक अधूरी सूची है, लेकिन यहां सबसे महत्वपूर्ण उदाहरण हैं:

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

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

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

1. व्यवस्था के प्रकार को ध्यान में नहीं रखा गया।
   
2. व्यवस्था का प्रकार सहमत नहीं है।
   
3. दायित्व के बिना एक वादा।
   

इसके अलावा, पहला और दूसरा पैराग्राफ दोनों एक ही बार में मौजूद हो सकता है। जब हम कोई समझौता करते हैं, तो हम इस बारे में नहीं सोचते हैं कि हम क्या सहमत हैं। अक्सर ऐसा लगता है:

- aegeus, ऐसा करो!
- ठीक है, मैं कर लूंगा! - और भाग गए।

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

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

व्यवस्था के प्रकार की समझ का संघर्ष हमेशा सामने नहीं आता है। हम अक्सर मानते हैं कि इस समझौते को स्पष्ट, प्रबलित करने की आवश्यकता नहीं है, क्योंकि सब कुछ पहले से ही स्पष्ट है: बस इसे लें और इसे करें। अधीनस्थ का मानना ​​है कि वह उससे ऊपर से चाहते हैं जो वह नहीं करना चाहता है। और फिर तोड़फोड़ शुरू हो जाती है ।

सबसे लोकप्रिय स्थिति, जैसा कि मैंने कहा, दायित्वों के बिना एक वादा है। एक समझौता जिसने एक वादे को जन्म दिया, लेकिन एक दायित्व को जन्म नहीं दिया, एक कारण या किसी अन्य के लिए पूरा नहीं किया जाएगा: पियानो गिर जाएगा, एक व्यक्ति विचलित हो जाएगा, कुछ और होगा।

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

समझौते को पूरा करने का एकमात्र मौका यह है कि एक व्यक्ति इसे पूरा करना चाहता है।

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

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

व्यवस्था के साथ, स्क्रम में स्प्रिंट के साथ भी ऐसा ही होना चाहिए। एक व्यक्ति जो कुछ करने के लिए प्रतिबद्ध है, उसे बस करना है। सब कुछ सरल है!

संक्षेप में, समझौते की विफलता के कारणों के बारे में क्या कहा गया था:

• एक वादा कोई गारंटी नहीं है।
• नियंत्रण मुश्किल है।
• तथ्य पर विफलता का पता चलता है।

यह स्पष्ट किया जाना चाहिए कि क्या करना है: बस स्थायी समझौते बनाएं जो प्रबंधन करने में आसान हों और अंत में बहामा में जाएं।

कप्तान साक्ष्य

दूसरे शब्दों में:

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

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

यह पता लगाने के लिए रहता है कि एक मजबूत समझौता क्या है और इसे कैसे प्रबंधित किया जाए।

मजबूत समझौता

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

एक वैकल्पिक व्यक्ति के साथ किए गए इंतजाम से विसंगतियां पैदा होती हैं। यदि आप संकुल द्वारा अलग-अलग दिशाओं में वितरित किए गए समझौतों की एक धारा के रूप में कार्य की कल्पना करते हैं, तो जब आप किसी वैकल्पिक व्यक्ति के साथ एक समझौते का समापन करने का प्रयास करते हैं, तो इस तथ्य के लिए तैयार रहें कि 50% संभावना के साथ आप समय खो देंगे। इसलिए, पहली बात यह है कि एक शब्द की कीमत बढ़ाना है।

शब्द का भाव

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

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

, , . - . , , 10 3. , — .

, .

, — . — , .

, , .

, — : « , ».

— , . , — . , .

— . , .

, , , .

, - — .

« » . , — . , , . , . , - . , , , , :

1. , .
   
2. , .
   

, , . — — , . - . , , , . , . .

, , «» :

• .
• .
• .

— , , , , , .

, . , .

, .

. , , : , , . , , , , . , — , - , . — .

, . — , «» . , — . - , . :

— , !
— .

-: «, , . 10:55. , ».

, , 5 — , , . , : , .

— — , .

?

, : ? 4 , , - :

1. ?
   
2. ?
   
3. , ?
   
4. , ?
   

. , . , .

: «, - , , , !» , , , .

, . . - , , , , .

« » . — . , , — .

« » , - , . , , — . , . , , .

, :

• .
• .
• , , — , .
• « » . , .

, Excel, : , , , . , .

?

, , , . , …

? ? — : — , — , — .

, «» , , . «» — - . « » , « ?» « ?»

…

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