इंजीनियर से नेता तक। भाग 2: प्रत्यायोजन और समस्या सेटिंग

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

मैत्री जादू है!

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

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

- हाय, आप कैसे हैं?
- ठीक है, मैं समझता हूं। मैं कैसे लिखूं? कोई घटनाक्रम? क्या मैं मॉडल में कुछ जोड़ सकता हूं?

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

sint16_t Temperature = nInTemp; bool_t Sign = TRUE; Sign = Temperature >> 15; if (Sign = TRUE) // do something // and do a little bit more else if (Sign == FALSE) { // do something } 

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

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

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

लक्ष्य निर्धारण

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

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

तकनीकी विनिर्देश

सबसे अच्छा विचार निम्नलिखित विनिर्देश से एक विनिर्देश बनाने के लिए है:

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

अच्छा विनिर्देश :

 11. RAM Functionality [Requirement ID 111] [Actual Baseline 1 \ Iteration 8] [Parent requirement 11] The functionality of the RAM devices shall be tested by a write / read test of at least all used memory locations. [Requirement ID 112] [Actual Baseline 1 \ Iteration 8] [Parent requirement 11] In case of detecting a RAM fault, the unit shall be halted. 

यानी हम वास्तुकला में अपने विनिर्देश की जगह को समझ सकते हैं और हमारे पास दो कार्यों के लिए दो परीक्षणों द्वारा कवर की जाने वाली क्रियाओं का एक सेट है (स्क्रिप्ट निष्पादित करें):

1. त्रुटि के बिना मामला
2. त्रुटि का मामला

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

खराब विनिर्देशन :

 Fault machine [Requirement 31] [Actual Baseline 1 \ Iteration 8] [Parent requirement: 3, 5, 7, 8, 9, datasheet 23 page 5] System shall catch and store all errors in None-Volatile Memory. Errors shall be stored as follows: 1. Set IE to OFF; 2. Write Date; 3. Write Time; 4. Write Error ID; 5. Write '\0'; 6. Set IE to ON; 

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

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

कार्य सेटिंग

ठीक है, अगर तकनीकी विनिर्देश कोड के करीब है, तो कार्यों की स्थापना के बारे में क्या?

बुरा काम :

 Create input monitoring functionality urgently. 

एक अच्छे उदाहरण में कार्यों का क्रम होना चाहिए या पूरी तरह से एक रोडमैप द्वारा वर्णित किया जाना चाहिए:

 Try to integrate last application release (from SVN) till Friday 13 in the following way: 1) Build new framework 2) Build new application with the new framework 3) Run tests 4) Run all benchmarks 5) Report to Jira If one of the steps breaks, try to re-check its default settings, and if all is correct, then report status. 

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



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

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

रिपोर्ट के लाभ और उनकी आवश्यकता क्यों होती है, इस पर अगली बार चर्चा की गई।