IT भूमिकाएँ: उत्पादकता और उपलब्धता

IT managers के रूप में हम दो बहुत अलग प्रकार के तकनीकी पेशेवरों से निपटने की जरूरत का सामना करते हैं। इन दो प्रकार के पेशेवरों को उनके व्यक्तित्व प्रकारों या काम करने के तरीकों से नहीं, बल्कि उनकी नौकरी की भूमिकाओं की प्रकृति से ही अलग किया जाता है। इन दो नौकरी प्रकारों की अनूठी जरूरतों को समझना तकनीकी कार्यकर्ताओं को प्रभावी ढंग से manage करने में महत्वपूर्ण है, लेकिन कम ही IT विभाग वास्तव में इन दो अलग-अलग नौकरी भूमिकाओं में निहित बारीकियों को समझने और सराहने के लिए समय लेते हैं।

पहले प्रकार को, और अब तक सबसे अच्छी तरह से समझे जाने वाले को, मैं “engineer” कहूँगा। इस engineering भूमिका में software developers और designers, architects, system engineers, network engineers या किसी भी प्रकार के नए systems को रचनात्मक रूप से design या implement करना जिनका प्राथमिक कार्य है — नौकरी के कार्यों की एक विशाल श्रृंखला शामिल है। Engineer शब्द एक loose शब्द है लेकिन अपेक्षाकृत meaningful है।

दूसरे प्रकार की technology worker भूमिका को सामान्यतः “support” भूमिका के रूप में संदर्भित किया जा सकता है। Support पेशे में helpdesk, systems administration, desktop support, network monitoring, command center, आदि शामिल हो सकते हैं। जो support पेशेवरों को engineering पेशेवरों से अलग करता है वह यह है कि उन्हें नए designs या implementations से जुड़ी creative processes का काम नहीं सौंपा जाता बल्कि वे मौजूदा systems के साथ काम करते हैं यह सुनिश्चित करते हुए कि वे ठीक से चलते हैं और जब कुछ गलत हो जाता है तो जल्दी से ठीक हो जाते हैं।

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

जहाँ भूमिकाओं की यह पहचान काम में आती है वह यह जानने में है कि तकनीकी staff को कैसे measure और manage किया जाए। बहुत उच्च स्तर से engineers को measure और manage करना काफी अच्छी तरह से समझा जाता है। उत्पादकता की अवधारणा engineering भूमिकाओं के लिए बहुत सरल और meaningful है। किसी engineering व्यक्ति या team को manage करने का लक्ष्य उस भूमिका को जितना संभव हो उतना creative design या implementation output करने की अनुमति देना और प्रोत्साहित करना है। गुणवत्ता की अवधारणा भी बिल्कुल मौजूद है, लेकिन हम फिर भी engineering भूमिकाओं के बारे में अपेक्षाकृत concrete terms में सोच सकते हैं जैसे लिखे गए functions की संख्या, produced deployment packages की संख्या, designed network का आकार, आदि। Metrics एक fuzzy चीज हैं, लेकिन हमें कम से कम एक अच्छा अंदाजा है कि एक engineer के लिए efficiency का क्या अर्थ है, भले ही हम इसे सटीक रूप से measure न कर सकें।

Support भूमिकाओं में यह समान अवधारणा नहीं है। हाँ, आप support भूमिका में उत्पादकता measure करने के लिए “बंद किए गए tickets” जैसे कृत्रिम metric का उपयोग कर सकते हैं, लेकिन यह बहुत भ्रामक होगा। एक ticket trivial हो सकता है और अगला एक बड़ी research challenge। कई मामलों में लंबे समय तक कोई tickets उपलब्ध नहीं हो सकते और फिर एक साथ कई आते हैं जिन्हें एक साथ serve नहीं किया जा सकता। उत्पादकता संभवतः sporadic और non-sustainable होगी और अंततः measure करने के लिए बिल्कुल भी meaningful नहीं होगी।

Engineering पद अपनी कमाई काफी लंबे समय तक — जो बड़े projects के लिए महीनों और वर्षों तक भी फैल सकती है — प्रभावी रूप से output produce करके करते हैं। इसलिए, engineering positions के साथ लक्ष्य एक ऐसा वातावरण प्रदान करना है जो sustainable उत्पादकता को प्रोत्साहित करे। यह अच्छी तरह से जाना जाता है कि engineers अक्सर shortened या alternative hours काम करके, नियमित vacations लेकर, आदि से उत्पादकता बढ़ाएंगे। यह अक्सर न केवल उत्पादकता बढ़ाता है बल्कि अक्सर output की गुणवत्ता में भी काफी सुधार करता है।

Support positions जरूरत पड़ने पर “वहाँ होने” से अपनी रोटी और मक्खन कमाते हैं। यदि एक support व्यक्ति अधिकतम efficiency से काम करने की कोशिश कर रहा है तो यह स्वाभाविक रूप से निहित है कि support issues का एक निरंतर backlog support team के ध्यान की प्रतीक्षा कर रहा है और बहुत से लोग support की प्रतीक्षा कर रहे हैं जिन्हें queue बनाने के लिए इसके लिए इंतजार करना पड़ता है। हमेशा एक queue बनाए रखने का मतलब यह भी है कि support personnel लगातार live items को resolve करने के बजाय stack से काम उठा रहे हैं — या तो high priority items को ignore कर रहे हैं या नियमित रूप से interrupted हो रहे हैं — जिससे continuous context switching होता है जो queue को efficiently handle करने की क्षमता को काफी कम कर देता है — जिसका अस्तित्व का पूरा उद्देश्य ही कृत्रिम उत्पादकता का भ्रम बनाना था।

Support भूमिकाएँ “event driven” हैं। मुझे यह terminology पसंद है क्योंकि मुझे लगता है कि यह सबसे सटीक रूप से उस mode का वर्णन करती है जिसमें लगभग सभी support पेशेवर काम करते हैं। चाहे कोई event phone call, instant message, email या ticket द्वारा उत्पन्न हो, यह एक “event” है जो support व्यक्ति को idle से action में transition करता है या, कुछ मामलों में, low priority item से high priority item में। किसी न किसी तरह, एक event support पेशेवर के लिए एक “context switch” का प्रतिनिधित्व करता है। किसी event के बिना support पेशेवर के पास करने के लिए कुछ नहीं है। यहाँ तक कि यदि “event” एक ticket queue या email backlog द्वारा दर्शाया जाता है तो भी यह event का एक रूप है।

एक वास्तव में कुशल support desk चलाने के लिए event प्रक्रिया के सावधानीपूर्वक management की आवश्यकता होती है। Support issues की कभी न खत्म होने वाली queue support पेशेवरों के लिए थकाऊ है और इसका मतलब यह भी है कि कोई भी staff high priority items की प्रतीक्षा में “idle” अवस्था में नहीं है। इस वजह से, high priority items या तो जितनी जल्दी होनी चाहिए उतनी जल्दी address नहीं किए जाते या फिर in-process items की उपेक्षा की जाती है।

Support staff की event driven प्रकृति को समझना इन teams के management के तरीके को समझने के लिए महत्वपूर्ण है। कोई सरल जवाब नहीं हैं, और support staff के metrics अक्सर engineering staff के metrics से भी अधिक बेमानी होते हैं — इसलिए अत्यधिक सावधानी के साथ उपयोग करें, लेकिन support भूमिका के साथ सहानुभूति रखकर हम देखना शुरू कर सकते हैं कि support manager के रूप में हमारी भूमिका support team members को support और promote करने की बड़ी तस्वीर में कहाँ फिट बैठती है।

मेरे अनुभवों से, सबसे महत्वपूर्ण अवधारणा support team को जाने वाले interrupts के अच्छे flow को प्रदान करना है। अक्सर support teams email और telephone जैसे कई अलग-अलग support avenues को handle कर रहे होते हैं। Events को उचित channels में restrict और funnel करना महत्वपूर्ण है।

Telephones के साथ समस्या यह है कि वे aggressive हैं और तत्काल context switch की मांग करते हैं चाहे recipient idle हो या वर्तमान में corporate history में सबसे critical production outage को support कर रहा हो। कॉल करने वाला व्यक्ति अनुमान लगा रहा है कि उनकी तत्काल जरूरत उस व्यक्ति की वर्तमान जरूरतों से अधिक है जिसे support person वर्तमान में support कर रहा है। Telephones हर जगह यह समस्या पैदा करते हैं जहाँ उनका उपयोग किया जाता है।

उस आखिरी बार के बारे में सोचें जब आप counter पर अपना order place करने के लिए एक pizza parlor में थे। आपने धैर्यपूर्वक line में इंतजार किया जब प्रत्येक व्यक्ति को serve किया गया। आपने सही काम किया। आप queue के सामने आए। आप अपना order place करना शुरू करते हैं जब phone बजता है। Order लेने वाला व्यक्ति आपको “hold” पर रखता है, हालाँकि आप वहीं खड़े हैं, phone उठाता है, order लेता है, फोन रखता है और आपके पास वापस आता है। यह कहता है कि phone करने वाला व्यक्ति, “squeaky wheel” होने के नाते, restaurant में वास्तव में मौजूद लोगों की तुलना में restaurant के लिए अधिक महत्वपूर्ण है। यही effect कई support desks पर होता है — in-process काम को group line पर या सीधे support person के पास calls से interrupt किया जाता है। यह, सबसे अच्छे मामले में, inefficient है और सबसे बुरे मामले में अत्यधिक critical मुद्दों के लिए critical support processes को बाधित कर सकता है।

इसलिए IT पेशेवरों को manage करने के तरीके के बारे में सोचते समय, उनकी भूमिका के उद्देश्य के बारे में सोचें। एक engineer का लक्ष्य उत्पादकता है। एक support पेशेवर का लक्ष्य उपलब्धता है।