मैं अपनी टीम के डेवलपर्स को "आप इसका निर्माण, आप इसे चलाते हैं" को गले लगाने के लिए कैसे मना सकते हैं?

Question

मैं अपनी टीम के डेवलपर्स को "आप इसका निर्माण, आप इसे चलाते हैं" को गले लगाने के लिए कैसे मना सकते हैं? उसके द्वारा, मेरे पास वर्नर वोगल्स के मन से यह उद्धरण है:

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

मैं विशेष रूप से डेवलपर्स के एक सेट के बारे में सोच रहा हूं जो:

• ऑप्स से संबंधित कार्यों के बहुत कम / कोई उल्लेख नहीं करने के साथ एक डेवलपर की भूमिका में काम पर रखा गया था।
• परंपरागत रूप से एक ऑप्स टीम के लिए "दीवार पर कोड फेंका गया" है।
• परंपरागत रूप से 9-5 कार्य अनुसूची है, और "पेजर ड्यूटी" के विचार के लिए सक्रिय रूप से शत्रुतापूर्ण हैं, आपदा वसूली में भाग लेना, पोस्ट-मॉर्टम लिखना, आदि, विशेष रूप से सामान्य व्यावसायिक घंटों के बाहर। (नोट: इसके लिए मेरे मन में केवल बहुत ही अनिश्चित परिणाम हैं; मैं यह प्रस्ताव नहीं कर रहा हूं कि हम इस टीम के काम के बोझ के बाद के घंटों के ग्राहक सहायता को जोड़ दें।)
• वर्तमान में लेखन / समर्थन निगरानी या उनके अनुप्रयोगों के लिए सचेत करने के लिए ज़िम्मेदार नहीं हैं।

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

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

Comments

यह कार्यस्थल एसई के रूप में अच्छी तरह से पूछने योग्य हो सकता है

— पीटर

Answer 1

मुझे लगता है कि सबसे आसान तरीका है अपने प्रदर्शन लक्ष्यों को बदलना ताकि वे कोड वितरित करने के साथ-साथ विश्वसनीयता पर आधारित हों। इसे बेच दें क्योंकि कंपनी दोनों के बिना सफल नहीं हो सकती इसलिए डेवलपर्स को केवल एक पर मापा जाना चाहिए? उनके लिए अपने प्रदर्शन लक्ष्यों को पूरा करने का सबसे अच्छा तरीका संचालन में शामिल होना है।

अंततः आपको उन्हें समझाने की ज़रूरत है कि कंपनी के सफल होने का सबसे अच्छा तरीका है और इसलिए उनके लिए सफल होना है। यह मुश्किल है और आप उन्हें शुरू से जहाज पर होने की उम्मीद नहीं कर सकते। उन्हें मूल्य पर भी बेचा जाना चाहिए।

Comments

मैं इससे सहमत हूं, यह महत्वपूर्ण है कि लोग ऐसा करना चाहते हैं न कि उन्हें केवल यह करने के लिए कहें।

— काइल स्टीनकैंप

Answer 2

जब व्यावसायिक संस्कृति को प्रभावित करने की बात आती है, तो सबसे अच्छा तरीका संभवतः प्रसिद्ध "उबाल मेंढक" विधि के माध्यम से है। आपको इन कार्यों को धीरे-धीरे डेवलपर्स से मिलवाना होगा, क्योंकि मुझे पता है कि मैं खुद (एक देव के रूप में) एक ही बार में यह सब नई जिम्मेदारी लेने पर तैयार हो जाऊंगा।

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

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

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

Comments

लेकिन देवों के बड़े बिंदुओं में से एक नहीं है कि आपको 23 घंटे (11 बजे) के पारंपरिक शनिवार के बजाय, जब भी आप तैनात / रिलीज कर सकते हैं, तो ऑफ-ऑफ करने की ज़रूरत नहीं है।

— जुथा अनटाइनन

Answer 3

विशेष रूप से DevOps के बाहर देखते हुए, यदि आप बड़े (ish) एंटरप्राइज़ वातावरण के बारे में बात कर रहे हैं, तो SAFe कार्यप्रणाली में इस तरह के व्यवहार को प्रोत्साहित करने का एक अच्छा तरीका है।

अनिवार्य रूप से यह कुछ प्रमुख चरणों में उबलता है:

• रिलीज ट्रेनों के रूप में परियोजनाएं शुरू होती हैं। इरादे (और जो कोई भी इसे निधि दे रहा है) की उम्मीद है कि यह लंबे समय तक चलेगा। मैं वर्षों से बात कर रहा हूं, इसमें से कोई भी "3 महीने के लिए एक टीम को खड़ा नहीं करता है, फिर उन्हें खड़ा करता है" व्यापार।

• एक परियोजना के दौरान रिलीज ट्रेन अनिवार्य रूप से नए एहसास किए गए व्यापार के अवसरों और रखरखाव शैली के काम के चल रहे कर के आधार पर दोनों नई परियोजना आवश्यकताओं के अधिक से अधिक लोगों को एकत्र करेगी।

• मैं लगभग हमेशा गाड़ियों को 100% प्रोजेक्ट / चेंज टीमों के रूप में अपनी पहली वेतन वृद्धि के रूप में देखता हूं, 2 वेतन वृद्धि वे रन कार्य के लिए समय का एक प्रतिशत आवंटित करते हैं। 3 वृद्धि प्रबंधन का एहसास है कि वे एक समस्या के बारे में हैं और नई आवश्यकताओं पर काम करने के लिए अपने अब अनुभवी डेवलपर्स और इंजीनियरों को समय देने के लिए रन ओवरफ्लो को संभालने के लिए टीमों को जोड़ना शुरू कर रहे हैं।

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

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

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

Comments

खैर, ठीक है, ठीक है, अब @ तेंसिबाई कुछ टीएलए (थ्री लेटर डेज़) से पीड़ित है कि "आई" एक्सीडेंटी (थिंक आई) पता है ... बिज़नेस अस असुअल कैसे होता है आईएमओ (एक और टीएलए) पूरा टेक्स्ट दिखता है। और BTW (grrrr, एक और एक), यदि आप ESL (grrrr, एक और अधिक) पीड़ित हैं और आप एक SCM (ggrrrr, एक और एक) प्रशिक्षण वर्ग में बीएयू का उच्चारण करते हैं, तो बेहतर है कि दर्शकों को "गुल" में अनुवाद करें। (वही ध्वनि ...), क्योंकि अंग्रेजी में "बिल्ड" जैसा होगा।

— Pierre.Vriens

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

— योगों

ठीक है, बहुत बेहतर है, आपने @Tensibai ... पीएस 1 से टिप्पणी का भी पालन किया है: मुझे विश्वास है कि आप टाइपो सुधार के साथ ठीक हैं जो मैंने अभी आपके उत्तर पर लागू किया है ... PS 2: SAF क्या है? मुझे विश्वास है कि यह "सिक्योरिटी एक्सेस फैसिलिटी" जैसी कोई चीज़ नहीं है, मेनफ़्रेम वातावरण में इस्तेमाल की जाने वाली चीज़ (विशाल), RACF, ACF2 या टॉप-सीक्रेट के साथ एकीकृत करने के लिए एक तरह की API ...

— पियरे.वियर्स

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

— हविंदिन

Answer 4

IMHO You build it, you run itको शाब्दिक रूप से नहीं लिया जाना चाहिए। शुरू करने के लिए - यह लगभग एक सजा की तरह लगता है;)

कोई भी व्यक्ति या छोटी डेवलपर टीम यथोचित रूप से लंबे समय तक सॉफ़्टवेयर डेवलपमेंट प्रक्रिया (अर्थात उत्पादन में!) में प्रयुक्त टूल या टूलसेट का समर्थन नहीं कर सकती है । वहाँ किया गया था कि :)

समर्थन कर्तव्यों का विस्तार उपकरण (सेट) के रूप में होता है जो ग्राहक आधार बढ़ता है। यदि उन कर्तव्यों को विशेष रूप से मान लिया जाए, तो विकास टीम सड़क के नीचे विकास के लिए बहुत कम / कोई समय नहीं बचा सकती है। प्रभावी रूप से एक डेड-एंड - कितने डेवलपर्स ऐसे वातावरण में घूमना चाहेंगे?

अपने डेवलपर टीम के सदस्यों पर कर्तव्यों का समर्थन करने के लिए लंबे समय तक संपर्क में निराशा, तनाव और अन्य प्रभावों को रोकने के लिए समर्थन टीम की पेशेवर 1 लाइन का होना महत्वपूर्ण है।

पहली पंक्ति समर्थन टीम, निश्चित रूप से, डेवलपर टीम (फिर से, टीम, एकल-व्यक्ति नहीं!) के लिए उन मुद्दों के लिए कमबैक कर सकती है, जिन्हें वे सीधे कवर कर सकते हैं। हां, यह पहली बार में मुश्किल हो सकता है, लेकिन बात बेहतर हो जाएगी। यह एक सहयोग होना चाहिए - जो कि DevOps के बारे में है।

Comments

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

— एंथनी नाइस

ओह समझा। हां - कुल बेमेल। मैं शायद इस जवाब को हटा दूंगा।

— दान कोर्निलेस्कु

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

— एंथनी नेवी

Answer 5

यह अंततः कंपनी के आकार और संरचना पर निर्भर करता है। वास्तव में तीन चरण हैं जो आपकी कंपनी में हो सकते हैं:

1. स्टार्टअप चरण (150 इंजीनियरों के तहत)। बेशक, डेवलपर्स को अपना खुद का सॉफ़्टवेयर चलाने की आवश्यकता है। एक स्टार्टअप में हर कोई ऐसा करता है। आपके पास संचालन टीम शुरू करने के लिए भी नहीं हो सकती है, लेकिन भले ही आप ऐसा करते हैं, यह छोटा है और प्रगति की गति इतनी तेज है कि किसी अन्य टीम को सफलतापूर्वक चलाने के लिए आवश्यक ज्ञान को पास करने का कोई रास्ता नहीं है उनके लिए जल्दी से पर्याप्त है सफल हो जाओ।

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

3. कई व्यावसायिक इकाइयों के साथ बड़ा उद्यम (जहां प्रत्येक की अपनी संचालन टीम है): इस स्तर पर आप अमेज़ॅन मॉडल को वापस चालू कर सकते हैं, जहां प्रत्येक टीम आवश्यक रूप से अपनी स्वयं की सेवाओं का विकास और संचालन करती है। प्रत्येक व्यावसायिक इकाई में प्रत्येक को एक-दूसरे को जानने के लिए पर्याप्त छोटा होना चाहिए, इसलिए लगभग 150 इंजीनियरों के तहत और आप प्रत्येक को स्टार्टअप के रूप में अनिवार्य रूप से संचालित करते हैं। अमेज़ॅन के पास प्रत्येक एडब्ल्यूएस सेवा कम या ज्यादा अलग से संचालित होती है और यह उनके लिए काम करती है।

आपको यह पता लगाना होगा कि आपकी कंपनी किस चरण में है और / या उसके अनुसार चल रही है और उसके अनुसार कार्य कर रही है। कोई "एक आकार सभी फिट बैठता है" समाधान है।

Answer 6

मेरा इस पर ध्यान देना (यदि मुझे इस तरह के आदेश के साथ सामना करना पड़ा, या आप इसे जो भी कहेंगे), " What else would you expect?!?!" जैसा कुछ होगा । क्योंकि, अकस्मात:

• मैं भी इसके बिना नहीं रह पाऊंगा, और
• मुझे अपना (कुत्ता) खाना पसंद है।

मुझे थोड़ा और समझाएं ...

मेरा व्यवसाय / शौक / जुनून scm है , विशेष रूप से मेनफ्रेम वातावरण में। और जहां भी मैं जाता हूं (ग्राहकों की जरूरतों को पूरा करने के लिए सामानों की पूर्ति के लिए), बहुत पहले आवश्यकता जो मैं (मेरे अनुबंध में) लगाता हूं, वह यह है कि जिस प्रणाली को हम लागू करते हैं, उसके लिए कोई ट्यूनिंग उसी समान प्रणाली के माध्यम से होती है। और ऐसा करने से (सच है, जो कुछ घंटों की तरह लगता है, अधिकतम दिन में आधे दिन कहते हैं), हमें इससे (अधूरी सूची) ये लाभ मिलते हैं:

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

हालांकि, इससे पहले कि आप खुद घर पर यह कोशिश करें, बचने के लिए कुछ नुकसानों से अवगत रहें:

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