हाल ही में नियुक्त कर्मचारी के रूप में परिवर्तनों का सुझाव कैसे दें? [बन्द है]


75

मुझे हाल ही में एक बड़ी कंपनी (आकार का एक विचार देने के लिए हजारों लोगों) में काम पर रखा गया था। उन्होंने कहा कि उन्होंने मुझे मेरी कठोरता के कारण काम पर रखा और क्योंकि मैं अपनी युवावस्था (i'm 25) के बावजूद C / C ++ प्रोग्रामर के रूप में अनुभवी था।

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

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

क्या आप कभी ऐसी स्थिति में आए हैं और यदि हां, तो आप मुझे क्या सलाह देंगे? क्या यहां काली भेड़ न बनकर चीजों को बदलने का एक सूक्ष्म तरीका है? या मैं सिर्फ अपने जुनून और ऊर्जा को छोड़ दूं?

धन्यवाद।

अपडेट

आपकी कीमती सलाह के बाद, मैं बदलावों का सुझाव देने में सक्षम था और अब टीम का प्रभारी हूं जिसे सबवर्सन बनाना और तैनात करना चाहिए: D आप सभी का धन्यवाद!

6 महीने बाद

मैंने बहुत बेहतर वेतन और अधिक दिलचस्प चुनौतियों के साथ एक अधिक दिलचस्प वातावरण छोड़ दिया और पाया। मैं किसी भी चीज़ के लिए वापस नहीं जाता।


रडार से बाहर न हों: infoq.com/news/2011/02/Technology-Radar-ThoughtWorks
rwong

6
यह महसूस करते हुए कि अभी भी सॉफ्टवेयर डेवलपमेंट कंपनियां हैं जो किसी भी संस्करण नियंत्रण प्रणाली का उपयोग नहीं करती हैं, जो भी मुझे मानवता में विश्वास खो देती है ...
कोनामिमन

जवाबों:


42

मैं अपनी पिछली कंपनी में ऐसी ही स्थिति में था, जहां मैं 5 साल से था। जब मैं 2004 में शामिल हुआ, तो वे थे:

  • अभी भी अपने डेटाबेस के लिए माइक्रोसॉफ्ट एक्सेस का उपयोग कर रहे हैं (यहां तक ​​कि महत्वपूर्ण व्यवसाय भी)
  • विकास के लिए विजुअल बेसिक 6 या एक्सेस / एक्सेल VBA का उपयोग करना
  • इन-हाउस के विकास संसाधन का उपयोग करने के बजाय बहुत से तृतीय-पक्ष का उपयोग करना (व्यवसाय प्रबंधकों ने अपनी स्वयं की विकास परियोजनाओं का नेतृत्व किया और 90% समय आईटी के ज्ञान के बिना निविदा के अनुबंधों को लगा दिया)
  • हांफना कोई संस्करण नियंत्रण नहीं है।

जब मैंने पिछले साल छोड़ दिया, तो कंपनी थी:

  • .NET और C # का विशेष रूप से उपयोग करना
  • सभी एक्सेस डेवलपमेंट को बंद कर दिया था
  • संस्करण नियंत्रण के लिए SVN का उपयोग करना
  • 2 गोमांस SQL ​​सर्वर बक्से थे और मौजूदा Access डेटाबेस को SQL में माइग्रेट कर रहे थे
  • सभी विकास इन-हाउस टीमों के माध्यम से आए और केवल संसाधन सीमित होने पर निविदा करने के लिए बाहर चले गए

उस समय जब मैं 21 साल का नहीं हुआ था, और विकास टीम में अगला युवा 30 साल का था। मैंने यह सब खुद नहीं किया। आईटी प्रबंधक उसी समय कंपनी में शामिल हो गया था, और आईटी के माध्यम से सभी विकास लाना चाहता था।

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

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

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

4 सप्ताह बाद मेरा सिस्टम 10 स्थानों पर पायलट में था, और 6 महीने बाद यह लाइव हो गया। एक साल बाद उन्होंने तीसरे पक्ष के अनुबंध को रद्द कर दिया, नेटवर्क से इसके सभी निशान हटा दिए, और हमारे इन-हाउस सिस्टम के लिए एक बड़ी वृद्धि की आवश्यकता के लिए हमारे पास आए।

आपको मेरी सलाह:

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

20
"मैंने अपने खाली समय के लगभग 2 महीने एक नई प्रणाली लिखने में बिताए , और इसे आईटी प्रबंधक को प्रस्तुत किया, और लागत बचत को समझाया"। हाँ, आप मुफ्त में काम करने की लागत की बचत! यदि यह £ 100k + बचाता है तो आपको इसे £ 50k के लिए बेच देना चाहिए!

अगर मुझे लगता है कि मैं सुसाइड किए बिना ही उसके साथ भाग सकता था!

3
@ जॉन आपको इसे आईटी मैनेजर को प्रस्तुत करना चाहिए, लागत बचत के बारे में बताएं, उन्हें इसे मुफ्त में दें ... और कुछ महीने बाद लागत बचत को अपने मूल्य के उदाहरण के रूप में उद्धृत करते हुए एक बड़ा वेतन वृद्धि के लिए कहें
MarkJ

27

उन्होंने कहा कि उन्होंने मुझे मेरी कठोरता के कारण काम पर रखा और क्योंकि मैं अपनी युवावस्था (i'm 25) के बावजूद C / C ++ प्रोग्रामर के रूप में अनुभवी था।

अधिक संभावना है क्योंकि आप सस्ते हैं।

क्या आप कभी ऐसी ही स्थिति में रहे हैं

हाँ।

आप मुझे क्या सलाह देंगे

छोड़ना।

क्या यहां काली भेड़ न बनकर चीजों को बदलने का एक सूक्ष्म तरीका है?

हो सकता है। परिवर्तनों का परिचय दें और प्रदर्शित करें कि वे सभी के लिए चीजों को कैसे सुधारते हैं। आपके द्वारा इसे कई बार किए जाने के बाद, आपको उन लोगों से सराहना मिल सकती है जो खो नहीं गए हैं।

या मैं सिर्फ अपने जुनून और ऊर्जा को छोड़ दूं?

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


5
उसके लिए बहुत कुछ कहा जाना चाहिए। अब छोड़ दो और अटक मत जाना।
प्रीत संघ

7
यह शायद ही कोई जवाब हो।
रिकेट

5
यदि मैं अब बदलूं, तो मैं अपने अगले साक्षात्कार पर क्या कहने जा रहा हूं? "मैंने छोड़ दिया क्योंकि वे 60 के दशक में वापस रहते थे" => मैं शायद मुझे किसी ऐसे व्यक्ति के रूप में देखूंगा जो कोशिश करने से पहले भी हार मान लेता है। शायद मैं भविष्य में छोड़ दूंगा, लेकिन मुझे लगता है कि मुझे कम से कम कुछ समय के लिए प्रयास करना चाहिए।
--३On

15
तुम युवा हो। यह कहने के लिए पूरी तरह से स्वीकार्य है कि आप जो करना चाहते थे उसके लिए कंपनी अच्छी तरह से फिट नहीं थी और आपने गलती की।
प्रीत संघ

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

19

उदाहरण के लिए लीड । समय पर आकस्मिक रूप से छोटे परिवर्तन। एक सहयोगी पर खींचो और उन्हें कुछ डेमो। अगर उन्हें यह नहीं मिलता है तो कभी भी दोबारा कोशिश न करें।

इसमें समय लगेगा। बस लोगों को उनके आराम क्षेत्र से बहुत जल्दी नहीं खींचना चाहिए।

दुख की बात है लेकिन इसीलिए आपके यहाँ और वे नहीं हैं।

उदाहरण के लिए। स्थानीय स्तर पर संस्करण नियंत्रण सेट करें और उन्हें दिखाएं कि यह कैसे मदद कर सकता है। फिर उन्हें कुछ संसाधन (सरल पढ़ने) दें जो आपको वापस कर सकते हैं।

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


3
ओह। अपने पैसे खर्च, क्या एक मग। जब तक आपको नहीं लगता है कि आपको बढ़ी हुई उत्पादकता से वेतन में वृद्धि मिलेगी, तो आप वास्तव में क्या हासिल कर रहे हैं?

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

आसान कैसे? जब तक वे पहचानते हैं कि आप अधिक काम कर रहे हैं, परेशान क्यों हैं?

@ मैं इस सरल तर्क का उपयोग अधिक उत्पादकता => सीखने के लिए अधिक समय => अधिक विपणन योग्य कौशल => (ए) बेहतर इंजीनियर (मेरे लिए) (बी) बेहतर पैसा (सी) बेहतर परियोजनाओं
प्रीत संघ

1
@ जॉन। अन्य उत्तर यह है कि मेरे उपकरण और उन पर महारत है जो मैं बेचता हूं। यह निश्चित रूप से मेरे परामर्श के दिनों में था। एक उपकरण खरीदने में सौ डॉलर का एक जोड़ा किताबें खरीदने के लिए अलग नहीं है।
प्रीत संघ

15

मैं एक बूढ़ा व्यक्ति (51) हूं और मेरे पास हर नौकरी में यही समस्या है। शायद यह सिर्फ कमरे में हमेशा सबसे चतुर आदमी होने से आता है! :-) गंभीरता से, हालांकि, जब आप जानते हैं कि यह कैसे करना है और वे नहीं करते हैं, तो आप अक्सर सोचते हैं, "अरे, मैं हर किसी को यह नई और बेहतर तकनीक दिखाऊंगा और वे सभी प्रभावित होंगे और अंदर कूदना चाहते हैं। इसका उपयोग करने के लिए। " लेकिन वास्तविक जीवन में, 90% समय, आप लोगों को बेहतर तरीके से दिखाते हैं, और वे बहाने की एक लंबी सूची के साथ आते हैं कि जिस तरह से वे यह सब कर रहे हैं वह बेहतर है। जब आप प्रदर्शित करते हैं कि उनके कारण मान्य नहीं हैं, तो वे नए, यहां तक ​​कि लामर कारणों के साथ आते हैं। मेरे पास बहुत बार है कि मैं '

यहां तक ​​कि अगर आप वास्तव में एक प्रतिभाशाली हैं, तो आपको यह स्वीकार करना होगा कि जब तक आप इसे साबित नहीं करते, तब तक कोई और नहीं जानता। मुझे क्रिश की याद आई, मेरे एक दोस्त ने, जिसने एक कंपनी के साथ 10 साल बिताने के बाद एक नया काम शुरू किया। नई नौकरी शुरू करने के कुछ समय बाद, वह एक बैठक में थे जहाँ वे कुछ तकनीकी समस्या पर चर्चा कर रहे थे और उन्होंने अपने सुझाए गए समाधान की पेशकश शुरू कर दी। फिर किसी और ने बाधित किया और कहा, "हाँ, धन्यवाद। बॉब, आप क्या सोचते हैं?" पहले तो वह नाराज़ हो गया: उसे सही जवाब पता था, लेकिन किसी को परवाह नहीं थी! इसके बजाय वे किसी ऐसे व्यक्ति की राय के साथ गए जो पूरी तरह से कम जानता था। लेकिन तब उन्हें एहसास हुआ कि, अरे, मेरी पुरानी नौकरी पर, मैंने किसी ऐसे व्यक्ति के रूप में अपनी प्रतिष्ठा बनाई थी जो जानता था कि वह किस बारे में बात कर रहा है, इसलिए जब मैंने बात की, तो लोगों ने सुनी। यहाँ, मेरे पास अभी तक कोई प्रतिष्ठा नहीं है, इसलिए कोई भी मेरी परवाह नहीं करता है।

मैं अपनी वर्तमान नौकरी में 2 साल रहा हूँ और यह केवल पिछले कुछ महीनों में है कि mhy राय में कोई वास्तविक वजन होना शुरू हो गया है। आपको धैर्य रखना होगा।

दूसरी तरफ, नए लोगों के पास अक्सर सुधार के लिए एक लाख सुझाव होते हैं जो वास्तव में अव्यवहारिक होते हैं, क्योंकि वे अभी तक संगठन के बारे में पर्याप्त नहीं जानते हैं और इसलिए वे नहीं जानते कि चीजों को जिस तरह से किया जा रहा है। कभी-कभी लोग 20 वर्षों तक कुछ इसी तरह करते रहते हैं, क्योंकि यह हमेशा ऐसा ही होता है और कभी किसी ने बेहतर तरीके से देखने के लिए नहीं सोचा; लेकिन कभी-कभी लोग 20 वर्षों तक कुछ इसी तरह करते रहते हैं क्योंकि अनुभव ने इसे करने का एक अच्छा तरीका दिखाया है और हर बार जब वे कुछ अलग करने की कोशिश करते हैं तो यह एक आपदा है। इसलिए इन लोगों को बेवकूफ बनाने के लिए बहुत जल्दी मत बनो। अपने शानदार नए सुझाव को सामने लाने से पहले जानें कि वे इसे पुराने तरीके से क्यों कर रहे हैं। मैंने अपने जीवन में बहुत बार जब मैंने '


आपका बहुत बहुत धन्यवाद। आपने यह वर्णन नहीं किया होगा कि मैं क्या अधिक सटीक महसूस करता हूं;) मैं अपना सर्वश्रेष्ठ प्रदर्शन करूंगा, लेकिन यह कठिन होगा, मैं एक बहुत ही उन्मत्त व्यक्ति हूं।
ेरेऑन

12

उन सहयोगियों को खोजें जो कंपनी को बेहतर बनाना चाहते हैं।

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

अपने भविष्य के साक्षात्कार के दौरान जोएल टेस्ट का उपयोग करें । याद रखें कि आप कंपनी का साक्षात्कार भी कर रहे हैं।


10

मेरी पहली सलाह बहुत जल्द बहुत ज्यादा बदलने की कोशिश नहीं है। पहले एक अच्छे विश्वसनीय डेवलपर के रूप में ख्याति प्राप्त करें जो काम कर सकते हैं। अभी नौसिखिया के रूप में, आपके द्वारा सुझाए गए कुछ भी संदिग्ध हैं; वे अभी तक आपको नहीं जानते और आपका सम्मान करते हैं। उस सम्मान को अपने पहले कदम के रूप में प्राप्त करें। फिर परिवर्तनों को शुरू करने का समय है।

आप ध्यान से जमीन चुनें। नई तकनीक नहीं संस्करण नियंत्रण के साथ शुरू करो। क्योंकि वास्तव में यह सबसे महत्वपूर्ण बदलाव है। आप अपने कोड के साथ भी ऐसा कर सकते हैं और फिर यह सुनिश्चित कर सकते हैं कि जब आपको किसी पुराने संस्करण को वापस करना है या पता लगाना है कि क्या बदल गया है, तो आप लोगों को जानते हैं कि यह आकस्मिक बातचीत में कितना आसान था।

अपने अधिक वर्तमान ज्ञान का उपयोग उस व्यक्ति के रूप में करें जो चमकता है और फिर लोग पूछना शुरू करेंगे कि आप यह कैसे कर रहे हैं। जब पीसी पहली बार कार्यस्थल में आई, तो मैंने एक सरकारी ऑडिट एजेंसी के लिए काम किया। वरिष्ठ अपने स्वयं के कंप्यूटर (सचिवों के लिए काम कर रहा था क्योंकि) के खिलाफ सभी बहुत ज्यादा थे। जूनियर्स ने अल्टेह पहले कंप्यूटरों को पकड़ लिया और वे काम करना शुरू कर दिया जो वरिष्ठ लोटस 1-2-3 और हार्वर्ड ग्राफिक्स के साथ नहीं कर सकते थे और अचानक, बड़े लोगों को दिलचस्पी थी क्योंकि वे युवा लोग बहुत वरिष्ठ प्रबंधन का ध्यान आकर्षित कर रहे थे।

संगठनात्मक संस्कृति में परिवर्तन एक तकनीकी मुद्दा नहीं है, यह एक राजनीतिक मुद्दा है। ऑफिस की राजनीति को मैनेज करने पर कुछ पढ़ें। आपको उच्च स्तर पर राजनीतिक समर्थन की आवश्यकता है।


6

मुझे अपनी वर्तमान नौकरी में ऐसी ही स्थिति का सामना करना पड़ा। मुझे एक टीम पर काम करने के लिए सीधे स्नातक से सीधे बाहर काम पर रखा गया था जो कि ज्यादातर इंजीनियर हैं जो यहां 15+ साल से हैं। परिवर्तन करना आसान नहीं था (मैं अभी भी कुछ चीजों के लिए जोर दे रहा हूं), लेकिन यह संभव है।

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

इस कहानी से मैंने जो सबक सीखा वह यह है: यदि आपको लगता है कि आप कुछ सुधार कर सकते हैं, तो इसके बारे में अपने प्रबंधक से बात करें। यदि वे इस पर संसाधनों को खर्च नहीं करना चाहते हैं, तो इसे अपने दम पर करें और उन्हें साबित करें कि आपका विचार वैध और उपयोगी है। एक विचार के लिए यह कहना बहुत आसान है कि कोई व्यक्ति उस चीज़ की तुलना में प्रस्ताव करता है जिसे आप अपने सामने देखते हैं जिसका स्पष्ट मूल्य है।

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

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


1
बढ़िया कहानी और पाठ! +1 :)
Ricket

4

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

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


4

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

हालांकि, किसी भी परिस्थिति में कंपनी कोड को एक मशीन पर न डालें, जिसे आप व्यक्तिगत रूप से अपनाते हैं या घर ले जाते हैं । क्योंकि तब आप पा सकते हैं कि, एक नायक होने के बजाय, आप एक वकील (सबसे अच्छा) या कानून प्रवर्तन (सबसे खराब) से डेस्क के गलत पक्ष पर हैं।


4
जब तक उन्होंने आपको काम करने के लिए एक लैपटॉप नहीं दिया है, जहां आपके पास वैसे भी स्रोत कोड है, और वे आपसे इसे अपने साथ घर ले जाने की उम्मीद करते हैं ...
धान

शायद, हालांकि मुझे ऐसा करने में संकोच होगा। संकट अक्सर दोष और पुनरावृत्ति की ओर ले जाते हैं। और यदि व्यक्ति (आमतौर पर आईटी या विकास प्रबंधक) जिसे कंपनी की संपत्ति (स्रोत कोड) की रक्षा नहीं करने के लिए दोषी ठहराया जाना चाहिए, तो इस तथ्य से ध्यान हटा सकता है कि "इस व्यक्ति ने कंपनी के स्रोत कोड की घरेलू ऐतिहासिक प्रतियां क्यों लीं?" वह / वह शायद करेंगे। HR स्रोत नियंत्रण को नहीं समझता है, लेकिन बौद्धिक संपदा की चोरी को समझता है। बेशक, देव मेघ हमेशा कह सकते हैं "मैंने पंगा लिया और इस बच्चे ने हमें बचाया" ...

@ हम जिस देश में रहते हैं, वहां हमारे पास कर्मचारियों के लिए सबसे अधिक सुरक्षात्मक कानून हैं। किसी को गोली मारना वास्तव में कठिन है, तब भी जब वह कुछ गलत करता है। यदि आप एक लैपटॉप पर गोपनीय डेटा ढीला करते हैं जो आपको दिया गया था, तो यह अभी भी बहुत संभावना नहीं है कि आप निकाल दिए जाएं। अजीब लग सकता है, लेकिन यह भी बताता है कि इतने लोग अपने काम को अच्छी तरह से करने की परवाह क्यों नहीं करते ...
ereOn

3

दूसरे जूनियर डेवलपर से आ रहा है ... क्या आपके पास महान लोग हैं? क्या आपके पास आत्म-संयम और यह समझने की उत्कृष्ट समझ है कि किसी विचार का प्रस्ताव करना उचित नहीं है, और उस विचार को कैसे बेचना है? यदि आप करते हैं, तब भी आप अन्य लोगों को यह बताने के लिए "कि लड़का" हो सकता है कि आप अपनी योग्यता साबित किए बिना अपना काम कैसे करेंगे।

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

यदि मेरा फिक्स विशेष रूप से निफ्टी है, तो मैं इसे साझा करता हूं, और कहता हूं "अरे दोस्तों, मैंने यह अच्छा उपकरण बनाया है, यह एक्सवाई और जेड को स्वचालित करता है और इस दूसरी चीज को तेजी से करता है।" उस पर अपना नाम रखो। दोहराएँ। विश्वसनीयता की समस्या कुछ महीनों में हल हो जाती है यदि आप अपने स्तर के लिए उच्च प्रदर्शन करने वालों में हैं, और आपके ऊपर के लोग आपके सुझावों के लिए अधिक खुले होंगे यदि आप यह समझाने के लिए तैयार हैं कि आपका विचार क्यों अच्छा है और यह उनकी समस्याओं को कैसे हल कर सकता है।

हाल ही में मैं ऊपरी प्रबंधन के लिए नए विचारों को प्रस्तावित करने में सक्षम रहा हूं जो ज्यादातर स्वीकार किए जाते थे, क्योंकि मैंने अपने तर्क को समझाने, उनकी प्रतिक्रिया सुनने और अपने पिछले काम की विश्वसनीयता के लिए समय लिया।

ADDENDUM: यदि आपका प्रबंधक आपके व्यवहार पर सवाल उठा रहा है ... इस सामान को तब तक न करें जब तक उसे नहीं लगता कि आपका प्रदर्शन कम से कम "शीर्ष 25%" पर रहता है, तो सुनिश्चित करें कि आपके बॉस हर तरह से साथ आने से पहले आपके साथ खुश हैं। चतुर सुधार जो आपको उस शीर्ष% में उच्च धक्का देते हैं या वह सोचेंगे कि आप समय बर्बाद कर रहे हैं। यदि आप सकारात्मक प्रदर्शन प्रतिक्रिया प्राप्त करते हुए नई उपयोगिताओं और समाधानों को बाहर निकाल रहे हैं, फिर भी वह अभी भी micromanaging पर जोर देता है तो आपको एक समस्या हो सकती है जो इस विषय के दायरे से बाहर है।


2

मिश्रण।

जैसा कि आपने कहा, आप काली भेड़ नहीं बनना चाहते हैं। हालाँकि, जब से आप (अपने आप को) कुछ उपयोगी बदलाव जोड़ना चाहते हैं:

पृष्ठभूमि में मान जोड़ें।

Svn / hg / git में लोगों के कोड की जांच करने के लिए cronjobs सेट करें। अपने स्वयं के समय पर अपने स्वयं के उपकरण बनाएं, जो विकास के प्रयासों को बढ़ा सकते हैं। विशेष रूप से, आप उस कंपनी में सुधार करना चाहते हैं जिसे आप अपने सीनियर्स को अपने क्यूबिकल में दिखा सकते हैं। और यहाँ क्यों है:

वाह कारक

यदि आप कह सकते हैं "हे ऐलिस, तुम्हें पता है कि बॉब ने कैसे निर्माण को तोड़ा? मैं उनके संपादन को वापस कर सकता हूं, और निर्माण फिर से काम करता है"। और जब आपके वरिष्ठ पवित्र गंदगी कहते हैं, तो शायद आप उनमें इतना जुनून जगाएंगे कि वे आपकी नई प्रथाओं को आगे बढ़ाएंगे या कम से कम प्रोत्साहित करेंगे।


2

यहाँ मेरी सलाह है।

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

जब मैंने शुरू किया था, तो हम विज़ुअल स्टूडियो 2005 का उपयोग कर रहे थे, जब वीएस 200 8 काफी समय से बाहर था, लेकिन मेरे बॉस को पैसा मिलाना हमारे सभी डेवलपर्स के लिए अपग्रेड आसान नहीं था, मुझे धीरे-धीरे इस विचार को आगे लाना था, "अगर हम ऐसा कर सकते हैं तो यह अच्छा होगा", लेकिन इससे पहले कि मैं इसे अपने बॉस के पास लाऊं, सुनिश्चित करें कि अन्य डेवलपर्स विचार पर अच्छे होंगे, क्योंकि वे इसका उपयोग करने वाले और लोगों के एक समूह वाले लोग होंगे। एहसान किसी एक व्यक्ति के फैसले की तरह कम लगेगा।

मुझे लगता है कि अपने बॉस को केवल विचार देने के बजाय, शायद धीरे-धीरे कोई भी संभावित बदलाव लाएं, क्योंकि मुझे लगता है कि यदि आप उन विचारों का सुझाव देते हैं जो कंपनी को बेहतर तरीके से बदल देंगे, तो यह भी दर्शाता है कि आप अपनी नौकरी की परवाह करते हैं और दिखाता है कि आप योजना बनाते हैं वहां घर बनाने पर।

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


1

एक जीवन भर का अवसर हो सकता है - जिस तरह से एक कंपनी 25 पर काम करती है उसे बदलना। अगर वे विरोध करते हैं और हर समय दुश्मनी दिखाते हैं तो यह आपके लिए जगह नहीं है।

याद रखें, आपका साक्षात्कार दो तरह की प्रक्रिया थी। आप महसूस कर सकते हैं कि वे कितने परिवर्तनशील और प्रतिरोधी थे।

Ps, मैं 25 वर्ष का हूं और जानता हूं कि आप कैसा महसूस करते हैं। आप शायद सीखने के लिए और अपने सहयोगियों की तुलना में नई चीजों को आज़माने के लिए बहुत अधिक उत्सुक हैं। फिर भी, मुझे जो .NET परिचय हो रहा है, उस पर वापस आना चाहिए;)


0

जब आप केवल ग्रोएल जोएल स्पोल्स्की द्वारा हो रही चीजें पढ़ें ।

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

जब आप किसी संगठन में काम कर रहे हों, तो यह निराशाजनक हो सकता है कि जोएल टेस्ट में कम स्कोर करता है । आपका कोड कितना भी अच्छा क्यों न हो, आपके सहकर्मी ऐसा बुरा कोड लिखते हैं जिसे आप प्रोजेक्ट से जुड़े होने के लिए शर्मिंदा होते हैं। या प्रबंधन किस कोड को लिखने के बारे में बुरा निर्णय ले रहा है, इसलिए आप बच्चों के लिए रिटायरमेंट-प्लानिंग गेम के एएस / 400 संस्करण में अपनी प्रतिभा को बर्बाद करने के लिए मजबूर हैं।

... एक बुरी टीम पर जीवन के साथ काम करना अनर्थकारी हो सकता है। लेकिन नीचे से अपनी टीम में सुधार के लिए रणनीतियां हैं, और मैं उनमें से कुछ को साझा करना चाहता हूं ...


1
यह पोस्ट वास्तव में अच्छा है, लेकिन इसे पढ़ते समय एक से अधिक कठिन हो सकता है ...
यूओओ जूल

-1

प्रबंधन के साथ काम करें; "दुष्ट मत जाओ"। प्रक्रिया के भीतर काम करें, और चीजों को उन शब्दों में रखें जिन्हें लोग समझेंगे, जैसे "लागू करना svn हमें एक सर्वर पर जगह देगा, दो दिन सेटअप करने के लिए, और हमें इसे वापस करने की आवश्यकता होगी, लेकिन हम x, y, z प्राप्त करेंगे। , जो हमें बहुत सारा पैसा बचा सकता है। ”


हमारे स्तर पर, पैसे को ध्यान में रखने के लिए कुछ नहीं है। हम भी कीमतों को देखने के लिए नहीं कहा जाता है। मैं इसे "टाइम-गेन तर्क" से बदल दूंगा। ;)
ेरेऑन 31'10

-1

बाहर निकलें। वहाँ बहुत सारी नौकरियां हैं। यह कुछ बेतरतीब कंपनी को ठीक करने के लिए आपका काम नहीं है जो आपको किराए पर देने के लिए हुआ है। वे अपने तरीके को पसंद करते हैं, अन्यथा वे एक नया सीटीओ या कुछ और काम पर रखते हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.