हमने पेशेवर बर्नआउट को रोकने के लिए "हमेशा संपर्क में" की स्थिति को कैसे बदला

लेख का अनुवाद विशेष रूप से पाठ्यक्रम के छात्रों के लिए तैयार किया गया था "DevOps प्रथाओं और उपकरण" ।

---

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

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

काम के घंटों के बाहर "हमेशा संपर्क में" रहना आपके जीवन के लिए हानिकारक है।

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

इंटरकॉम में इंटरकॉम स्टेटस हिस्ट्री

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

किसी भी समय बहुत सारे लोग "संपर्क" में थे।

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

हमें एहसास हुआ कि हम ऐसी स्थिति में थे, जहां हमारे पास तकनीकी सहायता के मैकेनिक्स हैं, जिन पर गर्व नहीं किया जा सकता है, और कई महत्वपूर्ण समस्याएं जिन्हें हम खत्म करना चाहते थे, जैसे:

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

"हमेशा संपर्क में" की सही स्थिति खोजें

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

परिणामस्वरूप, हमारी सहायता टीम 30 लोगों से घटकर मात्र 6 या 7 रह गई।

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

हमारे पास कई महीनों की कड़ी मेहनत थी, जिसके दौरान हमने यह प्रक्रिया शुरू की, जिसके परिणामस्वरूप अब पहले की तरह 30 इंजीनियर नहीं थे, लेकिन केवल 6 या 7 संपर्क में रहे। काम के घंटों के दौरान, टीम स्वतंत्र रूप से अपने कार्यों या सेवाओं के साथ समस्याओं से निपटती है। इस समय में आम तौर पर सबसे बड़ी संख्या में ब्रेकडाउन होते हैं, हालांकि, बाकी समय स्वयंसेवक तकनीकी सहायता में लगे रहते हैं।

हमने क्या सीखा?

हमने अपनी वर्चुअल तकनीकी सहायता टीम लॉन्च करने के बाद, हमने नए कार्यों की एक आमद की उम्मीद की, जैसे कि समस्याओं के कारणों की जांच करना या किसी एक समस्या को हल करने के लिए एक सामान्य सभा की विफलता। हालांकि, हमारी विकास टीमों ने विफलताओं के कारण कारकों की पूरी जिम्मेदारी ली, और बाद की कोई भी प्रतिक्रिया आमतौर पर तत्काल कार्रवाई थी। हमें ऐसी स्थिति से भी बचने की जरूरत है जिसमें तकनीकी सलाह का काम उस टीम को वापस करना होगा जहां से वह आया था, ताकि इंजीनियरों को घंटों बाद संपर्क करने के लिए मजबूर न किया जाए।

आउट-ऑफ-ऑफिस कॉल प्रति माह 10 से कम हो गई।

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

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

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

हमारे डेटा वेयरहाउस को स्थिर और स्केल करने के मौलिक काम के साथ-साथ, समस्याओं को हल करने के लिए लगातार ध्यान देने के कारण यह तथ्य सामने आया है कि बंद घंटों के दौरान कॉल की संख्या प्रति माह 10 से कम हो गई है। हमें इस संख्या पर बहुत गर्व है।

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