संस्कृति को अक्सर अनदेखा किया जाता है और गलत समझा जाता है, फिर भी यह कंपनी के प्रदर्शन के लिए जिम्मेदार एक महत्वपूर्ण कारक है। यदि हम अपनी संस्कृति का प्रबंधन नहीं करते हैं, तो हम गलत प्रथाओं को समाप्त करेंगे, जो अंततः हमारे व्यावसायिक लक्ष्यों को प्रभावित करेंगे।
किसी संगठन की वर्तमान संस्कृति को समझना
संस्कृति हमें किसी समूह या कंपनी के मूल्यों और मानदंडों के बारे में बताती है। यह पहचानता है कि क्या महत्वपूर्ण है और साथ ही साथ लोग एक दूसरे के साथ कैसे काम करते हैं।
संस्कृति = 'सफलता के लिए स्मार्ट तरीके से कैसे किया जा सकता है'
चलो ग्राहक सहायता टीम का उदाहरण लेते हैं। उस टीम की संस्कृति ऐसी होनी चाहिए कि वे ग्राहकों की संतुष्टि के 97-98% को प्राप्त करें।
एक जावा विचारधारा क्या है
ग्राहक को प्रसन्न रखते हुए, सबसे पहले उन्हें विनम्र होने की आवश्यकता है, यहां तक कि मुश्किल परिस्थितियों में भी उन्हें भ्रम से बचने के लिए अच्छे श्रोता होने की आवश्यकता होती है, उन्हें आवश्यकता के अनुसार कार्य को प्राथमिकता देने की आवश्यकता होती है।
एक पल के लिए रुकें और खुद से कुछ सवाल करें:
- अब मेरी कंपनी की संस्कृति क्या है?
- यह संस्कृति मेरे व्यावसायिक लक्ष्यों या केआरए के साथ कितनी अच्छी है?
- मिसलिग्न्मेंट के कारण मुझे क्या समस्या हो सकती है?
हर संगठन के लिए, 4 सी एक महत्वपूर्ण भूमिका निभाता है
अब, आइए एक सॉफ्टवेयर डेवलपमेंट संगठन की संस्कृति पर नज़र डालें। एकल सॉफ्टवेयर इकाई के निर्माण और रखरखाव के लिए कई टीमें शामिल हैं। इन सभी टीमों के अलग-अलग लक्ष्य और अलग संस्कृति है।
क्लाइंट द्वारा आवश्यकताओं की पुष्टि किए जाने के बाद यह प्रक्रिया शुरू होती है।
डेवलपर्स अपने संगठन द्वारा परिभाषित कोडिंग दिशानिर्देशों का पालन करते हैं और कोड उत्पन्न करने के लिए संकलक, दुभाषिए, डिबगर आदि जैसे प्रोग्रामिंग टूल का उपयोग किया जाता है। विभिन्न उच्च स्तरीय प्रोग्रामिंग भाषाओं जैसे C, C ++, पास्कल, जावा और PHP का उपयोग कोडिंग के लिए किया जाता है।
वे पूरे पैकेज को छोटे फ़ोल्डरों में विभाजित करते हैं और फिर उसी के अनुसार छोटे कोड विकसित करते हैं।
प्रथम चरण : कोड की इन छोटी इकाइयों को फिर एक बड़ी इकाई बनाने के लिए क्लब किया जाता है। छोटे चिप्स को एकीकृत करते समय, एक परियोजना-स्तरीय परीक्षण को एकीकरण परीक्षण के रूप में जाना जाता है।
चरण 2 : सफल एकीकरण के बाद, इसे डमी सिस्टम में तैनात किया गया है। इस डमी सिस्टम में क्लाइंट मशीन या मशीन के समान कॉन्फ़िगरेशन है जहां इस प्रोजेक्ट को अंतिम रूप से तैनात किया जाना है।
स्टेज 3 : अंत में, एक डमी सिस्टम में सभी विशेषताओं का परीक्षण करने के बाद, परियोजना को उत्पादन सर्वर या क्लाइंट मशीन में तैनात किया जाता है।
यद्यपि यह प्रक्रिया शब्दों में बहुत चिकनी और आसान लगती है, तकनीकी रूप से इसे प्राप्त करना बहुत कठिन है।
आइए देखें कि हमें किन समस्याओं का सामना करना पड़ सकता है:
प्रथम चरण :
उत्पाद की गुणवत्ता में सुधार के लिए ग्राहक हमेशा परिवर्तनों की तलाश में रहता है। अधिकांश समय जब पहली पुनरावृत्ति हुई थी, ग्राहक कुछ परिवर्तनों का सुझाव देगा। जब डेवलपर्स परिवर्तन प्राप्त करते हैं, तो वे उन्हें शामिल करना शुरू कर देते हैं जो टूटे हुए निर्माण के लिए एकीकरण को प्रभावित करता है।
चरण 2:
अधिकांश समय, परीक्षक या अन्य ऑपरेशन के लोगों को किए जाने वाले नए परिवर्तनों के बारे में पता नहीं होगा। जैसे ही उन्हें डेवलपर्स से कोड मिलता है, वे उनका परीक्षण करना शुरू कर देते हैं। जबकि बैक-एंड पर डेवलपर्स अभी भी बदलाव कर रहे हैं।
जैसा कि उन्हें नए परिवर्तनों को लागू करने के लिए पर्याप्त समय नहीं मिलता है, वे विकासशील अक्षम कोडों का सामना करते हैं जो वे अन्य नेटवर्क और डेटाबेस मुद्दों का सामना करते हैं जो फिर से प्रसव के समय को विलंबित करते हैं।
जब वे अंततः ऑपरेशन टीम को कोड वितरित करते हैं, तो उन्हें नए परीक्षण मामलों को बनाने और लागू करने के लिए बहुत कम समय के साथ छोड़ दिया जाता है। इसलिए वे कई परीक्षण मामलों को छोड़ देते हैं जो उन्हें बाद में पता चलता है कि वे उच्च प्राथमिकता वाले थे।
स्टेज 3:
हालांकि वस्तुतः निर्माण उत्पादन के लिए तैयार प्रतीत होता है, लेकिन परिणाम पूरी तरह से अप्रत्याशित हैं। बिल्ड विफल रहता है और कई बग होते हैं।
फिर प्रत्येक बग के लिए, उन्हें ट्रैक करना होगा कि ऐसा क्यों हुआ, जहां यह हुआ, इसे दूर करने के लिए क्या परिवर्तन किए जाने की आवश्यकता है, क्या पिछले वाले के साथ संगत बनाने के लिए अन्य कोड में परिवर्तन होगा। अंत में, इन सभी बगों के लिए, एक बग रिपोर्ट तैयार करनी होगी।
कोड की दक्षता में डेटाबेस डेवलपर की अज्ञानता के कारण सिस्टम त्रुटियों की वजह से विफलता है, परीक्षण की संख्या में परीक्षक की अज्ञानता, आदि।
जैसा कि ग्राहक हमेशा समय सीमा को चुस्त रखता है, उन्हें प्राप्त करने में शामिल कर्मचारी केवल अंतिम रिलीज में ध्यान केंद्रित करते हैं, भले ही उन्हें समग्र गुणवत्ता से समझौता करना पड़े।
हालांकि यह काम के समन्वय में एक समस्या लगती है, यह वास्तव में अपनाई गई संस्कृति की विफलता है।
मैनुअल प्रक्रियाओं पर बड़ी निर्भरता के कारण ऐसा होता है। अलग-अलग क्षेत्र में ज्ञान की कमी और पहुंच में कमी या ब्याज की कमी के कारण एक ही टीम में भाग लेना हमारे अपने बोझ और दर्द को बढ़ाता है।
यह उच्च समय है कि हमें बहुमुखी बनने की आवश्यकता है। एक प्रणाली में शामिल सभी प्रक्रियाओं का मास्टर होना मुश्किल हो सकता है, लेकिन हम सभी के जैक हो सकते हैं, उनमें से एक को माहिर कर सकते हैं। तब केवल हम अपने सिस्टम को स्वचालित कर सकते हैं या रोलबैक के बजाय इसे पुनर्प्राप्त करने के लिए पर्याप्त बुद्धिमान बना सकते हैं।
अब, आप सोच रहे होंगे कि क्यों?
ऐसा इसलिए है, क्योंकि जिस पर आप महारत हासिल कर रहे हैं, वह दूसरों पर अत्यधिक निर्भर है। तो निर्भरता बिंदु के बारे में जानने के लिए, हमें पूरी प्रणाली को समझने की आवश्यकता है।
इसलिए संस्कृति को बदलने के लिए एक प्रक्रिया के बारे में सोचें। इससे पहले कि आप नीचे दिए गए सवालों का जवाब है?
- आपकी वर्तमान संस्कृति कहाँ विफल हो जाती है?
- आप प्रक्रिया को बदलना क्यों चाहते हैं?
- क्या आपने सभी आवश्यक परिवर्तनों को स्पष्ट रूप से पहचान लिया है?
- क्या आपने सभी प्रभावित हितधारकों से प्रतिक्रिया और खरीद प्राप्त की है?
- क्या आपने परिवर्तन के लिए प्रक्रिया अनुशासन, डेटा और मापन प्रणाली को अमान्य कर दिया है?
इसलिए, अब जब हमारे पास सभी का जवाब है, तो हम अपने सिस्टम में एक क्रांति के बारे में सोचते हैं। यह क्रांति कैसे होगी? यह तभी हासिल किया जा सकता है जब हम जो अभी हैं उसे मार दें। टीमों के बीच कोड के प्रवास में बहुत समय बर्बाद होता है। हमें उस प्रक्रिया को लाना होगा जहां हम निरंतर एकीकरण और निरंतर तैनाती कर सकते हैं।
निरंतर एकीकरण और तैनाती की यह प्रक्रिया इसे और अधिक चुस्त बनाती है। इस चपलता को लाने के लिए DevOps संस्कृति माना जाता है।
DevOps संचालन और विकास इंजीनियरों का अभ्यास है, जो पूरी सेवा जीवनचक्र में एक साथ भाग लेते हैं, विकास प्रक्रिया से लेकर उत्पादन समर्थन तक।
oracle pl sql त्रुटि सर्वोत्तम प्रथाओं से निपटने
समय के साथ कार्य प्रणाली को बदलना आसान नहीं है। एक सफल संक्रमण बनाना सिस्टम को पुनर्निर्मित करने के बजाय पुनर्निर्माण करना है।
अब देखते हैं कि हम इसे कैसे प्राप्त कर सकते हैं। अप्रोच करने के दो तरीके हो सकते हैं।
1) ऊपर नीचे करने के लिए
२) नीचे
इन तकनीकों के बारे में गहराई से जानने के बाद, हम महसूस करेंगे कि यह हमारे संगठन के लिए सबसे उपयुक्त है।
शीर्ष डाउन दृष्टिकोण में, हम उच्च प्रबंधन में जा सकते हैं और उनसे सभी टीमों में बदलाव करने के लिए कह सकते हैं। यदि प्रबंधन आश्वस्त है, तो हम इस पर काम शुरू कर सकते हैं।
एमएस sql ट्यूटोरियल शुरुआती के लिए
लेकिन जवाब 'NO' के रूप में मिलने की संभावना काफी अधिक है। क्योंकि सिस्टम को बदलने से संगठन अस्थिरता का कारण बन सकता है।
उन्हें संगठन, राजस्व, ग्राहक की रुचि के स्तर आदि की संरचना पर ध्यान देना होगा, लेकिन सबसे महत्वपूर्ण कारक जो उन्हें पुरानी प्रणाली से बाहर निकलने से पीछे खींचता है, वह यह नहीं देख सकता है क्या हासिल किया जा सकता है और नए के साथ इसे कितनी आसानी से हासिल किया जा सकता है, इसकी बड़ी तस्वीर।
इस मामले में, हम इस बड़े चित्र को प्राप्त करने के लिए दूसरे दृष्टिकोण की तलाश कर सकते हैं।
नीचे का दृष्टिकोण स्वयंसेवक के लिए कहता है। यहां हमें एक छोटी सी टीम और एक छोटा काम लेना है और इसे DevOps Model में निष्पादित करना है।
इस मॉडल के तकनीकी पक्ष को देखते हुए, हमारे पास परिष्कृत उपकरणों के विभिन्न सेट हैं जो काम को अधिक कुशल और तेज़ बनाते हैं। लेकिन, अकेले उपकरण देवो के रूप में संदर्भित एक सहयोगी वातावरण बनाने के लिए पर्याप्त सक्षम नहीं हैं।
इस तरह के वातावरण का निर्माण करने के लिए आपको बॉक्स से बाहर सोचना होगा। लोगों को अपनी टीमों, व्यवसाय और ग्राहकों के बारे में सोचने के तरीके का आकलन और अहसास।
संगठनात्मक संस्कृति को बदलने की तुलना में उपकरणों के एक नए सेट को एक साथ रखना सरल है। असामाजिक मास्टर डेवलपर्स को बढ़ावा देकर, अक्षम कोड को एकीकृत करने की अनुमति देता है, उन कोड को तैनात करना जो ठीक से परीक्षण नहीं किया गया था, एक-दूसरे के सिर पर दोष डालते हुए, ऑपरेशन टीम को बेवकूफ बनाने पर विचार करना सबसे अच्छा अभ्यास नहीं है जो हम व्यवसाय को सक्षम करने के लिए अनुसरण कर रहे हैं। और हमारे ग्राहकों के लिए मूल्य बनाएँ।
यह उपकरण नहीं है, यह उन लोगों का उपयोग करता है जो प्रक्रिया को जटिल बनाते हैं। विचारों और व्यवहारों को इकट्ठा करने के बजाय एक अमूर्त स्तर पर कहना, उनके लिए खुला होना हमें एक उज्ज्वल पथ पर ले जाता है।
आइए 6 सदस्य और 3-बिंदु वाली टीम के साथ शुरुआत करें। सबसे पहले, हमें डेवलपर्स, संचालन, परीक्षक आदि के रूप में हमारे द्वारा कॉल की जाने वाली टीम को तोड़ना होगा। हम उन सभी को एक मानते हैं, जैसा कि 'डेविल्स' कहते हैं। जब हमें आवश्यकताएं प्राप्त होती हैं, तो हमें जोखिम वाले क्षेत्रों का विश्लेषण करना होगा। समुद्र और नरक के गहरे वर्गों को ध्यान में रखते हुए .. हम नौकायन शुरू करते हैं।
अब, आप सोच रहे होंगे 'इन निरंतर एकीकरण और निरंतर तैनाती का एक्स-फैक्टर क्या है जो विफलता की संभावना को कम करता है'।
बेहतर दृष्टि और प्रक्रिया के साथ, हम परिणामों की स्पष्ट तस्वीर डालते हुए प्रबंधन से संपर्क कर सकते हैं जैसे कि प्रक्रिया कितनी सुचारू थी, विफलता का जोखिम कैसे कम किया गया था, समय से पहले कार्य कैसे पूरा किया गया था, आदि।
अब, हम स्पष्ट रूप से कल्पना कर सकते हैं कि प्रत्येक पुनरावृत्ति के बाद पूर्वव्यापीकरण करके पूरी प्रक्रिया को तकनीकी और सांस्कृतिक आधार पर कैसे अनुकूलित किया गया था।
एडुर्का ने विशेष रूप से क्यूरेट किया है यह आपको कठपुतली, जेनकिंस, Ansible, SaltStack, बावर्ची के आसपास अन्य लोगों के बारे में अवधारणाओं को समझने में मदद करता है।
क्या आप हमसे कोई प्रश्न पूछना चाहते हैं? उन्हें टिप्पणी अनुभाग में उल्लेख करें और हम आपके पास वापस आ जाएंगे।
संबंधित पोस्ट: