23-24 सितंबर को सेंट पीटर्सबर्ग में सेंट
टीमलेड कॉन्फ 2019 आयोजित किया गया था। फ्लंट ने इसमें सक्रिय भाग लिया: इगोर त्सुको (अज्ञात के लिए हमारे निदेशक) ने एक बैठक आयोजित की, जहां प्रतिभागियों ने संगठन के भीतर गुप्त ज्ञान को खोजने और प्रकट करने के तरीके को समझा, और सर्गेई गोन्चरुक (परियोजना प्रबंधक) ने एक प्रस्तुति दी "एक वितरित टीम का प्रबंधन। बहु-प्रक्षेपण। " परंपरा से, हम रिपोर्ट और
उसके वीडियो (~ 37 मिनट) की समीक्षा प्रकाशित करते हैं।
"वितरित टीम" और "मल्टी-प्रोजेक्ट"
एक वितरित टीम के तहत, विभिन्न कंपनियां बहुत अलग-अलग चीजों को समझती हैं - उदाहरण के लिए, एक शाखा नेटवर्क या कार्यालय और दूरस्थ श्रमिक ... लेकिन हमारे मामले में इसके "वास्तविक" अर्थ में कोई कार्यालय नहीं है।
अब हमारे पास 80 से अधिक कर्मचारी हैं जो रूस और उससे आगे के 20 से अधिक शहरों में रहते हैं। हम में से अधिकांश एक दूसरे को "फ्लंटा" जन्मदिन पर साल में केवल 2 दिन "लाइव" देखते हैं।
बाकी समय हम मास्को, समारा, टूमेन, निज़नी नोवगोरोड या किसी अन्य शहर में रहते हैं, हम पक्षी या कॉफी की गंध के साथ काम करते हैं। जगह किराए पर देने के बजाय, हम वास्तव में उपयोगी कुछ में पैसा लगाते हैं। और जब से हर कोई दूर से काम करता है, हमारे पास "शाखाओं" या "जातियों" में विभाजन नहीं है।
और सबसे महत्वपूर्ण बात - हम किसी भी सीमा के बावजूद सबसे अच्छा किराया लेते हैं! यही हमारी समझ में "वितरण" है।
आइए अब बहु-डिज़ाइन से निपटते हैं, लेकिन शुरुआत के लिए यह फ़्लंटा डिवाइस में थोड़ा गोता लगाने के लिए महत्वपूर्ण है।
हम एक इंजीनियरिंग कंपनी हैं, हमारे पास कई इंजीनियर हैं। टीम लीडर और मैनेजर के मार्गदर्शन में पांच से सात इंजीनियर टीम बनाते हैं। ऐसी कई टीमें हैं, और प्रत्येक टीम के पास परियोजनाओं का अपना सेट है।
हमारे लिए, एक परियोजना एक उत्पाद या एक विकास टीम के लिए एक ग्राहक बुनियादी ढांचा है। यही है, परियोजना की स्पष्ट सीमाएं हैं, लेकिन विकास और विकास पर कोई प्रतिबंध नहीं है!
प्रत्येक परियोजना की अपनी आवश्यकताएं होती हैं, जिन्हें किसी तरह टीम को व्यक्त करने की आवश्यकता होती है।
यह प्रबंधक द्वारा किया जाता है। ये "मल्टी-डिज़ाइन" की मूल बातें हैं।
अब जब हमें रिपोर्ट के शीर्षक से शर्तों की एक सामान्य समझ है, तो सवाल यह है: यह सुनिश्चित करने के लिए क्या आवश्यक है कि ऐसी परिस्थितियों में सब कुछ सिर्फ काम नहीं करता है, लेकिन अच्छी तरह से काम करता है?
टीम प्रबंधक इस मुद्दे को हल करने के लिए जिम्मेदार है। ग्राहक से इंजीनियरिंग तक "अनुवादक" होना उसकी प्रमुख दक्षताओं में से एक है। दूसरा टीम के भीतर और ग्राहकों के साथ रचनात्मक संचार का संगठन है। और तीसरा मुख्य योग्यता काम के प्रवाह और इंजीनियरों की वास्तविक क्षमताओं के बीच एक संतुलन पा रहा है:
हम प्रत्येक क्षमता का अधिक विस्तार से विश्लेषण करेंगे।
1. प्रसारण अपेक्षाएं
यहां तक कि एक ही ग्राहक में परस्पर विरोधी अपेक्षाएं हो सकती हैं। उदाहरण के लिए, एक ग्राहक के व्यवसाय के लिए आवश्यक है कि उत्पादन करने वाला उत्पादन स्थिर हो। और इसके अलावा, लगातार नई विशेषताओं के साथ इसकी भरपाई की गई जो राजस्व बढ़ाने में मदद करती है।
खैर, अगर कोई दुर्घटना होती है (व्यापार दुर्घटना के लिए तैयार है), तो इसे जल्द से जल्द समाप्त कर दिया जाएगा। यह बहुत ही सही लगता है?
लेकिन इस क्लाइंट के पास डेवलपर्स भी हैं। और उनकी उम्मीदें, यह पूरी तरह से अलग हैं! डेव डेवलपर्स के लिए, उत्पादन अधिक महत्वपूर्ण है (आखिरकार, व्यवसाय भी उन पर दबाव डालते हैं), और वे यह भी उम्मीद करते हैं कि उनके किसी भी अनुरोध को अभी सुना जाएगा और बनाया जाएगा (आमतौर पर यह "वाक्यांश के बाद", 5 मिनट का काम ")।
आवश्यकताओं में व्यवसाय और डेवलपर्स दोनों को एकजुट करने वाली एकमात्र बात यह है कि दोनों अपेक्षित कार्यों को सटीक और समय पर पूरा करने की उम्मीद करते हैं।
आइए तस्वीर को समग्र रूप से देखें ... हां, यह तुरंत पारस्परिक रूप से अनन्य पैराग्राफ से भरा है!
- नई सुविधाओं को जोड़ना हमेशा विफलता के नए बिंदु जोड़ता है। Broads! और शुक्रवार की रिलीज के बाद उत्पादन अस्थिर है।
- हमारे इंजीनियरों ने दिन के दौरान जितनी जल्दी हो सके उतनी जल्दी किया, जो डेवलपर्स ने पूछा, और नियोजित कार्य इस वजह से अछूते नहीं रहे।
- या यहाँ की कहानी है: किस स्थिरता के लिए अधिक ध्यान देना पर्यावरण? हमने इसके लिए संसाधन आवंटित करके देव को स्थिर किया, लेकिन एक और रोल-आउट के बाद, उत्पादन में गिरावट शुरू हुई!
- एक लगातार मामला: उत्पादन टूट गया और पूरी टीम इसकी मरम्मत करने चली गई। इसी समय, निश्चित रूप से, नियोजित कार्यों पर कोई प्रगति नहीं हुई है, और यहां तक कि भारत के डेवलपर्स ने पहले ही चैट में रूसी भाषा की चैट पर स्विच कर दिया है, क्योंकि वे जवाब के लिए इंतजार नहीं कर सकते।
और हम समझते हैं कि आवश्यकताएं स्वयं विरोधाभासी हैं, जिसका अर्थ है कि उन्हें सीधे प्रसारित करना असंभव है।
2. संचार
वास्तव में उम्मीदों को प्रसारित करने में समस्याएं हैं। ठीक है, शायद तब कम से कम संचार के साथ सब कुछ आसान हो?
एक दूसरे के साथ और ग्राहकों के साथ संवाद करने के लिए, हम पाठ और Google मीटिंग के लिए स्लैक का उपयोग मीटिंग और अवसरों के लिए करते हैं जब यह लिखित की तुलना में आसान होता है। लेकिन एक चैट में हम अक्सर संदेश प्राप्त करते हैं जो एक उपयोगी अर्थ नहीं रखते हैं या इतनी त्रुटियां हैं कि अर्थ को पहचानना मुश्किल है!
हम इस पर ध्यान क्यों देते हैं? तथ्य यह है कि, उदाहरण के लिए, केवल जुलाई 2019 में हमें स्लैक में ग्राहकों से 1993 के अनुरोध प्राप्त हुए, जो एक अनिवार्य प्रतिक्रिया की आवश्यकता थी। और, ज़ाहिर है, ग्राहकों की संख्या में वृद्धि के साथ, इस तरह के अनुरोधों की संख्या की वृद्धि में एक स्थिर प्रवृत्ति है। जुलाई में, हमने इस तरह के कॉल की प्रतिक्रिया पर लगभग 165 इंजीनियरिंग घंटे बिताए। लेकिन प्रत्येक अपील के लिए, कुछ करना भी आवश्यक था!
हमें बहुत दुख होता है जब इंजीनियरों का समय, जो नियोजित कार्यों में लगाया जा सकता है, अन्य कॉलों की प्रतिक्रिया या यहां तक कि दुर्घटनाओं की मरम्मत के लिए बर्बाद हो जाता है।
चैट रूम के साथ समस्या स्पष्ट है, लेकिन वीडियोकांफ्रेंसिंग में शायद कोई समस्या नहीं है?
हमने ऊपर कहा कि हम दैनिक मीटिंग रैलियों के लिए Google मीट का उपयोग करते हैं, और बाकी समय हम उन कार्यों को करते हैं जो हमने रैली में हल किए थे। हर दिन हम लगभग एक घंटे रैलियों में बिताते हैं। हम प्रत्यक्ष काम पर प्रतिदिन कम से कम सात घंटे खर्च करने की कोशिश करते हैं, अर्थात् कार्यों को पूरा करने के लिए 6 घंटे बचे हैं। लेकिन हमारे कार्य अवधि में बहुत भिन्न हैं।
इसलिए यह पता चला है कि रैली के एक घंटे में हम कई छोटे, लेकिन संभवतः हमारे ग्राहकों के कार्यों के लिए महत्वपूर्ण हो सकते हैं। और हमें यह समझने की ज़रूरत है कि क्या घड़ी की बैठकें वास्तव में आवश्यक हैं या क्या इस बार जाना और काम करना बेहतर है?
यदि आप संचार समस्याओं को एक साथ लाने का प्रयास करते हैं, तो हम देखते हैं कि चैट बेकार रुकावट उत्पन्न करती है और नियमित रूप से रैलियों "काम करने के लिए" खाती है।
प्रभावी संचार अपने दम पर नहीं है।
3. योजना
ठीक है, हमें संचार और प्रसारण उम्मीदों में समस्याओं को हल करने की आवश्यकता है, लेकिन नियोजन में, शायद, कोई नुकसान नहीं है? चलिए इसका पता लगाते हैं।
हर दिन बड़ी संख्या में नए कार्य बनते हैं। मैं चाहूंगा कि वे जितनी तेजी से बढ़ें, हम कार्यों को बंद करें। लेकिन जीवन में, एक आदर्श शायद ही कभी प्राप्य है। सबसे पहले, कभी-कभी बुनियादी ढांचे में कुछ टूट जाता है। दूसरे, हमेशा कुछ छोटी चीजें होती हैं जिन्हें तुरंत करना आसान होता है। तीसरा, ऐसे कार्य हैं जिन्हें हम एक टीम रैली में हल करने के लिए सहमत हुए:
और कभी-कभी ऐसा होता है कि दुर्घटनाओं और trifles पर टगिंग के कारण, नियोजित लोगों के लिए बिल्कुल भी संभव नहीं है! इसी समय, नए कार्य आने बंद नहीं होते हैं - सभी प्रस्तावित समय सीमाएं टूट गई हैं।
हमारी रेसिपी
लेकिन उम्मीदों के अनुवाद के साथ सभी समस्याओं के लिए, संचार और योजना के साथ, शंकु को भरने की विधि, हम प्राप्त करने में कामयाब रहे, जैसा कि यह हमें लगता है, सही जवाब।
तीन प्रमुख दक्षताओं को प्रभावित करने वाली प्रमुख व्यावसायिक प्रक्रियाओं में से एक टीम की बैठक है। और हमें यह धारणा थी कि यदि हम एक टीम की बैठक को प्रभावी बनाते हैं तो हम बीस प्रतिशत प्रयास के साथ 80% परिणाम प्राप्त कर सकते हैं? हमने इस सिद्धांत का परीक्षण किया।
जैसा कि आपको याद है, हमारी एक टीम है जो हमारे प्रोजेक्ट के सेट पर काम करती है। और वह इन परियोजनाओं से आवश्यकताओं की एक निश्चित सूची है। लेकिन प्रत्येक आवश्यकता, एक नियम के रूप में, परस्पर संबंधित कार्यों की श्रृंखला में केवल एक है। और इसलिए हर परियोजना में! और एक नया कार्य करने से पहले, हमें यह समझने की आवश्यकता है कि क्या हमने पिछले चरण को पूरा किया है?
कल, टास्क ए -1 को ईगोर द्वारा, टास्क बी -1 को - शिमशोन और टास्क बी -1 को - जीन ने किया था। लेकिन हम सभी इंजीनियरों को इतनी गहराई से सभी परियोजनाओं में कैसे विसर्जित कर सकते हैं कि येगोर कार्य बी के साथ मुकाबला करने में सफल होता है, और शिमसन दो छोटे कार्यों ए और बी के साथ। "ये सभी कठिनाइयाँ क्यों हैं?" - आप पूछें। हां, तथ्य यह है कि ज़हाना आज छुट्टी पर नियोजित कार्यों को पूरा नहीं करेगी!
हमारा ध्यान बहुत सारे समान कार्यों पर है। औसतन, हमें प्रत्येक कार्य दिवस में प्रत्येक टीम के लिए लगभग 25 नए कार्य प्राप्त होते हैं। और चूंकि कई कार्य हैं, उनके बीच के संबंध भ्रमित हैं और इस बात की कोई समझ नहीं है कि पिछले दिन के सभी कार्य पूरे हुए हैं या नहीं। इस सब को उजागर करने के लिए, हमें एक टीम रैली की आवश्यकता है, और हर कार्य दिवस, अन्यथा हम इस प्रवाह को प्रबंधित करने में सक्षम नहीं होंगे।
प्रवाह की मात्रा को देखते हुए, यह पहले से रैली की तैयारी के लायक है। प्रशिक्षण में, इंजीनियरों के बिना, हम यह नहीं समझ पाएंगे कि कौन से कार्य पूरी तरह से हो चुके हैं और कौन से नहीं हैं। और, ज़ाहिर है, हम इंजीनियर से इंजीनियर तक ज्ञान स्थानांतरित नहीं कर पाएंगे। लेकिन हम काम करने के लिए नए कार्यों को लेने के लिए प्राथमिकताओं का निर्धारण करने में असमान हैं।
कार्य प्राथमिकता
कार्यों को प्राथमिकता देते समय हम किस पर आधारित होते हैं? सबसे पहले, हमारे पास लक्ष्य के बारे में क्लाइंट के साथ रणनीतिक समझौते हैं जिन्हें प्राप्त करने की आवश्यकता है। दूसरे, सप्ताह में एक बार हम ग्राहक के साथ एक ऑनलाइन मीटिंग के लिए सामरिक योजनाओं को अपडेट करते हैं। तैयारी में ग्राहक की जरूरतों को प्रबंधक द्वारा बरकरार रखा जाता है, और तकनीकी आवश्यकता और एक या किसी अन्य कार्य को पूरा करने की प्रक्रिया टीम लीड है। यह सही है,
टीम लीडर और मैनेजर की राय की समानता के आधार पर, दिन के लिए कार्यों की एक सूची बनाई जाती है।
टीम की बैठकों की संस्कृति
जैसे ही हमने दिन के लिए कार्यों की सूची निर्धारित की है कि क्या किया गया है और विवरण में अपने सहयोगियों को विसर्जित करने के लिए, हम एक टीम बैठक शुरू करते हैं, जिस पर प्रत्येक इंजीनियर को विस्तार से बताना चाहिए कि उसने कल क्या किया, और पूरी टीम को सुनना चाहिए और सबसे महत्वपूर्ण बात, उन परिवर्तनों को समझना चाहिए जो हुए हैं। लेकिन यह कहा से आसान है।
हमने रैली की कई सांस्कृतिक विशेषताओं को पेश किया, जिससे हमें वांछित परिणाम प्राप्त हुए:
रैली की शुरुआत में, जब सभी लोग इकट्ठा हो रहे थे, हम जीवन के बारे में बात करते हुए 10-15 मिनट बिताते हैं। समाचार और घटनाओं के बारे में काम से संबंधित नहीं, सहयोगियों के शौक के बारे में। इसलिए इंजीनियर जो अलग-अलग शहरों में हैं और लगभग एक-दूसरे को कभी दोस्त या दोस्त नहीं बनते हैं। और
ये 10-15 मिनट टीम को और अधिक एकजुट होने में मदद करते हैं ।
टीम बनाने की बातचीत के बाद हम मूल भाग में आगे बढ़ते हैं। थोड़ा पीछे चलते हैं।
इस दृष्टांत को याद करें? तथ्य यह है कि न तो शिमोन और न ही येगोर को पता है कि रैली शुरू होने से पहले वे किन कार्यों और परियोजनाओं को आज करेंगे। कई कारणों से: छुट्टियां, व्यावसायिक यात्राएं, बीमारी, कर्तव्य, आदि। - कार्य हर दिन कलाकारों को बदल सकता है जब तक कि यह पूरी तरह से हल न हो जाए। और प्रत्येक इंजीनियर समझता है कि आज एक कार्य को सौंपा जा सकता है,
अर्थात् , सभी इंजीनियर पहले से ही
प्रत्येक कार्य के विवरण में देरी करने में रुचि रखते हैं ।
रैली में, हम उन रुकावटों का विश्लेषण करते हैं जो पूरी टीम द्वारा उत्पन्न हुई हैं। हम जोर देते हैं कि स्पीकर की समस्या को हल करने में पूरी टीम हिस्सा ले। इसलिए हम
कार्यों में डुबकी लगाने और उन्हें एक साथ हल करने के लिए प्रेरित करते हैं ।
यदि टीम कार्यालय में काम करती है, तो अनौपचारिक संचार अक्सर "कूलर पर" होता है। लेकिन एक वितरित टीम में, इस तरह के संचार की आवश्यकता मौजूद है। इसीलिए कार्यों की चर्चा के दौरान, बातचीत अक्सर गलत दिशा में कहीं लीक हो जाती है। लेकिन हम किसी भी विक्षेप को रोकते हैं। बिल्कुल कैसे? हम इसे आसानी से करने का प्रबंधन करते हैं: आखिरकार, अमूर्त बातचीत के लिए विशेष रूप से आवंटित समय है, और अब यह काम करने का समय है। इसलिए, यहां तक कि सामान्य मौखिक "चलो बात करने के लिए" व्यापार के एजेंडे पर लौटने के लिए हर किसी के लिए पर्याप्त है। पार्सिंग कार्यों की प्रक्रिया में विकर्षणों को रोककर, हमने
काम करने के लिए टीम की स्थापना की ।
हम प्रत्येक इंजीनियर के रिपोर्ट समय को नियंत्रित करने का प्रयास करते हैं। कभी-कभी विवरण में गोता लगाने के लिए हमें कार्य के बारे में एक लंबी और विस्तृत कहानी की आवश्यकता होती है। हालांकि, ज्यादातर मामलों में, हम
रैली को फैलाने की कोशिश नहीं करते हैं ।
प्रभावी रैलियां - एक चांदी की गोली?
टीम के नेता और प्रबंधक की राय की समानता और रैली की हमारी सांस्कृतिक विशेषताओं के आधार पर रैली की तैयारी के लिए धन्यवाद, हमने वास्तव में उन्हें प्रभावी बनाया। लेकिन क्या आपने 80% सभी दक्षताओं को बंद करने का प्रबंधन किया है? वास्तव में नहीं।
हमने प्रसारण अपेक्षाओं के साथ अच्छा काम किया, लेकिन संचार में एक-दूसरे से अनचाहे चैट संदेशों के साथ अभी भी समस्याएं थीं, और नियोजन में रुकावटें थीं जो हमें निर्धारित कार्यों को प्रभावी ढंग से करने से रोकती थीं।
हां, लेकिन गैर-सूचनात्मक चैट संदेश भी रुकावट हैं। और हमें एक ऐसा तंत्र खोजने की जरूरत है, जो हमें सभी प्रकार के अवरोधों को कुशलतापूर्वक संभालने में मदद करे।
लड़ते हुए व्यवधान
हमने सोचा, क्या होगा अगर हमारे पास एक अलग व्यक्ति है जो अपने आप को एक टीम के साथ "कवर" करेगा जो रुकावट प्रवाह से नियोजित कार्यों पर काम कर रहा है?
विचार नया नहीं है और आम तौर पर अच्छा है, लेकिन वास्तव में यह कौन करेगा? हमने दो विकल्पों पर विचार किया: इस तरह की सेवा को खोजना और काम पर रखना या मौजूदा इंजीनियरों का उपयोग करना। नए लोगों की खोज के लिए समय और वित्तीय संसाधनों की आवश्यकता थी, और मौजूदा इंजीनियरों को पहले से ही "लड़ाई में परीक्षण" किया गया था और सभी टीम की परियोजनाओं में डूबे हुए थे। इसलिए, नए लोगों को काम पर रखने के विकल्प को अस्वीकार कर दिया गया था।
यह इस सवाल पर फैसला करना बाकी है कि वर्तमान इंजीनियरों से ऐसी सेवा को कैसे व्यवस्थित किया जाए। यहां समाधान सतह पर था: उन्होंने टीम से इंजीनियरों के रोटेशन के साथ, बस एक शेड्यूल पर ड्यूटी लागू की। हम Google कैलेंडर में ड्यूटी शेड्यूल रखते हैं, साथ ही स्लैक में सूचनाएं सेट करते हैं कि आज कौन ड्यूटी पर है।
ऐसा लगता है कि अब सब कुछ ठीक होना चाहिए? हुर्रे? नहीं, वास्तव में समस्या बनी हुई है। याद रखें, थोड़ा पहले हमने कहा था कि अकेले स्लैक में हमें महीने में लगभग 2,000 हिट मिलते हैं, जो प्रत्येक टीम के लिए एक दिन में लगभग 16 हिट होते हैं। लेकिन स्लैक के अलावा, परिचर को निगरानी प्रणालियों से संदेशों को संसाधित करना होगा, और जिस दिन यह होगा:
- 112 - प्रोमेथियस से;
- 16 - ओकेमीटर से;
- 25 - बाहरी ब्लैकबॉक्स निगरानी प्रणालियों से;
- 14 - विभिन्न कस्टम स्क्रिप्ट से;
- और यहां तक कि ग्राहकों से 2 फोन कॉल।
यह विभिन्न स्रोतों से हर दिन 198 रुकावट है! लेकिन वास्तव में, और भी स्रोत हैं:
- लगभग हर ग्राहक में प्रोमेथियस होता है;
- और ओकेमीटर प्रत्येक क्लाइंट पर स्थापित है;
- लेकिन कस्टम स्क्रिप्ट, यहां तक कि एक ग्राहक के रूप में कई के रूप में आप चाहते हैं ...
जादू और महाशक्तियों के साथ सामना करने के लिए टीम के किसी भी इंजीनियर के लिए, हमने सभी अवरोध स्रोतों से एक ही स्थान पर अलर्ट एकत्र किया। हमने इस उपकरण को मैडिसन कहा है, और इसमें प्रत्येक संदेश एक घटना है।
लेकिन मैडिसन केवल घटनाओं को एकत्र करता है और उनके बारे में भाग्य रखता है। लेकिन हमें यह समझने की जरूरत है कि किस तरह की घटना को पहले लेना है, अर्थात्, ट्राइएज प्रदर्शन करने के लिए, प्रोसेसिंग और एस्केलेशन का स्पष्ट आदेश देना है, ताकि इसे तनावपूर्ण स्थिति में आसानी से किया जा सके।
हमने एक ऐसा उपकरण भी बनाया - जिसे पोल्क कहा जाता है:
पोल्क ड्यूटी इंजीनियर का कार्यस्थल है। यह परिचर को केवल नियोजित कार्यों से विचलित हुए बिना घटनाओं पर ध्यान केंद्रित करने की अनुमति देता है, एक स्थान पर सभी स्रोतों से घटनाएं प्राप्त करता है, पूर्वनिर्धारित गंभीरता के अनुसार एक घटना की महत्वपूर्णता का निर्धारण करने में मदद करता है, स्पष्ट रूप से परिभाषित स्थितियों का एक सेट होता है और एक प्रसंस्करण एल्गोरिदम होता है जो इन स्थितियों की गति को निर्धारित करता है।
चैटिंग की तकनीकी और सांस्कृतिक विशेषताएं
उत्कृष्ट: अब इस तरह के एक शक्तिशाली उपकरण से लैस परिचर, वास्तव में रुकावट से टीम को बंद कर देता है। लेकिन यहां तक कि ऐसे उपकरणों के साथ घड़ी समाप्त हो रही है, और बेकार रुकावट केवल आग में ईंधन जोड़ती है।
बेकार चैट रुकावटों से निपटने के लिए, हम तकनीकी उपकरणों के एक छोटे सेट का उपयोग कर सकते हैं, लेकिन इस समस्या का मुख्य समाधान निश्चित रूप से सांस्कृतिक विमान में निहित है।
तकनीकी दृष्टिकोण से, स्लैक में हमने परियोजनाओं पर जानकारी साझा की, ग्राहकों के प्रतिनिधियों के साथ संचार के लिए एक अलग चैनल बनाया, और प्रत्येक परियोजना के लिए, इंजीनियरों के लिए एक चैनल इस पर काम पर चर्चा की। हमने
@flant बॉट भी लिखा है, जब पोल्क द्वारा पहुँचा जाता है, तो एक घटना स्वचालित रूप से बनाई जाती है जो ड्यूटी अधिकारी प्रक्रिया करता है।
इसके अलावा, हमने ग्राहकों से
@flant , और
@flant (सभी चैनल सदस्यों को सूचित करने वाली एक घटना) और
@here (ऑनलाइन सभी चैनल के सदस्यों को सूचित करने वाली एक घटना) का उपयोग करने की सिफारिश की, केवल उन दुर्लभ और असाधारण मामलों में जब आप उनके बिना नहीं कर सकते। (उदाहरण के लिए, जब
@flant bot अनुपलब्ध है)।
क्लाइंट के साथ हमारे सहयोग के पहले दिन, हम चैनल में इंटरैक्शन पर विस्तृत निर्देश देते हैं। और पहली नियमित बैठक में, हम निश्चित रूप से बातचीत पर चर्चा करेंगे, जिसमें
@here ,
@here और
@flant बीच अंतर शामिल है।
विशेष रूप से, हम इस तथ्य पर ध्यान केंद्रित करते हैं कि हमारे लिए
@flant कॉल, सबसे पहले, एक अनिवार्य प्रतिक्रिया के साथ एक कार्रवाई है, और टीम के अधिकांश
@here लिए
@here और
@here केवल एक रुकावट है, जो भी संबोधित नहीं है और इसे अनदेखा किया जा सकता है इस परियोजना के लिए नियोजित कार्यों को हल करने से पूरी टीम को विचलित करते हुए।
लेकिन नए सहकर्मी उन ग्राहकों से बातचीत करने आते हैं जिन्हें बॉट के बारे में जानकारी नहीं है। दूसरे सिर्फ भूल जाते हैं। यदि ऐसा होता है, तो हम धीरे-धीरे इसके अस्तित्व को याद करते हैं।
इंजीनियरों के बीच संचार के लिए, हम
@channel लिए समान नियमों का उपयोग करते हैं
और
@here : जब तक बिल्कुल आवश्यक न हो, उनका उपयोग न करें। और फिर भी, हम नियम का पालन करने पर जोर देते हैं "चैट में केवल" हैलो "न कहें - तुरंत एक विचार तैयार करें"। यह नियम सभी शुरुआती लोगों के लिए अवश्य पढ़ें। जो लोग इसे भूल गए, उन्हें यह याद दिलाया जाएगा - यदि आवश्यक हो, तैनात किया जाए।
कुल: बदलावों की शुरूआत और चैट में संचार समस्याओं के सुधार के साथ, हमने अधिकांश बेकार रुकावटों के साथ और नियोजित कार्यों के प्रदर्शन पर रुकावटों के प्रभाव के साथ सामना किया।
विलंब और अवरोधन
हमने जांच की कि उसके बाद हमारे संकेतक कैसे बेहतर हुए: वास्तव में, वे स्पष्ट रूप से बेहतर हो गए, लेकिन योजना बनाने में अभी भी समस्या थी।
जब टीम की रैली खत्म हो जाती है, तो काम करने का समय आ जाता है। लेकिन अक्सर, इंजीनियर, विशेष रूप से दूरस्थ रूप से काम करने वाले, विलंब करने की प्रवृत्ति रखते हैं। या, काम के दौरान, एक समस्या में भाग लें और इसे हल करने के प्रयास में हलकों में चलें।
आइए शिथिलता से निपटने की कोशिश करें। इसे कैसे दूर किया जाए? Redmine (हमारे कार्य ट्रैकर) में बहुत सारे कार्य हैं - आपको उन लोगों पर ध्यान केंद्रित करने की आवश्यकता है जो आज काम में होंगे। और यहां तक कि उनमें से, आपको यह समझने की आवश्यकता है कि प्राथमिकताओं को निर्धारित करने के लिए पहले क्या कार्य करना है। और आदर्श रूप से, यदि आप उस समय की योजना बनाते हैं जो हम प्रत्येक कार्य पर खर्च करने के लिए तैयार हैं ...
हमने एक उपकरण बनाया, जो इस सब को हल करने में मदद करता है, और इसे फोर्ड नाम दिया है:
यह उस में है कि इंजीनियर को कार्य दिवस के लिए प्राथमिकता के क्रम में व्यवस्थित कार्ड के रूप में एक कार्य प्राप्त होता है। सभी नियोजित कार्यों के लिए, हम लगभग समय निर्धारित करते हैं कि इंजीनियर को उन्हें हल करते समय पालन करना होगा। इंजीनियर उस समस्या को हल करने में खर्च किए गए समय को ध्यान में रखता है। और अगर समय लगभग समान है, लेकिन समस्या हल नहीं हुई है, तो यह एक मार्कर है कि इंजीनियर एक मृत अंत तक पहुंच गया है।
इससे क्या हो सकता है? प्राथमिकता जिसमें कार्ड स्थित हैं, के अलावा,
हमने प्राथमिकता श्रेणियां भी पेश कीं, उन्हें रंगों के साथ उजागर किया:
- ग्रे बॉक्स का उपयोग साधारण, अनुसूचित कार्यों के लिए किया जाता है;
- ग्रीन फील्ड - उन कार्यों के लिए जिन्हें वर्तमान दिन में ही शुरू किया जाना चाहिए, यदि अन्य सभी क्षेत्रों में कार्य समाप्त हो गए हों;
- पीला क्षेत्र उन कार्यों के लिए है जो दिन के दौरान अचानक अनियोजित हो गए थे;
- लाल क्षेत्र - उन कार्यों के लिए जिन्हें वर्तमान कार्य दिवस के अंत से पहले हल करने की आवश्यकता है।
यदि एक इंजीनियर को ग्रे और हरे रंग के क्षेत्रों में एक कार्य द्वारा अवरुद्ध किया जाता है, तो उसे बस अगले कार्य को शुरू करना होगा, और अगली टीम की बैठक में लॉक को विघटित करना होगा।
लेकिन यह स्पष्ट है कि अगर एक इंजीनियर पीले या लाल ज़ोन में कार्यों से अवरुद्ध होता है, तो आपको अगली बैठक की प्रतीक्षा नहीं करनी चाहिए: आपको उस प्रोजेक्ट पर संवाद करने के लिए इंजीनियरों के लिए उपयुक्त चैनल में टीम से मदद लेने की आवश्यकता है जिसमें कार्य निर्धारित है। और, हमारी संस्कृति के अनुसार, टीम इंजीनियर या टीम लीडर निश्चित रूप से बचाव में आएंगे।
यह उल्लेखनीय है कि फोर्ड की क्षमताएं अधिक व्यापक हैं और हमने केवल "हिमशैल के टिप" को छुआ है, जिसे आप अन्य खुले टूल का उपयोग करके कार्यान्वित कर सकते हैं।
परिणाम
यह पता चला है कि शिथिलता और अवरोध का मुकाबला करने के लिए, हम एक तकनीकी समाधान और टीम संस्कृति में सरल नियमों के रूप में फोर्ड का उपयोग करते हैं।
क्या इन उपकरणों ने हमारी मदद की? हाँ! लेकिन किसी कारण से, 100% नहीं?
तथ्य यह है कि दुनिया बदल रही है और आगे बढ़ रही है। और हम इन परिस्थितियों में भी बदल रहे हैं, आदर्श के लिए प्रयास कर रहे हैं, लेकिन, जैसा कि आप जानते हैं, यह अप्राप्य है।
आदर्शों को प्राप्त करने और प्रबंधक की भूमिका पर
अपने अस्तित्व की पूरी अवधि में मानव जाति ने जो कुछ महान चीजें बनाई हैं, वे पेशेवरों की टीमों द्वारा की गई हैं, जिनके पास शांत प्रबंधक थे।
हम, फ्लंट, पेशेवरों की एक टीम भी हैं। और यह अच्छा होगा अगर हमारी टीम में अधिक शांत प्रबंधक हों। काम करने के लिए हमारे पास आओ और हमारी प्रक्रियाओं को बेहतर बनाने में मदद करें:
वीडियो और स्लाइड
प्रदर्शन से वीडियो (~ 38 मिनट):
रिपोर्ट की प्रस्तुति:
पुनश्च
हमारे ब्लॉग में भी पढ़ें: