मैं टीम में एक धीमे और असंगठित सहयोगी से कैसे निपटूं? [बन्द है]


85

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

मैं अपने काम से बहुत परिचित हूं और मैं इसे जल्द ही खत्म कर दूंगा। चूंकि इसमें ज्यादा काम नहीं है। और मैं एक ऐसा व्यक्ति हूं जो काम करना पसंद करता है। मैं ज्यादातर समय ऑफिस में बिताता हूं और घर जाने के बाद ही नींद आती है।

C / c ++ ऐप को एक अन्य सहयोगी द्वारा प्रबंधित किया जाता है, जिसके पास 5+ वर्ष का अनुभव है और वह मुझसे बहुत तेज़ी से चीजें कर सकता है, लेकिन वह कभी ऐसा नहीं करता है। हो सकता है वह ऐसा करना पसंद न करे। जब मेरा अजगर इसके साथ संवाद करता है या गलत मान देता है तो उसका ऐप अक्सर क्रैश हो जाता है। यह कीड़े से भरा है। चूंकि मेरा ऐप इस पर निर्भर करता है, इसलिए मुझे इसे बनाने में मुश्किल समय आ रहा है। कीड़े को ठीक करने के बजाय, उसने मुझे अपना काम धीमा करने के लिए कहा। वह मुझे प्रबंधक को बताने के लिए कहता है कि मेरे काम को बहुत समय की आवश्यकता है। वह मुझे प्रबंधक को बेवकूफ बनाने के लिए कह रहा है और यहां तक ​​कि मुझे उसकी तरह धीरे-धीरे काम करने के लिए मजबूर कर रहा है।

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

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

क्या कोई मुझे सुझाव दे सकता है कि मैं इससे कैसे निपटूं? मैं जल्द ही इस परियोजना को खत्म करना चाहता था। मैं उसके साथ अच्छे संबंध बनाकर भी उसे कैसे काम दे सकता हूं?

टिप्पणियों के जवाब:

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

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

क्या आपकी कंपनी में बग ट्रैकिंग सिस्टम नहीं है?

यहाँ वास्तविक बग ट्रैकिंग सिस्टम नहीं है। कंपनी परियोजना को जल्द से जल्द खत्म करने की कोशिश करती है और इसे क्यूए को देती है। और फिर QA द्वारा रिपोर्ट किए गए बग्स को ठीक करता है।

यही कारण है कि कंपनियों को कर्मचारियों को स्टॉक / विकल्प या किसी प्रकार का स्वामित्व देना चाहिए। इस तरह से आप सचमुच उस आदमी से कह सकते हैं "तुम मुझे मौद्रिक विकास की लागत दे रहे हो ... क्या तुम पैसा भी नहीं बनाना चाहते?"।

कंपनी के पास स्टॉक विकल्प हैं जो उन्होंने मुझे 2500 शेयर दिए हैं, ज्यादातर वह भी कुछ और ही मिला होगा।

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

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

QA इस पूरे समय क्या कर रहा है? वे परियोजना की स्थिति की रिपोर्ट / पुष्टि क्यों नहीं कर रहे हैं?

प्रबंधक वह व्यक्ति है जो QA को कब देना है, यह तय करता है। अभी तक यह क्यूए को नहीं दिया गया है। उन्होंने कहा कि हमें इसे इस महीने के अंत तक देना चाहिए।


6
आप कैसे जानते हैं कि C ++ का आदमी आपसे ज्यादा तेज है? वह स्वाभाविक रूप से धीमा हो सकता है।
अय्यूब

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

1
@ जॉब की धारणा है कि वरिष्ठता का मतलब बेहतर कोडर है जो हमेशा ऐसा नहीं होता है।
रुडोल्फ ओलह

जवाबों:


126

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

क्या यही मुझे करना होगा:

  • अपराध में उसका साथी मत बनो। अपनी परियोजना या उसकी परियोजना की स्थिति के बारे में झूठ बोलने से मना करें।

  • लागू करें (यदि आवश्यक हो तो आपके खाली समय में) बग आपके आवेदन की रिपोर्टिंग करता है, इसलिए सभी कीड़े ईमेल द्वारा आपके सहकर्मियों और आपके प्रबंधक को भेजे जाते हैं । यदि बग उसके अनुप्रयोग के कारण होता है, तो इसे ईमेल में दिखाई दें (ईमेल विषय में [XYZ APP BUG] या कुछ और डालें)।

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

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

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

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


45
+1 इस बात पर जोर देने के लिए कि प्रश्नकर्ता को अपनी परियोजना की स्थिति के बारे में कभी झूठ नहीं बोलना चाहिए।
एरिक हाइड्रिक

6
मैं एक मवेशी ठेस का सुझाव देने जा रहा था लेकिन लुकास के सुझाव बेहतर हैं!
रस क्लार्क

9
+1 के लिए 'बाहर देखो और उसे कम मत समझना। उसके जैसे लंबे समय तक सुस्त रहने वाले की चाल या उसकी आस्तीन दो हो सकती है। ' वह वास्तव में होना चाहिए ...
amyassin

3
@ ब्रायन, मेरा मानना ​​है कि ये तकनीकी समाधान रिश्ते की समस्या को हल कर सकते हैं। ध्यान दें कि सहकर्मी 5 साल का वरिष्ठ और कथित रूप से बहुत सक्षम डेवलपर है। दूसरी ओर आशिन एक नौसिखिया है, इसलिए उसके पास अधिक लाभ नहीं है। इस मामले में यह बेहतर है कि कठिन तथ्यों पर टिके रहें, बजाय इसके कि सहकर्मी (ओं) और संभवतः प्रबंधक से समस्या के बारे में बात की जाए। यदि यह शब्द के खिलाफ शब्द है, तो प्रबंधक शायद सहकर्मी पर भरोसा करेगा - या नहीं, लेकिन वह उसे वैसे भी परेशान नहीं कर सकता क्योंकि वह कंपनी के लिए मूल्यवान हो सकता है (विरासत प्रणाली आदि को बनाए रखना)
लुकास स्टैस्कल

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

128

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

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

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

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


44
मैं मानता हूं कि जब तक आपको नींद नहीं आती है तब तक काम करना उल्टा है। किसी को भी 40 घंटे से अधिक काम नहीं करना चाहिए जब तक कि यह क्रंच का समय न हो और निश्चित रूप से नियमित रूप से न हो।
एचएलजीईएम

36
इस बात पर विचार करें कि यदि आप 12 घंटे काम करते हैं और वह 7 काम करता है, और आप अग्रिम नहीं कर सकते हैं यदि वह आगे नहीं बढ़ता है, तो आप एक हो सकते हैं जो खराब दिख रहा है । आखिरकार, आपको वह करने के लिए 12 घंटे चाहिए जो आदमी ने सिर्फ 7 में किया था! इसलिए हो सकता है कि आपके बजाय उसकी गति धीमी हो जाए या आप तेजी से आगे बढ़ें, आपको अतिरिक्त समय बिताने के लिए एक अतिरिक्त प्रोजेक्ट के लिए पूछना चाहिए, जबकि आप उसे अपना हिस्सा करने के लिए इंतजार कर रहे हैं । निश्चित रूप से अन्य चीजें हैं जो आप कर सकते हैं / सीखने / दस्तावेजीकरण कर रहे हैं?
कोनरक

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

9
Srs के लिए +1। मुझे लगता है कि प्रारूप उस प्रश्न का उत्तर है जो पूछा गया था, लेकिन हर कोई वास्तव में कम से कम तीन लोगों को शामिल करने वाली कहानी के एक पक्ष को सुनने के बाद पार्टी बी को खुश करता है। हो सकता है कि पार्टी बी का आउटपुट स्तर पूरी तरह से संतोषजनक रहा हो और उसके मुआवजे के स्तर के अनुरूप वर्षों तक नए आदमी जो 12 बजे कार्यालय में रहना पसंद करते हैं और इस बारे में बात करते हैं कि अन्य सभी को कैसे दिखाया जाता है?
१11

15
@ एशिन: गंभीरता से, मैं समझता हूं कि शुरुआती करियर की इच्छा और मैं इसे छोड़ना नहीं चाहता। लेकिन मैं आपको चेतावनी देता हूं कि यह करता है, अंततः, बर्नआउट की ओर जाता है और यह एक सुखद बात नहीं है। यहां तक ​​कि अगर आप व्यक्तिगत परियोजनाओं पर अपना खाली समय बिताते हैं, तो इससे मदद मिलेगी। लेकिन किसी ने मुझे बताया कि जब मैंने यह करियर शुरू किया था तो मुझे कोडिंग के बाहर कुछ शौक की जरूरत थी। मैं हंसा और उसे खारिज कर दिया - मैं ऐसा क्यों करना चाहूंगा? और मैंने इसके लिए बाद में भुगतान किया।
पीडीआर

40

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


5
ई-मेल रिकॉर्ड इसके लिए विशेष रूप से उपयोगी हैं। मैं हमेशा एक ई-मेल के साथ हर समझौते का पालन करता हूं और जब भी मैं मेल के माध्यम से करता हूं तो हमेशा सूचित करता हूं।
वेल्श

5
@ वेल्श - बिल्कुल। यहां तक ​​कि अगर प्रत्येक व्यक्ति एक कमरे में है, तो अपने अनुरोधों को ईमेल करते हुए भेजें और प्रबंधक के साथ सीसी का पालन करें।
ओट्टोवियो डेसिओ

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

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

3
@Ashin: वह आपको प्रबंधक को cc नहीं करने के लिए कह सकता है, लेकिन इसका मतलब यह नहीं है कि आपको इसका अनुपालन करना चाहिए। क्या आपके पास प्रबंधक को जारी रखने के लिए कुछ भी करने का कोई अधिकार है? इसके अलावा, आप BCC सुविधा का उपयोग कर सकते हैं ताकि उसे पता न चले कि प्रबंधक CC'd था।
FrustratedWithFormsDesigner

34

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

अगली बार जब आप किसी मीटिंग में हों और वह कहे कि उसका सारा कोड ठीक है, तो बोलें, "ओह, अच्छा, जो बात मैंने आपको लगभग एक घंटे पहले बताई थी, वह उस समय की है जब मैं एक्सवाईजेड को डेट पर बुलाता हूं, जो वर्किंग डे नहीं है, अब तय हो गया है? " तीन चीजों में से एक होगा:

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

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


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

32

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

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

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


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

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

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

28

सबसे पहले:

चूंकि वह मेरा सहयोगी है, मैं प्रबंधक को कुछ भी नहीं बता सकता।

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

ईमानदारी से अपनी स्थिति की रिपोर्ट करें। यदि आपका कार्य किसी अन्य डेवलपर के अंत में बग्स द्वारा आयोजित किया जा रहा है, तो दस्तावेज़ जिसे आपने C / C ++ में बग ढूंढे हैं और उन्हें रिपोर्ट किया है (कृपया मुझे बताएं कि आप कुछ दस्तावेज़ का उपयोग कर रहे हैं जो एक पेपर निशान छोड़ता है)।

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


5
हो सकता है कि उनका सॉफ्टवेयर अश्विन की तुलना में अधिक जटिल हो। एक सहकर्मी के साथ हार्ड लाइन लेना आपके साथ निकटता से काम करना है लेकिन पता करने के लिए परेशान havent असामाजिक, काउंटर उत्पादक और बहुत अव्यवसायिक है।
hplbsh

3
आपके वेतन का भुगतान आपकी कंपनी करती है न कि आपके सहयोगी।
रूडी

@lttlrck मैं आपसे सहमत हूं, उनका ऐप मुझसे ज्यादा जटिल है। लेकिन इसकी एक मौजूदा परियोजना है। जैसे हमारी कंपनी के पास एक मौजूदा स्टैंडअलोन ऐप है जो c & c ++ में लिखा गया है जो समान काम करता है। और अब उन्होंने इसे वेब पर बनाने की योजना बनाई है ताकि उपयोगकर्ता इसे बिना इंस्टॉल किए सीधे उपयोग कर सकें। और जहाँ तक मुझे उससे और प्रबंधक से अपने प्रारंभिक चरण में पता चला है कि, वे मौजूदा परियोजना के समान कोड का उपयोग थोड़ा संशोधित करते हैं और इसके अलावा बूस्टर का उपयोग करके अपनी कक्षाओं और विधियों को अजगर तक उजागर करते हैं।
HOT

3
@Ashin kn, तथ्य यह है कि उनके आवेदन का एक हिस्सा एक मौजूदा परियोजना है जरूरी नहीं कि उसका काम आपके मुकाबले आसान है। डेस्कटॉप उपयोग के लिए शुरू में तैयार किए गए कुछ अनुप्रयोगों को सेवाओं के रूप में उजागर करने के लिए केवल थोड़े संशोधनों की आवश्यकता होती है (जैसे वेब इंटरफ़ेस के माध्यम से); परिवर्तन अक्सर दुर्भाग्य से अधिक महत्वपूर्ण होते हैं। जब यह पूरी तरह से उपयोग किए जाने वाले तरीके को बदलने के लिए विरासत कोड के साथ काम कर रहा है, तो थोड़े से बदलाव से बहुत से अवांछित दुष्प्रभाव हो सकते हैं, यहां तक ​​कि उन अनुप्रयोगों में भी जो शुरुआत में बहुत बुरी तरह से डिज़ाइन नहीं किए गए थे। यह उनके अधिक सतर्क रवैये की व्याख्या कर सकता है, जो कि धीमा है।
ब्रूनो

1
+1 के लिएIf you know C/C++, you can offer to help on the main application logic to get things moving with that as well.
गोजो कुदोर

27

काम पर कई मुद्दे हैं। विदित हो कि:

  1. आप अन्य लोगों की प्रेरणाओं के बारे में धारणा बना रहे हैं
  2. आप तथ्यों को राय के साथ रंग रहे हैं।
  3. बाहरी लोग (किसी और के) इतिहास से अवगत नहीं हैं और अपने सहकर्मी के साथ आपकी कुंठाओं से अवगत नहीं हैं।
  4. आप बचकाने लग सकते हैं यदि ऐसा लगता है कि आप "गोच" गेम खेल रहे हैं। आपका सहकर्मी शायद इसे बेहतर तरीके से खेल सकता है - आखिरकार उसके पास अभी भी कोई काम नहीं है?

इसलिए, अपनी परियोजना की स्थिति प्रस्तुत करते समय:

  1. दूसरे व्यक्ति का उल्लेख न करें।
  2. कोड के साथ त्रुटियों या मुद्दों की रिपोर्टिंग करते समय - डेवलपर नहीं। "FooBar () विधि 1 पर कॉल 1 लौट रहा है जब इसे 2 लौटना चाहिए"। फिर कोई भी मुद्दा व्यक्तिगत हमला नहीं है, आप सिर्फ कोड के बारे में बात कर रहे हैं - लोग नहीं।
  3. उन तथ्यों से चिपके रहें जिनके लिए आपके पास सबूत है।
  4. यदि आपका सहकर्मी रक्षात्मक या शत्रुतापूर्ण हो जाता है, तो प्रश्न पूछें। "मुझे समझ नहीं आ रहा है कि आपको क्यों लगता है कि मुझे _ करना चाहिए "
  5. सामाजिक झगड़ों या बेगुनाहों से बेखबर रहें। आप व्यक्तिगत हमले नहीं मिलता है।
  6. किसी भी स्टेटस मीटिंग से पहले रात को भरपूर नींद लें, ताकि आप मानसिक रूप से फुर्तीले हों।
  7. दस्तावेज, दस्तावेज, दस्तावेज।
  8. इस आदमी को कुछ दिलचस्प समस्या के साथ आपकी मदद करने के लिए कहने में संकोच न करें, यदि वह महसूस करता है कि आप उसका सम्मान करते हैं, तो वह आपको ले जा सकता है। यह तालमेल बनाने के बारे में है। (ध्यान दें यह नहीं चूस रहा है - यह कुछ और है)
  9. यदि आपको करना है, तो छोड़ने के लिए तैयार रहें, ताकि आप जरूरतमंद या भावनात्मक रूप से फंस न जाएं। यह आपके सिर को बैठकों में रखने में मदद करेगा।

4
अब तक, सबसे अच्छी योजनाओं में से एक यहाँ। मैं केवल "बाहर जाना और फूलों को सूंघना" जोड़ना चाहता हूं क्योंकि "काम कर रहा हूं जब तक मुझे नींद नहीं आती" भाग डरावना लगता है।
लियोनार्डो हेरेरा

@ लियोनार्डो - thx :-) मैं सहमत हूँ। कार्य / जीवन संतुलन और ओपी के प्रश्न के दायरे से परे सभी तरह से।
पैट

+1 जब कोड के साथ त्रुटियों या मुद्दों की रिपोर्टिंग - डेवलपर नहीं
Ubermensch

16

"मैं एक व्यक्ति हूं जो काम करना पसंद करता है। मैं ज्यादातर समय कार्यालय में बिताता हूं और केवल घर जाता हूं जब मुझे नींद आती है।"

यह स्वस्थ नहीं है और सहकर्मियों से उम्मीद नहीं की जा सकती है, जब तक कि आपको अपरिहार्य बर्नआउट के लिए वर्षों तक सक्षम होने के बिंदु पर मुआवजा नहीं दिया जाता है। (कंपनी में> $ 200ka वर्ष से ऊपर> 10% स्वामित्व की तरह कुछ)। उस बिंदु पर पहुंचने के लिए विशेषज्ञता बनाए रखना जहां वह बहुत जल्दी विकसित हो सकता है। आपका कुछ समय विकासशील विशेषज्ञता के लिए समर्पित होना चाहिए।

"सी / सी ++ प्रोजेक्ट मुख्य ऐप है जो सभी कार्यक्षमता करता है। मेरे अजगर उपयोगकर्ता को इसके लिए अनुरोध भेजते हैं और उपयोगकर्ता से इसकी प्रतिक्रिया प्रदर्शित करते हैं। ... हो सकता है कि वह ऐसा करना पसंद न करें।"

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

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

फिर आप उसके सिस्टम के लिए एक स्वचालित परीक्षण सूट लिख सकते हैं जिसे बाहरी रूप से कहा जाता है जो मानकों पर सहमत होने के अनुरूप है। जैसे, फू (1,2,3) की तुलना में परीक्षण "बार 4 5 6" की प्रतिक्रिया देता है। यह उसके विकास के साथ कीड़े और गति की पहचान करने में मदद कर सकता है (और उसके कोड के साथ गड़बड़ करने की आवश्यकता नहीं है)। एक बार उन चीजों को पूरा करने के बाद, आप किसी अन्य प्रोजेक्ट / कार्य (जैसे कि C / C ++ भागों के साथ उसकी सहायता) कर सकते हैं।


12

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

इस स्थिति में, कुछ विचार हैं जिन्हें आपको ध्यान में रखना चाहिए।

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

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

इसलिए यदि प्रबंधक के सामने अपने सहकर्मी का विरोध करना बुरा है, और उसका विरोध करना भी बुरा है , तो आप क्या करते हैं?

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

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

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

कृपया याद रखें कि जब आप अपनी चिंताओं को किसी भी सहयोगी या प्रबंधक को व्यक्त करते हैं, तो आपकी चिंताएं आपके सहकर्मी के कार्यक्रम के बारे में होती हैं जो खराब डेटा (या जो कुछ भी कर रहा है) वापस कर रहा है; ये औसत दर्जे की चीजें हैं जिन्हें सत्यापित और तय किया जा सकता है। आपकी चिंताएं आपके सहकर्मी के धीमे या असंगठित होने के बारे में नहीं हैं ; ये औसत दर्जे की चीजें नहीं हैं, जो सच हो सकती हैं या नहीं भी हो सकती हैं, और जिन्हें बॉस के सामने एक बैठक में लाने से तय होने की संभावना नहीं है।


3
+1 करने के लिए ज़ोर देना कि "पेशेवर रूप से व्यवहार करना आपके दीर्घकालिक कैरियर के लिए सबसे महत्वपूर्ण बात है"।
Skarab

1
+1 उत्कृष्ट उत्तर - निश्चित रूप से सबसे अच्छा मैंने यहां अभी तक देखा है। मानवीय समस्या का मानवीय समाधान। आक्रामक बग ट्रैकर्स आदि का कोई उल्लेख नहीं ;-)
ट्रोजननाम

8

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

यह मुझे लगता है जैसे यहाँ अपर्याप्त परियोजना प्रबंधन है। आपको एक) कीड़ों को ट्रैक करने की आवश्यकता है जो आपको प्रभावित कर रहे हैं और बी) लिखित रूप में चर्चा का पालन करते हैं।

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


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

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

2
ठीक ठीक। सहकर्मियों के लिए कवर करना वास्तव में वास्तव में आपको किसी कंपनी में आगे नहीं बढ़ा सकता है, या कम से कम किसी भी कंपनी में प्रबंधन की टीमों के साथ नहीं हो सकता है।
वोल्फगैंगसेनफ

@temptar - क्यूए ईमेल के माध्यम से रिपोर्ट करता है और वे कुछ कीड़े भी लॉग करते हैं जहां भी, मैं इसके बारे में इतना स्पष्ट नहीं हूं, क्योंकि मैं यहां सिर्फ 3 महीने से हूं और यह मेरा पहला प्रोजेक्ट है। हाँ, जैसा कि आप सभी ने कहा कि मुझे अपने द्वारा रिकॉर्ड रखने दें और मुझे अपने प्रबंधक को ईमेल के माध्यम से इस बारे में सूचित करने दें। सुझाव के लिए धन्यवाद
HOT

2
@ एशिन, आप ट्राक या मेंटिस में देखना चाह सकते हैं क्योंकि वे मुफ्त बग ट्रैकिंग सिस्टम हैं जो स्थापित करने और उपयोग करने के लिए अपेक्षाकृत सरल हैं।
तंगुरेना

8

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

सामने के छोर के कारण आप एप्लिकेशन परत पर देरी का तर्क कैसे दे सकते हैं? इसलिए आप ऐसा करते हैं ताकि वे अलग हो सकें। आगे क्या है, उसके पास और भी देरी है क्योंकि कोई व्यक्ति एक फ्रंट फ्रंट एंड का निर्माण करना चाहता है?

अपना काम पूरा करो। किसी भी समस्या का दस्तावेजीकरण उसके ऐप पर विफलता के साथ करें। और फिर घर जाओ! मुझे परवाह नहीं है कि आप नींद में हैं या नहीं। कुछ दोस्तों के लायक खोजें।


4

मैंने अभी आरसी मार्टिन (अंकल बॉब) द्वारा "द क्लीन कोडर" पढ़ा है। पुस्तक का मुख्य बिंदु यह है कि सामान्य रूप से प्रोग्रामर को अधिक सम्मान नहीं मिलता है क्योंकि वे पेशेवर व्यवहार नहीं कर रहे हैं । इसका मतलब है कि मुख्य रूप से वे परियोजना की स्थिति के बारे में प्रबंधन के साथ प्रभावी रूप से संवाद नहीं करते हैं।

झूठ बोलना निश्चित रूप से संचार का एक बहुत बुरा रूप है। आपका सहकर्मी बेहद अनप्रोफेशनल है और इसलिए आप हैं। आप दोनों प्रोग्रामर की धारणा को बेहतर बनाने के लिए कुछ भी अच्छा नहीं कर रहे हैं।

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


3

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

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

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

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

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

आप प्रति झूठ नहीं बोल रहे हैं, न ही आप पक्ष ले रहे हैं। आप समस्याओं पर ध्यान देकर राजनीति कर रहे हैं और अपने सहयोगी को चेहरा बचाने दे रहे हैं यदि चीजें वास्तव में आगे नहीं बढ़ रही हैं।

यह सिर्फ आपके प्रबंधक से बात करने के लिए लुभाता है, लेकिन यह न भूलें कि उनमें से आपको किसके साथ काम करना है।


2

पैट का जवाब बहुत अच्छा था। मैं 100% सहमत हूं। मालिक के साथ एक बैठक चुपके मत जाओ। या तो इसे अपने सहकर्मी के साथ 4 आंखों के बीच ले जाएं या आप सभी 3 के साथ करें। लेकिन पैट के सुझाव कोड मुद्दों पर ध्यान केंद्रित करने और लोगों पर नहीं जाने का सही तरीका है।

Btw, 40h / सप्ताह पर्याप्त दोस्त है। आपको अपनी प्रेरणा उच्च रखने की आवश्यकता है!


1

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

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


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

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

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