विकास टीम में "यूनिवर्सल": लाभ या हानि?

सभी को नमस्कार! मेरा नाम ल्यूडमिला मकरोवा है, मैं UBRD में एक विकास प्रबंधक हूं और मेरी टीम का एक तिहाई हिस्सा सार्वभौमिक है।

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

वह कौन है, हमारी उम्मीदों का प्रतिपादक?

शब्द "सामान्यवादी" आमतौर पर टीम के सदस्यों को समझने के लिए समझा जाता है जो एक से अधिक भूमिकाओं को जोड़ते हैं, उदाहरण के लिए, एक विकास विश्लेषक।

टीम की सहभागिता और इसके कार्य का परिणाम प्रतिभागियों के पेशेवर और व्यक्तिगत गुणों पर निर्भर करता है।

कठिन कौशल से, सब कुछ स्पष्ट है, लेकिन नरम कौशल विशेष ध्यान देने योग्य हैं। वे एक कर्मचारी के लिए एक दृष्टिकोण खोजने में मदद करते हैं और उसे ठीक उसी कार्य के लिए निर्देशित करते हैं जिसमें वह सबसे उपयोगी होगा।

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

1. "सार्वभौमिक - सर्वशक्तिमान"

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

क्या मजबूत हैं:

• जटिल समस्याओं को हल करने में सक्षम;
• समस्या में गहराई से डूबे, "खुदाई" और परिणाम प्राप्त करें;
• एक जिज्ञासु मन के अधिकारी।

लेकिन:

• भावनात्मक रूप से प्रयोगशाला;
• खराब प्रबंधित;
• अपनी खुद की अस्थिर दृष्टिकोण है, जिसे बदलना बहुत मुश्किल है;
• एक साधारण बात करने के लिए कठिन है। आसान कार्य गर्व की सर्वशक्तिमानता को चोट पहुँचाते हैं।

2. "स्टेशन वैगन - मैं इसे समझूँगा और करूँगा"

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

क्या मजबूत हैं:

• स्वतंत्र;
• तनाव प्रतिरोधी;
• कई मामलों में सक्षम;
• erudite - उनके बारे में बात करने के लिए हमेशा कुछ होता है।

लेकिन:

• अक्सर दायित्वों का उल्लंघन;
• चीजों को जटिल करने के लिए: वे भागों में गुणा करके गुणा तालिका को हल करते हैं;
• काम की गुणवत्ता कम है, सब कुछ 2-3 बार बदल जाता है;
• वे लगातार समय सीमाएं बदल रहे हैं, क्योंकि वास्तव में सब कुछ इतना सरल नहीं है।

3. "यूनिवर्सल - ठीक है, मुझे जाने दो, क्योंकि कोई और नहीं है"

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

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

क्या मजबूत हैं:

• जिम्मेदार हैं;
• परिणाम पर ध्यान केंद्रित;
• शांत;
• पूरी तरह से नियंत्रित।

लेकिन:

• निम्न स्तर की दक्षताओं के कारण औसत परिणाम दिखाना;
• जटिल और अमूर्त समस्याओं को हल नहीं कर सकते।

4. "यूनिवर्सल उनके शिल्प का एक मास्टर है"

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

वह वास्तुकला से अच्छी तरह से परिचित है, तकनीकी कार्यान्वयन की विधि का चयन करता है, वर्तमान वास्तुकला पर चुने हुए समाधान के प्रभाव का सावधानीपूर्वक विश्लेषण करता है। मामूली, महत्वाकांक्षी नहीं।

क्या मजबूत हैं:

• उच्च गुणवत्ता वाला काम दिखाएं;
• किसी भी समस्या को हल करने में सक्षम;
• बहुत कुशल है।

लेकिन:

• दूसरों की राय के असहिष्णु;
• maximalists। वे सब कुछ सही करने की कोशिश करते हैं, और इससे विकास का समय बढ़ता है।

व्यवहार में हमारे पास क्या है?

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

दक्षताओं के संयोजन / विलय / संयोजन के लिए सबसे आम विकल्प एक विश्लेषणात्मक डेवलपर है। इसके अलावा, एक परीक्षक विश्लेषक और एक तीन-इन-वन बहुत आम हैं।

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

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

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

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

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

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

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

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

हम समस्याओं के साथ कैसे काम करते हैं?

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

1. प्रत्येक समस्या के लिए जो कठिनाइयों का कारण बनती है, मैं आपसे एक एकीकृत रूप भरने के लिए कहता हूं: एक त्रुटि मानचित्र जो आपको उस चरण की पहचान करने की अनुमति देता है जिस पर "ड्राडाउन" हुआ था:



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

3. हमने टीम के भीतर बातचीत के नियम पेश किए। उदाहरण के लिए, हम आवश्यक रूप से परियोजना प्रबंधन प्रणाली में कार्य की प्रगति के बारे में सभी जानकारी दर्ज करने के लिए सहमत हुए। विकास प्रक्रिया के दौरान कलाकृतियों को बदलते / पहचानते समय, आपको इसे ज्ञान के आधार और टीओआर के अंतिम संस्करण में प्रदर्शित करना होगा।

4. नियंत्रण प्रत्येक चरण पर शुरू किया गया था (अतीत में समस्याग्रस्त चरणों पर विशेष ध्यान दिया जाता है) और स्वचालित रूप से अगले कार्य के परिणामों के आधार पर।

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

परिणाम क्या है?

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

निष्कर्ष

यूनिवर्सल कर्मचारियों के पास उनके पेशेवरों और विपक्ष हैं।

लाभ:

• आप किसी भी समय सैगिंग कार्य को बंद कर सकते हैं या थोड़े समय में एक जरूरी बग को हल कर सकते हैं;
• समस्या को हल करने के लिए एक एकीकृत दृष्टिकोण: कलाकार इसे सभी भूमिकाओं के पक्ष से देखता है;
• सामान्यता लगभग सब कुछ समान रूप से अच्छी तरह से कर सकती है।

नुकसान:

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

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

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

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

मैं हर किसी को "अपने शिल्प के सार्वभौमिक स्वामी" की एक स्व-आयोजन टीम की कामना करता हूं!