टीम मनोविज्ञान

जब कई लोग एक ही प्रोजेक्ट (कोड) पर काम करते हैं, तो सॉफ्टवेयर डेवलपमेंट की प्रक्रिया में काफी अंतर होने लगता है। कोई इस तथ्य से सहमत नहीं हो सकता है। कई अतिरिक्त कारक खेल में आते हैं। समग्र परिणाम विकास की गति में कमी है, और कभी-कभी विकसित सॉफ़्टवेयर की गुणवत्ता में कमी हो सकती है।

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

सॉफ्टवेयर की प्रभावशीलता और गुणवत्ता में कमी का कारण क्या है?

प्रोग्रामर की प्रभावशीलता को कम करने वाले कारकों को उद्देश्य और व्यक्तिपरक में विभाजित किया जा सकता है।

दक्षता को प्रभावित करने वाले विशेष कारक

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

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

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

प्रोग्रामर, काम करने वाला, महसूस कर सकता है कि यह कोड "उसका" या "उसका नहीं" है। कोड के साथ यह स्व-पहचान काफी महत्वपूर्ण है। यदि कोई व्यक्ति मानता है कि कोड "उसका" है, तो वह:

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

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

उद्देश्य कारक

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

समस्या की विशिष्टता और कथन

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

समस्या हल करना

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

• सबसे सिद्ध तरीका कोड के लेखक होना है :)
• किसी भी लिखित कोड प्रलेखन
• प्रोग्रामर के बीच मौखिक और लिखित संचार

निम्नलिखित तरीके कोड के स्वामित्व को बढ़ाने के लिए उपयुक्त हैं:

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

कोड मसौदा मानकों पर एक अलग पैराग्राफ (स्वामित्व बढ़ाने का एक और तरीका, बस बहुत लंबा)

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

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

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

युक्तिकरण मुद्दे

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

विधि संख्या 1। जिम्मेदारी और "व्यक्तिगत कमरे" का पृथक्करण

यदि आपकी परियोजना की बारीकियां अनुमति देती हैं:

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

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

• आपके पास अपूरणीय प्रोग्रामर होंगे (यदि मिंक स्वामी निकलता है, तो किसी और के लिए इस मिंक का साथ देना मुश्किल होगा)
• यदि सभी लेकिन एक "मिंक" तैयार है, तो प्रोग्रामर जो पहले से ही काम पूरा कर चुके हैं, वे वास्तव में एक प्रोग्रामर की मदद नहीं कर पाएंगे, जो अनुसूची के पीछे है, क्योंकि वे "मिंक" की बारीकियों को नहीं जानते हैं और सबसे अधिक संभावना केवल प्रोग्रामर को नाराज करेगी

पेशेवरों:

• आप इंट्रा-मिंक प्रक्रियाओं के प्रलेखन के बिना कर सकते हैं। क्योंकि एक मिंक एक प्रोग्रामर द्वारा समर्थित है, तो वह यह सब अपने सिर में रख सकता है
• प्रोग्रामर व्यावहारिक रूप से संचार पर समय नहीं बिताते हैं

विधि संख्या 2। मंच

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

निष्कर्ष

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