👨🏽‍🚀 ⚱️ 👨🏼‍🔬 असुविधा हमें विकास प्रक्रिया में सुधार करने में कैसे मदद करती है। 🆙 👲🏼 👌

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

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

थोड़ा सा संदर्भ

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

एक नैदानिक उपकरण के रूप में बेचैनी

टीम में समस्याओं को खोजने और पहचानने के लिए, हम एक काफी सरल उपकरण का उपयोग करते हैं - प्रतिभागियों की असुविधा।

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

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

एक समान स्थिति में कैसे कार्य करें:

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

वर्णित एल्गोरिथ्म सरल है, लेकिन बारीकियां पर्याप्त नहीं हैं। आगे, मैं उन सिद्धांतों का वर्णन करूँगा जो हमने इस दृष्टिकोण का उपयोग करके घटाए हैं। ताकि लेख एक संस्मरण में न बदल जाए, मैं केवल प्राप्त परिणाम का वर्णन करूंगा, न कि दर्द की जागरूकता से लेकर उसके उन्मूलन तक की पूरी कहानी।

जिन सिद्धांतों पर हम प्रक्रिया का निर्माण करते हैं

1. हम लगातार फीडबैक लूप बनाते और छोटा करते हैं

बाहरी दुनिया के साथ सभी मानवीय संपर्क प्रतिक्रिया पर निर्मित होते हैं, इसके बिना प्रदर्शन किए गए कार्रवाई की शुद्धता को सत्यापित करना असंभव है। कल्पना कीजिए कि अगर हमारा जीवन चार-चार मीटर की ऊँचाई से कूदने या लाल-गर्म चायदानी को हथियाने में दर्द महसूस नहीं करता तो हमारा जीवन कैसा होगा।

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

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

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

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

इसलिए, बड़ी संख्या में तेज और सूचनात्मक प्रतिक्रिया की उपस्थिति महत्वपूर्ण है।

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

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

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

क्या उल्लेखनीय है, कभी-कभी एक बहुत छोटा परिवर्तन एक कट्टरपंथी सुधार के लिए पर्याप्त होता है।

उदाहरण के लिए, आप ELK में लॉग लिखते हैं। वे संरचित, विश्लेषण, सार्वजनिक रूप से उपलब्ध हैं - सब कुछ ठीक है। लेकिन डिबगिंग के दौरान डेवलपर कितनी बार ड्रॉप करता है? सबसे अधिक संभावना नहीं है।

यदि चेतावनी स्तर और उच्चतर के संदेश सीधे IDE में प्रदर्शित होते हैं, तो सूचना के लिए एक मौका है, उदाहरण के लिए, क्वेरी निष्पादन समय sagging। भले ही वह वर्तमान कार्य से संबंधित न हो। समस्या को पहले नोटिस करने का मौका है, और इसे ठीक करने की लागत कम होगी।

2. कोई भी गतिविधि सार्वजनिक कलाकृतियों को छोड़ देती है

कलाकृतियों को बिल्कुल सार्वजनिक होना चाहिए। और उपयोगी है।

इस सिद्धांत के लिए धन्यवाद, हम बस कारक को कम करते हैं, स्थिति की एकीकृत समझ प्रदान करते हैं, काम (और फकापिम) होशपूर्वक, लगातार निष्कर्ष बना रहे हैं।

कुछ प्रथाएं स्पष्ट हैं और आम तौर पर स्वीकार की जाती हैं: कमिट्स के सूचनात्मक संदेश, कार्यों के साथ कमिट्स का कनेक्शन, हाउ टू टेस्ट का वर्णन, डेफिनेंस की परिभाषा।

कम स्पष्ट बिंदु हैं:

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

3. हम एक दूसरे के ध्यान केंद्रित काम के अधिकार का सम्मान करते हैं

धारा में काम का महत्व और व्यवधान के परिणाम , मेरा मानना है कि पहले से ही ज्ञात हैं। इसलिए, मैं समस्या पर विस्तार से ध्यान नहीं दूंगा, लेकिन तुरंत अपनी प्रथाओं की ओर रुख करूंगा।

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

4. हम मल्टीटास्किंग से बचते हैं

क्योंकि मल्टीटास्किंग काम नहीं करता है । वह केवल थकावट करता है, ध्यान केंद्रित करता है और परिणाम प्राप्त करता है।

क्या अभ्यास मदद करते हैं:

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

5. हम यथासंभव देर से वास्तु निर्णय लेते हैं

यह हमारा पता नहीं है, लेकिन दुबला विनिर्माण के बुनियादी सिद्धांतों में से एक है ।

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

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

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

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

6. कोड किसी भी समय चालू होता है।

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

जब एक टूटना एक असामान्य स्थिति है, और जीवन का एक आदर्श नहीं है, तो इसके कारणों को ढूंढना आसान है। यह आमतौर पर अंतिम प्रतिबद्धता है। इसलिए, जिम्मेदार व्यक्ति समझ में आता है, समाप्त करने के कदम समझ में आते हैं, यह स्पष्ट है जब हम एक स्थिर स्थिति में लौटते हैं।

सिस्टम के संचालन में परिणामी आत्मविश्वास किसी भी समय जारी करने का एक मूल्यवान अवसर प्रदान करता है।

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

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

हम निरंतर प्रदर्शन कैसे बनाए रखें:

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

7. हम एक टीम हैं, विकास समूह नहीं।

"टीम" का क्या अर्थ है:

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

8. हम पूंछ काटते हैं

वर्तमान कार्य की दक्षता और एकाग्रता को अधिकतम करने के लिए, हम पहले से किए गए कार्य से जुड़े "ऋण" को समाप्त करते हैं:

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

अंतिम बिंदु एक अलग स्पष्टीकरण के लायक है।

मेरा मतलब है कि शुरू में छोटे श्रम लागत के साथ "रेंगना" कार्य, लेकिन कई दिनों या हफ्तों तक प्रगति में लटका रहा।

यह क्यों हो सकता है:

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

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

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

उपयोगी समाधान कैसे चुनें

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

लेकिन अभी भी कुछ चेकलिस्ट है। यहाँ यह है:

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

निष्कर्ष

अंत में, आइए दृष्टिकोण की कमजोरियों पर चर्चा करें।

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

मैं आपसे यह भी पूछता हूं, तैयार सिद्धांतों की सूची न लें, वह उपकरण लें जिसके साथ यह बनाया गया था। यहाँ क्यों है:

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

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

असुविधा हमें विकास प्रक्रिया में सुधार करने में कैसे मदद करती है।