खुद आओ ... या एक टीम में संचार के नियम

लेख पर प्रतिक्रिया "आओ! @ # अपने" विषाक्तता "के साथ । "

अगर मैंने इस लेख से सलाह का पालन किया, तो मेरे लिए यह काफी होगा कि मैं भावनाएं दिखाऊं और लेखक से कहूं कि "खुद आओ ... तुम्हें कुछ समझ में नहीं आता!"।

हालांकि, यह मेरे विचार को व्यक्त करने में मदद नहीं करेगा। इसलिए, चलो एक करीब देखो।

उद्धरण 1:

यदि कोई व्यक्ति अक्षम है, तो आपको उसे यह स्पष्ट रूप से समझने की जरूरत है, न कि उसकी कोमल भावनाओं को हर किसी की निंदा की रक्षा करने की।

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

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

इसी समय, निश्चित रूप से, कोड में विशिष्ट समस्याओं के बारे में बात करना आवश्यक है।

एक सामान्य व्यक्ति एक तर्कपूर्ण स्थिति पर चर्चा करने के लिए खुश है। और वह शत्रुता नकारात्मक भावनाओं को ले जाएगा। विषाक्त टीम के सदस्य के साथ कौन काम करना चाहेगा?

उद्धरण:

क्या कोई व्यक्ति आपको बार-बार एक ही त्रुटि के साथ एक कोड भेज सकता है और उसे विनम्रता और मुस्कुराहट के साथ जवाब देने की आवश्यकता है?

यदि कोई व्यक्ति बार-बार गलतियाँ करता है और किसी तरह बढ़ने की कोशिश नहीं करता है, तो उसे निकाल दिया जाना चाहिए। इस बारे में टीम लीडर से बात करें। लेकिन हिस्टीरिया वैसे भी आवश्यक नहीं है। ठीक है, सिर्फ इसलिए कि यह मदद नहीं करेगा।

नकारात्मक भावनाएं ही नकारात्मक भावनाओं को जन्म दे सकती हैं। और यह कोड में त्रुटियों को ठीक नहीं करेगा।

उद्धरण 3:

पेशे में जिम्मेदारी जितनी अधिक होगी, तनाव प्रतिरोध भी उतना ही अधिक होना चाहिए।

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

और मैं सभी जिम्मेदारी के साथ घोषणा करना चाहता हूं: कोई भी तनाव पसंद नहीं करता है, भले ही वह इसे झेलने में सक्षम हो। हर कोई हमेशा तनाव कम करने की कोशिश करता है।

उदाहरण के लिए:

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

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

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

उद्धरण:

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

खैर हाँ, यह है। "आपका कोड खराब है" एक व्यर्थ वाक्यांश है, यह संभव है कि सुझावों के साथ तुरंत शुरू करें, और यहां तक ​​कि बेहतर स्पष्ट प्रश्नों के साथ, यह क्यों किया गया और अन्यथा नहीं।

अंतभाषण

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

आसानी से गुगली किए गए अध्ययन बताते हैं कि जब तनाव के एक निश्चित स्तर से अधिक हो जाता है, तो प्रदर्शन तेजी से घट जाता है।

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

सबसे अच्छे विचार अनुकूल वातावरण में पैदा होते हैं।

उदाहरण के लिए, विचार-मंथन के नियम को लें: सबसे पहले हर कोई विचारों को फेंकता है, और आप उनकी बिल्कुल भी आलोचना नहीं कर सकते। और तभी एक विस्तृत चर्चा आती है।

खैर, हम सभी लोग हैं। लोग तब पसंद नहीं करते जब कोई अपनी गलतियों को इंगित करता है। यहां तक ​​कि सबसे सही समीक्षा कोड अक्सर एक सार्वजनिक फ़ॉगिंग की तरह दिखता है। खैर, उत्तेजित मत हो!

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

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

इन सरल उपायों ने टीम में माहौल में काफी सुधार किया है।

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

ऐसे लोग हैं जिन्होंने कभी एक करीबी टीम में काम नहीं किया है, और यह कल्पना नहीं करते हैं कि यह कितना रोमांचकारी है।

हां, वास्तव में मैं यहां पर क्रूस पर चढ़ा रहा हूं, अपने आप पर जाएं ...

(अंतिम वाक्य के अंत में इमोटिकॉन को मध्यस्थों द्वारा हटा दिया गया था। मैं किसी को अपमानित नहीं करना चाहता, यह सिर्फ एक मजाक है)