मुझे यह जानने में दिलचस्पी है कि एक मौजूदा सॉफ्टवेयर डेवलपमेंट प्रक्रिया से कैसे निपटा जाए जो सालों से बदली नहीं है और आखिरकार उत्पाद और टीम की विफलता का कारण बनेगी। हां, इसे हल करने का आसान तरीका नौकरी बदल रहा है, लेकिन इस अर्थव्यवस्था के साथ काम करना आसान है। हालांकि, यदि आपके पास विशिष्ट उदाहरण हैं और एक ही स्थिति में कई बार देखे या देखे गए हैं और सोचते हैं कि इन मुद्दों को हल करने के लिए सबसे अच्छा समाधान कंपनी को छोड़ना है, तो कृपया अपने उत्तर का समर्थन करें। मुद्दा यह है, इस सवाल का वास्तव में एक जवाब है, खासकर अगर विषय के कई विशेषज्ञ यह इंगित करते हैं कि जाने के लिए सबसे अच्छा मार्ग है: मार्ग ए।
मुझे पता है कि डेवलपर्स के टन समान स्थितियों में रहे हैं या हैं। यह एक मुख्य कारण है कि कंपनियां अपने बाजार में # 1 से अंतिम या बाजार से दूर होने तक जाती हैं। उम्मीद है कि इस पोस्ट के उत्तर अन्य डेवलपर्स को समान बाधाओं का सामना करने में मदद करेंगे। एक छोटे या बड़े विकास दल में यह आमतौर पर होता है:
- कुछ डेवलपर्स परवाह नहीं करते हैं और प्रवाह के साथ जाने का फैसला करते हैं और कोड को बहुत सारे कोड के साथ छोड़ना पसंद करते हैं जिस तरह से यह गंध है और विकास प्रक्रिया है, जैसे,
- अन्य लोग बिना किसी बदलाव के थक जाते हैं और इस्तीफा देकर दूसरी कंपनी में चले जाते हैं,
- दूसरों को बात करने में डर लगता है और चुप रहना पसंद करते हैं,
- कई बार बहुत कम डेवलपर्स या सिर्फ एक उत्पाद के सुधार के लिए बोलने की कोशिश करते हैं, और टीम को बताते हैं कि ग्राहकों, उपयोगकर्ताओं और टीम के लिए ऐसा करने के लिए सर्वोत्तम कोडिंग प्रथाओं और लाभों का पालन करना कितना महत्वपूर्ण है। इस प्रकार के डेवलपर्स आमतौर पर टीम के साथ रहने का फैसला करते हैं जैसे कि कंपनी ऐसे लाभ प्रदान करती है जो बहुत कम सॉफ्टवेयर कंपनियां पेश करती हैं, या उत्पाद में बहुत अधिक संभावनाएं होती हैं, आदि।
हमारी टीम में उत्पाद केवल एक अंश है जहां कंपनी को इसका राजस्व मिलता है क्योंकि इसमें उत्पादों की एक छतरी है (यह कंपनी एक सॉफ्टवेयर / हार्डवेयर कंपनी नहीं है; इसलिए, कम से कम अब के लिए कोई निरंतर पेटेंट मुकदमेबाजी नहीं है, जो नौकरी पैदा करती है अस्थिरता)। मैंने अन्य डेवलपर्स के अनुभवों से इन वर्षों के दौरान अब तक क्या सीखा है और मेरा अनुभव यह है कि वास्तव में एक विकास टीम को जानना है, इसमें समय लगता है, दिन नहीं, न ही सप्ताह, बल्कि कुछ महीने। साक्षात्कार प्रक्रिया के दौरान यदि टीम आपको किराए पर लेना चाहती है, या आपको ज़रूरत है; वे सब कुछ शानदार बनाते हैं, और वे आपको बता सकते हैं कि आप क्या सुनना चाहते हैं। हालाँकि, वास्तविकता अलग है जब आप उस टीम में काम करना शुरू करते हैं और कोड के अंदर खुदाई करना शुरू करते हैं और पूर्ण SDLC प्रक्रिया की ओर बढ़ते हैं। यह तब होता है जब एक डेवलपर के रूप में, आप उस नौकरी की वास्तविकता को देखना शुरू कर देते हैं जो आपको मिली थी। यह वास्तविकता एक कंपनी से दूसरी कंपनी में स्थानांतरित करना चाहती है क्योंकि यह जानना मुश्किल है कि आप जिस कंपनी में जाते हैं वह बेहतर या बदतर होगी। हां, आप Glassdoor समीक्षाएं आदि पढ़ सकते हैं, लेकिन उन ऑनलाइन समीक्षाओं में से कितनी वास्तविक हैं, और HR से नहीं?
नीचे दिए गए मुद्दों से निपटने के लिए सबसे अच्छा तरीका क्या होगा जो इस बात पर विचार करने के लिए शुरू से ही प्रबंधक ने हमेशा बदलने का विरोध किया है, और पिछले डेवलपर्स वर्षों से ऐसा ही कर रहे हैं?
वर्ष के लिए उत्पाद नवाचार की कमी: उत्पाद में बहुत अधिक संभावनाएं हैं और कंपनी को अच्छा राजस्व लाता है, लेकिन उत्पाद ऐसा दिखता है जैसे 20 साल पहले बनाया गया था। कुछ उपयोगकर्ताओं ने शिकायत की है कि उत्पाद उपयोगकर्ता के अनुकूल नहीं है और न ही सहज है, और अन्य ने उल्लेख किया है कि जीमेल जैसे ऐप के लिए उपयोग किया जाता है और समान सुविधाओं के न होने के कारण उत्पाद का उपयोग करते समय निराश हो जाते हैं। यहां मुख्य मुद्दा यह है कि जब आप उत्पाद में बदलाव करने के लिए एक डेवलपर के रूप में प्रयास करते हैं और उत्पाद के मुख्य तत्वों को सिर्फ एक जोड़ी पिक्सल के आसपास स्थानांतरित करना शुरू करते हैं (इसे और अधिक उपयोगकर्ता के अनुकूल, या सहज ज्ञान युक्त बनाने के लिए), प्रबंधक पैनिक, और आपको बताता है। जहां था वहीं वापस रख दिया। यदि आप एक ऐसी सुविधा को जोड़ने का प्रयास करते हैं जो उपयोगकर्ताओं के लिए उत्पादकता को लाभान्वित करेगी, तो प्रबंधक आपको इसे हटाने के लिए कहता है क्योंकि "उपयोगकर्ता का उपयोग उस प्रक्रिया को करने के लिए किया जाता है जिस तरह से यह आदि है।" मुझे लगता है कि आपको परिवर्तन, सुधार और नवाचार के लिए प्रतिरोध मिला (प्रबंधक परिवर्तन के लिए खुला नहीं है, जब आप एक डेवलपर के रूप में लाभ के मजबूत तर्क प्रदान करते हैं)। कंपनी के क्षेत्र में कुछ प्रतिस्पर्धी हैं (उनमें से कुछ उत्पाद अधिक प्रतिस्पर्धी हैं), लेकिन किसी तरह कंपनी ने मौजूदा ग्राहकों को वर्षों तक बनाए रखा है।
परियोजना प्रबंधन समन्वय का अभाव: इसके परिणामस्वरूप, कुछ परियोजनाएं देरी से पहुंचती हैं, बग के साथ और कुछ ग्राहक शिकायत करते हैं (ग्राहक बगों की रिपोर्ट करते हैं), या बजट का उपयोग परियोजना आदि को वितरित करने से पहले बहुत तेजी से किया जाता है। मैंने उन्हें प्रदान किया है। कुछ परियोजना समन्वय युक्तियाँ और विचारों का अब नियमित रूप से उपयोग किया जा रहा है ताकि परियोजनाओं और कार्यों की प्रगति को ट्रैक किया जा सके।
खराब सॉफ्टवेयर डेवलपमेंट प्रैक्टिस: कोड की गंध सबसे अधिक देखी जाती है यदि सभी फाइलें, कोई डॉक्यूमेंटेशन, कोड रिडंडेंसी, फ्रंट एंड टियर और बैक एंड मिक्स एक ही फाइल पर न मिला हो, आउटडेटेड डेवलपमेंट टूल्स, कोई वास्तविक परीक्षण वातावरण और न ही टेस्ट टूल्स (सिर्फ कॉपी और पेस्ट) उत्पादन के लिए देव वातावरण से फ़ाइलें, और फिर मैन्युअल रूप से परीक्षण करें कि चीजें अच्छी और रिलीज़ दिखती हैं)। विकास के अधिकांश उपकरण मैं विकास और परीक्षण के लिए उपयोग करता हूं जहां टीम द्वारा अज्ञात है, क्योंकि टीम केवल कोड विकास के लिए 2 आईडीई का उपयोग करती है और स्रोत नियंत्रण केवल विकास के वातावरण के लिए उपलब्ध है। अन्य डेवलपर्स ने वर्तमान मुद्दों को सुधारने के लिए नवीनतम रूपरेखाओं का उपयोग करने की कोशिश की है, लेकिन प्रबंधक को यह पसंद नहीं है कि "क्या होगा अगर आप छोड़ देते हैं, तो कौन उस कोड को बनाए रखने वाला है ?, चलो इसे छोड़ दें जिस तरह से यह है" उन डेवलपर्स में से कुछ पहले से ही छोड़ दिया और दूसरी कंपनियों में चले गए।
संक्षेप में, मुझे यकीन है कि अन्य कंपनियों में कई डेवलपर्स के साथ भी ऐसी ही स्थिति होती है, लेकिन अलग-अलग परिस्थितियों के कारण, एक डेवलपर किसी अन्य कंपनी में जाने की तुलना में टीम में रहना पसंद कर सकता है, जैसे (नौकरी की सुविधा, कार्य लचीलापन, कंपनी के लाभ, या सिर्फ इसलिए कि एक बेहतर अवसर नहीं आया है)। कोई भी सही कंपनी नहीं है जिसे मैं जानता हूं, लेकिन आप एक डेवलपर के रूप में कैसे व्यवहार करेंगे और इन सभी मुद्दों पर दृष्टिकोण रखेंगे ताकि चीजों को सकारात्मक रखा जा सके और अंततः उत्पाद विकास और सॉफ्टवेयर विकास प्रक्रिया की बेहतरी के लिए बदलाव को बढ़ावा दिया जा सके (चाहे आपके पास कई हों विकास के अनुभव के साल या बस कुछ)? मुझे पता है कि यह पोस्ट लंबी है, लेकिन मैंने अधिक उपयोगी प्रतिक्रिया प्राप्त करने की संभावना बढ़ाने के लिए अतिरिक्त विवरण देना पसंद किया।
आपकी सभी प्रतिक्रिया और समय के लिए बहुत बहुत धन्यवाद