क्या एक (जूनियर) डेवलपर को अपने विकास / आईटी टीम में बेहतर प्रक्रियाओं और प्रथाओं के लिए धक्का देने की कोशिश करनी चाहिए?


108

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

मेरी टीम काफी छोटी और कुछ हद तक नई (<3 साल पुरानी) है। उनमे कमी है:

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

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

क्या यह (कनिष्ठ) डेवलपर के प्रयास के लायक है कि समय के लिए ऊपर जाने के लिए प्रयास करें और धक्का दें? या "अपनी लेन में रहना" और विकास पर ध्यान केंद्रित करना और प्रक्रिया की परिभाषा, और प्रबंधन के लिए अनुकूलन के थोक को छोड़ना सबसे अच्छा है?


10
मैंने देखा कि आपका एक टैग स्क्रम है। क्या आपकी टीम एक स्क्रैम टीम है? और यदि हां, तो क्या वे पूर्वव्यापी पकड़ रहे हैं?
डैनियल

10
क्या कोई कारण है कि आप "हम" के बजाय "वे" का उपयोग करते हैं? उदाहरण के लिए "मेरी टीम काफी छोटी और कुछ हद तक नई (<3 साल पुरानी है। उनमें कमी है")
थॉमस कोएले

40
सिर्फ एक FYI करें, यदि आपने कई कंपनियों के लिए काम किया है, तो संभवत: आप जूनियर नहीं हैं।
केविन

11
आपको क्या लगता है कि आपके द्वारा सूचीबद्ध चीजें "बेहतर" हैं, न कि केवल नवीनतम समय बर्बाद करने वाली सनक? क्या आप हर एक के लिए एक उचित मामला बना सकते हैं?
jamesqf

11
"प्रबंधन सुधारों के कार्यान्वयन के लिए खुला है [..]" , जो काफी हद तक अप्रासंगिक है, अधिक महत्वपूर्ण यह है कि आपकी टीम के बाकी सदस्य इसके लिए खुले हैं या नहीं। यदि वे नहीं कर रहे हैं, तो प्रबंधन में खरीद नहीं है, लेकिन नहीं टीम में खरीद अपनी टीम के बाकी के साथ एक प्रतिकूल संबंध के लिए एक सड़क है।
मार्क रोटेवेल

जवाबों:


179

अब तक के अच्छे जवाब, लेकिन वे सभी आधारों को कवर नहीं करते हैं।

मेरे अनुभव में, कॉलेज के बाहर रहने वाले कई लोगों को शानदार सैद्धांतिक ज्ञान है - मेरे लिए या कई अन्य वरिष्ठ नागरिकों के लिए दशकों से एक जीवन जीने के लिए सॉफ्टवेयर तैयार करना।

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

बिंदु में मामला: एक आवेदन जो मैंने बहुत समय पहले काम किया था, एक शानदार ओओ सिद्धांतकार द्वारा डिज़ाइन किया गया था, जो हर जगह लागू किए गए बहुत सारे पैटर्न के साथ टी को ओओ सिद्धांतों और सिद्धांत का पालन करने के लिए तैयार किया गया था।

यह सॉफ्टवेयर डिजाइन का एक शानदार नमूना था।

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

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

यह वास्तुकार एक विश्वविद्यालय के प्रोफेसर थे, जिनके नाम के विषय के बारे में कई किताबें थीं। उन्होंने कभी भी एक कमर्शियल प्रोजेक्ट पर प्रोग्रामर के रूप में काम नहीं किया।

व्यावहारिक अनुभव निर्माण सॉफ्टवेयर वाले लोगों ने महसूस किया होगा कि एक ऐसी विकृति जो डिजाइन को अनिवार्य रूप से आगे ले जाएगी और अधिक व्यावहारिक दृष्टिकोण लेगी, जिससे एक प्रणाली को बनाए रखना आसान होगा और बेहतर प्रदर्शन भी होगा।

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

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

सुझाव देने से डरो मत कि चीजों को बेहतर तरीके से किया जा सकता है, लेकिन हमेशा यह सुनिश्चित करें कि आपको पता नहीं है कि यह सभी स्नॉट-नोज्ड किड के रूप में नहीं आया है, बल्कि एक सहकर्मी के रूप में है जो केवल सीखने के लिए नहीं बल्कि कोशिश कर रहा है कंपनी की बेहतरी के लिए प्रक्रियाओं को बेहतर बनाने में मदद करें, न कि केवल सैद्धांतिक शुद्धता के लिए।


19
मैं आपके अवलोकन से अधिक सहमत नहीं हो सका। अभ्यास अब तक का सबसे अच्छा तरीका है यह जानने के लिए कि क्या काम करता है, और फिर भी हमेशा अधिक होता है, और अन्य।
Kain0_0

226
एक परियोजना पागलपन की हद तक, जटिल भयानक बदलने के लिए है, तो यह है नहीं एक "सॉफ्टवेयर डिजाइन के शानदार टुकड़ा"।
स्टीव चैमिलार्ड

85
यह जवाब यह ध्वनि की तरह बनाता है जैसे ओओपी ज्ञान का एक निकाय है जिसे शिक्षाविदों का जुनून है, जबकि उद्योग "बेहतर जानता है"। मेरे अनुभव में, यह दूसरा तरीका है: शिक्षाविद OOP के बारे में बहुत कम परवाह करते हैं, जबकि बहुत सी कंपनियां अभी भी इसके प्रति आसक्त हैं। शिक्षाविद खुद को अधिक कालातीत लेकिन अस्पष्ट अवधारणाओं के साथ चिंतित करते हैं (जिनकी कीमत अक्सर उद्योग द्वारा सराहना की जाती है)।
थियोडोरोस चट्जीगानियाकिंस

13
इसके अलावा, उम्मीद है कि वरिष्ठ इंजीनियर फैंस से सावधान रहें ।
जॉन वू

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

43

हाँ लेकिन बहुत देखभाल के साथ!

मैं स्पष्ट कर दूं।

आपको सॉफ्टवेयर की आदत में सुधार करने का प्रयास करना चाहिए। यदि आप कोड / टीम / व्यवसाय / परियोजना / प्रबंधन को देखते हैं और आपकी पहली प्रतिक्रिया स्नान करना है, तो यह रहने योग्य नहीं है। यदि आपकी पहली प्रतिक्रिया हाँ चिल्लाना है! ... और फिर शिकायत करें जब आप कार्यालय से बाहर निकले हैं, तो आपको अपने घर को अधिक रहने योग्य बनाने की आवश्यकता है। इसकी एक भावना है, और आप इसे जान पाएंगे।

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

समस्या

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

व्यापक परिवर्तन के बाद हालांकि कोई भी, शायद कार्यान्वयनकर्ता को छोड़कर, जानता है कि क्या उम्मीद की जानी चाहिए। संक्षेप में हर किसी को सिस्टम के इस हिस्से में एक न्योफाइट स्तर पर रीसेट किया गया है। यह अच्छा नहीं है। Neophytes को नए नियम सीखने में समय लगता है। उस समय में नियोफ़ाइट्स गलतियाँ कर रहे हैं क्योंकि वे अभ्यास नहीं कर रहे हैं। वे गलतियाँ उस प्रणाली का हिस्सा बन जाती हैं, जिसे अब आपको उसके साथ रहना होगा और उसके पास नहीं है जहाँ अब चिंगारी है।

एक रास्ता आगे

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

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

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

अब तीन चीजें हुई हैं:

  • आपने सिस्टम में सुधार किया है,
  • आपने सिस्टम को बदलने का अनुभव प्राप्त किया है
  • टीम ने आपको सिस्टम को सफलतापूर्वक बदलने के लिए देखा है।

अब सुधार करने के लिए एक और चीज़ चुनें, जैसे-जैसे आपका अनुभव बढ़ता जाएगा और जैसे-जैसे आप कम लटकने वाली समस्याओं को खत्म करेंगे, आप सिस्टम में कठिन मुद्दों का सामना करना शुरू करेंगे, लेकिन कम से कम अब जब आप कहेंगे कि हमें एक्स को बदलना होगा:

  • आप जानते हैं कि परिवर्तन प्रणाली को कैसे प्रभावित करेगा
  • आप जानते हैं कि यह क्या समस्याएं उत्पन्न करेगा (किन नियमों को पुनः प्राप्त करने की आवश्यकता है)
  • आप जानते हैं कि परिवर्तन को लागू करने के मुद्दों को ठीक करने या सुधारने के कुछ तत्काल तरीके हैं
  • आपके आसपास के लोग जानते हैं कि आप सिस्टम के जानकार हैं, और इसे सफलतापूर्वक बदलने में सक्षम हैं

वहाँ से सहमत होने के लिए बहुत सारे। तनाव के लायक एक बात यह है कि कोई कोडबेस या प्रक्रिया सही नहीं है; सब कुछ हमेशा एक समझौता है। और जितना हो सकता है आप सब कुछ दूर चकना चाहते हैं और फिर से शुरू कर सकते हैं, जैसा कि आप कहते हैं, आईएमई यह आमतौर पर छोटे कदमों से धीरे-धीरे विकसित करना बेहतर है। इस तरह आप सभी को अपने साथ ला सकते हैं, और मौजूदा ज्ञान को खोने से बचा सकते हैं। महत्वपूर्ण बात यह जानना है कि आप कहाँ जाना चाहते हैं; इस तरह, आप मौके पा सकते हैं और अवसरों को उठा सकते हैं।
gidds

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

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

20

हाँ तुम कर सकते हो। परंतु...

तुम्हें सावधान रहना होगा।

अपने करियर की शुरुआत में (बहुत समय पहले) मैं भाग्यशाली था / अशुभ कुछ महीनों के पुराने प्रोजेक्ट में "जूनियर" के रूप में।

पहली चीज़ के रूप में, मैंने देखा (OMG) कोई कोड रिपॉजिटरी नहीं थी! मेल द्वारा ज़िप फ़ाइलों को एक दूसरे को भेजकर कोड के सभी मर्ज मैन्युअल रूप से किए गए थे।

इसलिए मैं अपने नए प्रबंधक के पास गया और सुझाव दिया कि हमारे पास एक भंडार होना चाहिए। उत्तर था: ठीक है, इसे व्यवस्थित करें ...।

तो बिना मदद के एक कोड रिपॉजिटरी का आयोजन करना कंपनी में नया था, अब यह एक विनम्र अनुभव था।

जब मैंने इसे स्थापित किया, (झटका) कोई भी इसका उपयोग नहीं करना चाहता था। इसलिए मैंने चीजों को साथ लाने की कोशिश की और सौभाग्य से मेरे प्रबंधक ने समझा कि मेरा समर्थन है।

लेकिन इसका परिणाम यह हुआ कि मुझे अच्छी तरह से पसंद नहीं किया गया और दुर्भाग्य से स्रोत नियंत्रण प्रणाली से प्राप्त एक उपनाम मिला।


तो इस पर मेरी राय है, पहले अपने टीम के सदस्यों को महसूस करें, कि उन्हें क्या लगता है कि अगला सेट करना महत्वपूर्ण है।

हो सकता है कि उनके पास भी आपकी तरह एक सूची हो। हो सकता है कि उनके पास हालांकि सब कुछ हो और वे सूची में उस "बात" को करना चाहते थे। शायद वे .... (जो भी) ...।

पूरी टीम को गठबंधन करना होगा।

लेकिन अगर वे नहीं हैं, तो आप अभी भी पेशेवर रूप से काम कर सकते हैं। और दिमाग वाले लोगों की तरह खोजें और काम करें कि आप कैसे सोचते हैं कि यह किया जाना चाहिए। यदि यह अच्छे परिणाम लाता है, तो अधिक लोग आपके साथ काम करेंगे, अंततः यह "प्रक्रिया" बन जाएगा।

कोड के साथ, विकास प्रक्रियाओं के लिए समान: निरंतर सुधार की आवश्यकता है।

तो हां, आपको हमेशा सुधार करने की कोशिश करनी चाहिए, जो कि सुधार करना संभव है।

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


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

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

17
"दुर्भाग्य से एक उपनाम मिलता है जो स्रोत नियंत्रण प्रणाली से प्राप्त होता है।" LOL मुझे आशा है कि आपने गिट नहीं लिया।
B --овиЈ

Git अभी तक आसपास नहीं था।
रॉबर्ट आंद्रेजुक

10
@ BversовиЈ शायद उन्होंने उसे "विध्वंसक" ... :-)
अलेक्जेंडर

14

क्या यह (कनिष्ठ) डेवलपर के प्रयास के लायक है कि समय के लिए ऊपर जाने के लिए प्रयास करें और धक्का दें?

हां, हमेशा चीजों को बेहतर बनाने की कोशिश और प्रयास करना आपके लायक है। आप अच्छी तरह जानते हैं कि आखिर आपको किन समस्याओं का सामना करना पड़ता है।

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

क्योंकि अंत में, यदि आप समाधान का हिस्सा नहीं हैं तो आप समस्या का हिस्सा हैं।



13

हाँ। लेकिन एक वरिष्ठ के लिए भी संगठनात्मक परिवर्तन कठिन है, इसलिए यदि आप वास्तव में इसे सही तरीके से करना चाहते हैं, तो:

  • पहले हफ्तों के दौरान नहीं: इस समय का उपयोग करें:

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

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

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

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

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

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

  • इसे थोड़ा समय दें। बाद में अपने फेट्स के साथ वोट करें: आप कुछ महीनों के दौरान इसे दो साल तक आज़माना चाह सकते हैं। लेकिन कुछ कंपनियों के पास आसान उपाय नहीं हैं। कुछ टीमें बदलाव नहीं करना चाहती हैं और उनके पास प्रोत्साहन नहीं है। और कुछ कोड आधार शुद्ध हॉरर हैं। अगर आपको लगता है कि आप दुनिया के खिलाफ हैं तो याद रखें कि जॉब पूल में बहुत सारे ऑफर हैं। आप अच्छी प्रथाओं को सीखना चाहते हैं और दीर्घावधि में आप बेहतर ढंग से कम वेतन के साथ खुश रहेंगे लेकिन ऐसा अनुभव प्राप्त होगा जो आपको अधिक मूल्यवान बना देगा।

बोनस: यदि आप इसे अपने CV / साक्षात्कार के लिए लिखने में सफल होते हैं। एक जूनियर के रूप में आपके पास आमतौर पर कहने के लिए बहुत कम होता है और बेहतर के लिए बदलाव बनाना हमेशा एक महान संकेत होता है। आप इस बारे में बहुत स्पष्ट और यथार्थवादी दृष्टिकोण रखना चाहते हैं कि आपने व्यक्तिगत रूप से क्या किया और दूसरों से क्या काम लिया। निम्नलिखित साक्षात्कार प्रश्न की कल्पना करें।

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

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

1
मैंने इसे बुरी तरह से कहा हो सकता है: बेशक आप बोते हैं कि अन्य क्षणों पर और विशेष रूप से पहले दिनों के दौरान प्रश्न पूछें। मेरा इरादा है, लेकिन midcommunicated बिंदु द्वारा हो सकता है कि एक जूनियर के रूप में आप पहले दिन "PUSH FOR CHANGES" नहीं करते हैं क्योंकि आपको पता चल सकता है कि यह सब-अभिमानी है और आपके पास किसी संगठन के लिए कुछ अलग करने के लिए उपकरणों की कमी है
Borjab

9

हाँ। लेकिन आपके द्वारा सुझाई गई बातें नहीं।

आपकी सूची में से इकाई / एकीकरण परीक्षण एकमात्र ऐसी वस्तु है जिस पर आप प्रगति कर सकते हैं।

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

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

मैं सीआई पाइपलाइनों की स्थापना, स्वचालित तैनाती, संस्करण, पैकेजिंग पुस्तकालयों पर हमला करने के लिए अच्छे सामान के रूप में चीजों का सुझाव भी दूंगा


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

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

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

2

पर निर्भर करता है:

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

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


1

सबसे जटिल चीजों जैसे स्क्रम से शुरू न करें। सबसे आसान चरणों के साथ शुरू करें।

आपने स्रोत कोड प्रबंधन का उल्लेख नहीं किया है। क्या आपके पास कुछ स्रोत कोड रिपॉजिटरी (git, svn, cvs, ...) है? टैगिंग और ब्रांचिंग के लिए एक रणनीति? वे सरल कदम हैं जो एक शुरुआत कर सकते हैं। इन चरणों को हल करने का प्रयास करें और अपनी कंपनी को लागत कम करने में मदद करें (यही प्रबंधन में रुचि है)।

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

स्क्रैम के रूप में, "एक्सट्रीम प्रोग्रामिंग" (एक्सपी) के बारे में बेहतर पढ़ें। Scrum XP के कई विचारों पर आधारित है और उनके आसपास एक औपचारिक प्रक्रिया जोड़ता है - XP की अवधारणाओं को अभी भी उस प्रक्रिया के बिना उपयोग किया जा सकता है।

चीजों का सुझाव दें, जमीनी जानकारी प्रदान करें, दूसरों को समझाने की कोशिश करें, परिणामों का विश्लेषण करें, ... लेकिन दूसरों से बहुत अधिक सहयोग की उम्मीद न करें: ज्यादातर लोग अपनी पुरानी बुरी आदतों के साथ रहना पसंद करते हैं। लेकिन जब आप ऐसा प्रयास नहीं करेंगे, तो कुछ भी नहीं सुधरेगा।


0

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


0

शुरुआत में, सवाल पूछें

आपकी सूची को पढ़कर, मैं निम्नलिखित प्रश्नों का सुझाव दूंगा (अपनी सूची में वापस देखें कि वे कैसे फिट होते हैं):

  • मैं यह कैसे देखूं कि व्यवसाय के स्वामी किस काम का अनुरोध कर रहे हैं?
  • क्या आपने [स्क्रम] की कोशिश की है?
  • इसके लिए उत्पाद स्वामी कौन है?
  • क्या भूमिकाएँ हैं?
  • [यह भूमिका] क्या करता है?
  • [इस गतिविधि] के लिए क्या भूमिका जिम्मेदार है?
  • क्या आपने एक दैनिक स्टैंडअप की कोशिश की है?
  • मैं टीम के बाकी हिस्सों में अपनी बाधाएं कैसे पहुंचाऊं?
  • मुझे कैसे पता चलेगा कि टीम के अन्य सदस्य क्या काम कर रहे हैं?
  • क्या हमें समस्या ट्रैकिंग टूल में [इसे] डालना चाहिए?
  • ट्रैकिंग टूल में हमें [इसे] कैसे लिखना चाहिए?
  • जब [यह] होता है, तो क्या हमें इसे इस मुद्दे पर नज़र रखने वाले टूल में डाल देना चाहिए?
  • हम परीक्षण कैसे करते हैं?
  • हम दूसरों के पुन: उपयोग के लिए अपने परीक्षण कैसे रिकॉर्ड करते हैं?
  • क्या आपने [JUnit] कोशिश की है?
  • [यह] दस्तावेज कहां है?
  • क्या आपने [मीडियाविकि] की कोशिश की है?

[कोष्ठक] में चीजों को प्रतिस्थापित करें क्योंकि प्रश्नों को उचित बनाने या अपनी प्राथमिकताओं को फिट करने के लिए उपयुक्त है। यदि मेरा शब्दांकन आपकी शैली से मेल नहीं खाता है, तो रिवाइडिंग पर विचार करें।

हो सकता है कि आपने पहले ही ऐसा करना शुरू कर दिया हो। समूह वार्तालाप पर एक-से-एक वार्तालाप को अनुकूल बनाएं। क्योंकि एक-के-बाद-एक, आप दूसरे व्यक्ति के बारे में क्या सोचते हैं, इसका बेहतर अध्ययन कर सकते हैं। क्या वह व्यक्ति इस बदलाव के लिए है? इसके खिलाफ? कमजोर? कट्टर?

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

बाद में, कदम उठाएं

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

जब आपके पास एक बाधा है (और मान लें कि आप एक स्टैंडअप में साझा नहीं कर सकते हैं), तो मदद के लिए टीम को ईमेल करें।

पहचानें कि भूमिकाएं क्या होनी चाहिए, संभवतः दूसरों के समर्थन से जो आपके साथ सहमत हैं। काम शुरू होने पर लगातार लोगों के पास जाना शुरू करें जिसमें आपकी (संभवतः एक समूह की) भूमिका शामिल है, जो सोचते हैं कि उनके पास होना चाहिए। यदि वे पीछे धकेलते हैं, तो उन्हें पहचानने के लिए कहें कि उस भूमिका का मालिक कौन होना चाहिए।

उत्पाद मालिकों से पूछें (कि आपने पहचाना) यह वर्णन करने के लिए कि वे सोचते हैं कि उनके उत्पाद को अभी और भविष्य में कैसे काम करना चाहिए।

एक परीक्षण ढांचा स्थापित करें (यदि अन्य इसका पक्ष लेते हैं, तो किस ढांचे पर एक संयुक्त निर्णय लें) और इसे अपनी परियोजनाओं के लिए उपयोग करें। जब आप बग को ठीक कर रहे हों, तो परीक्षण लिखें। मुद्दा ट्रैकर पर बग रिपोर्ट में यह दस्तावेज (लिखित परीक्षण प्रदर्शन थैला बग, [स्थान] पर संग्रहीत)। परिवर्तन करने पर दूसरों को परीक्षण चलाने के लिए प्रोत्साहित करें। यदि वे नहीं करते हैं, तो परीक्षण स्वयं चलाएं और आवश्यक रूप से ट्रैकर को समस्याएँ प्रस्तुत करें।

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

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

आखिरकार, आप वरिष्ठ होंगे

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


+1; बहुत से अच्छे विचारों के साथ बेहतर उत्तरों में से एक।
कीथ

0

संक्षिप्त उत्तर : नहीं, अन्य उत्तरों में उल्लिखित सभी कारणों के लिए। मध्यम या वरिष्ठ देव होने के बावजूद, आमतौर पर किसी नई टीम में शामिल होने के लिए समझने के लिए पहले तलाश करना बेहतर होता है ।

एक प्रस्तावित समाधान :

1) जब भी आपको ऐसा कुछ दिखाई दे जो आपको लगता है कि बेहतर होना चाहिए, तो ध्यान दें! (नोटबुक में, डिजिटल नोट में ...)

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


0

देर से जवाब, और अन्य उत्तर में बहुत सारी अच्छी सामग्री से सहमत हैं।

मुझे लगता है कि यह कहा जाना चाहिए कि यहां एक महत्वपूर्ण मुद्दा विशिष्ट प्रथाओं नहीं है, लेकिन समग्र टीम संस्कृति है।

  • सांस्कृतिक परिवर्तन कठिन है
  • और अधिक अगर आप "जूनियर" के रूप में देखे गए

निरंतर सुधार प्राप्त करने का एक साधन होने पर बाकी सब का पालन कर सकते हैं ।

इसे प्राप्त करने के लिए मेरा दृष्टिकोण है:

  • प्रलेखित प्रक्रियाएँ और प्रक्रियाएँ
  • टीम के साथ रेट्रोस्पेक्टिव्स जिनके कार्य प्रक्रिया प्रलेखन में परिवर्तन हैं।

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

आप आसानी से दस्तावेज़ प्रक्रिया शुरू कर सकते हैं। "मैं नया आदमी हूं, क्या मुझे यह अधिकार मिला है? मुझे यह लिखने दो।" इसके बाद यह महत्वपूर्ण है कि वास्तव में स्वयं प्रक्रिया का पालन करें, या जहां यह टूटता है, वहां कॉल करने का प्रयास करें।

हो सकता है कि आप इस तरह की बातचीत को तदर्थ होने के साथ शुरू करें और फिर नियमित अनुष्ठान का सुझाव दें।

इस दृष्टिकोण को लेना एक वृद्धिशीलता देता है, धीरे-धीरे नरम, दृष्टिकोण। आप एक जूनियर के रूप में दिखने से बच सकते हैं जो वे सब जानते हैं और इसके बजाय टीम में बदलाव करने के लिए एक सूत्रधार बनने की कोशिश करते हैं।

कुछ विचार:

  • कुछ टीमों के पास खराब प्रक्रिया है, लेकिन वास्तव में पहले से ही वह जानता है। वे बदलना चाहते हैं और बस उसे उत्प्रेरित करने के लिए कुछ चाहिए। अन्य टीमें वास्तव में अपने तरीके से फंस गई हैं और बदलने के लिए बहुत कठिन है।
  • एक ही व्यक्ति के लिए जाता है।
  • आपको उसके प्रति संवेदनशील होना चाहिए और यह पता लगाना चाहिए कि टीम में कौन बदलाव के लिए खुला है और कौन नहीं। समझे क्यों।
  • आसान जीत का पता लगाएं।
  • टीम में बदलाव का स्वागत करें: उनके व्यक्तिगत दर्द बिंदुओं का पता लगाएं और उन्हें ठीक करने में मदद करने का प्रयास करें।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.