विकास दल में "सार्वभौमिक": लाभ या हानि?

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

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

वह कौन है, हमारी उम्मीदों का अग्रदूत?

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

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

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

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

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

ये हर जगह हैं. वे हमेशा बहुत सक्रिय रहते हैं, ध्यान का केंद्र बनना चाहते हैं, लगातार अपने सहकर्मियों से पूछते हैं कि क्या उन्हें उनकी मदद की ज़रूरत है, और कभी-कभी वे परेशान भी हो सकते हैं। वे केवल सार्थक कार्यों में रुचि रखते हैं, जिनमें भाग लेने से रचनात्मकता को जगह मिलेगी और वे अपने गौरव का मनोरंजन कर सकेंगे।

वे किसमें मजबूत हैं:

• जटिल समस्याओं को हल करने में सक्षम हैं;
• समस्या में गहराई से उतरें, "खुदाई" करें और परिणाम प्राप्त करें;
• जिज्ञासु मन हो.

लेकिन:

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

2. "यूनिवर्सल - मैं इसका पता लगाऊंगा और करूंगा"

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

वे किसमें मजबूत हैं:

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

लेकिन:

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

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

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

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

वे किसमें मजबूत हैं:

• जिम्मेदार;
• परिणाम उन्मुख;
• शांत;
• पूरी तरह से नियंत्रित.

लेकिन:

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

4. “एक हरफनमौला खिलाड़ी अपनी कला का माहिर होता है”

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

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

वे किसमें मजबूत हैं:

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

लेकिन:

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

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

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

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

एक उदाहरण के रूप में अपनी टीम का उपयोग करते हुए, मैं आपको अपने साथी जनरलिस्टों के फायदे और नुकसान दिखाऊंगा। मेरी टीम में उनमें से एक तिहाई हैं, और मैं उनसे बहुत प्यार करता हूँ।

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

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

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

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

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

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

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

हम समस्याओं से कैसे निपटें?

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

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

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

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

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

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

अंत में क्या हुआ?

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

निष्कर्ष

सामान्यवादी कर्मचारियों के अपने फायदे और नुकसान हैं।

लाभ:

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

नुकसान:

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

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

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

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

मैं सभी को "अपनी कला के सार्वभौमिक उस्तादों" की एक स्व-संगठित टीम की कामना करता हूँ!

स्रोत: www.habr.com