क्या मुझे अपनी टीम को हमारे स्रोत नियंत्रण प्रणाली के साथ एक बुनियादी प्रवीणता से अधिक की उम्मीद करनी चाहिए?


48

मेरी कंपनी ने लगभग तीन महीने पहले तोड़फोड़ से गिट में स्विच किया। हमारे पास स्विच से पहले अग्रिम सूचना के सप्ताह थे। चूँकि मैंने पहले कभी भी (या किसी अन्य DVCS) Git का उपयोग नहीं किया था, मैंने Pro Git पढ़ा और अपने स्वयं के रिपॉजिटरी को कताई करने और आसपास खेलने में थोड़ा समय बिताया, ताकि जब हम स्विच करें तो मैं कम से कम दर्द के साथ काम करने में सक्षम रहूँ। अब मैं डिफ़ॉल्ट रूप से 'Git guy' हूं।

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

हमारे दैनिक कार्यों में स्रोत नियंत्रण की मौलिक प्रकृति को देखते हुए (सत्ता की हास्यास्पद मात्रा का उल्लेख नहीं किया जाता है), मुझे लगता है कि कोई भी देवता जो इसके साथ एक निश्चित स्तर की प्रवीणता हासिल नहीं करता है, वह एक दायित्व है

क्या मुझे उम्मीद है कि मेरी टीम को कम से कम कुछ समझ होनी चाहिए कि Git आंतरिक रूप से कैसे काम करता है, और इसे सबसे बुनियादी पुल / मर्ज / पुश ऑपरेशन से परे कैसे उपयोग करें? या मैं सिर्फ कुछ नहीं से कुछ बना रहा हूं?


30
क्या कंपनी ने Git पर कोई प्रशिक्षण दिया?
यानिस

9
कोई भी देव जो उत्पादक नहीं है एक दायित्व है। यह मानते हुए कि वे बड़े पैमाने पर उत्पादक हैं, ज्ञान को जानना या न जानना असंगत है। दिन के अंत में यह सिर्फ एक और उपकरण है।

9
मैं समझ सकता हूँ कि कैसे Git शाखाओं ने इसके साथ "बुनियादी प्रवीणता" का हिस्सा काम किया है ...
Shauna

16
यदि आपके टीम के साथी Git का पता नहीं लगा सकते हैं तो आपको स्रोत नियंत्रण से बड़ी समस्याएं मिल सकती हैं।
जॉर्डन बेंटले

4
@ कालेब एक घमंड नहीं था। इससे दूर।
जोशुआ स्मिथ

जवाबों:


49

व्यावसायिकता स्वाभाविक रूप से यह तय करेगी कि एक डेवलपर अपनी टीम के मानक उपकरणों से परिचित हो, भले ही वे नए और अपरिचित (या अवांछित भी हों)।

हालाँकि, आपकी पोस्ट की कुछ बातें मुझे विराम देती हैं।

हमारे पास स्विच से पहले अग्रिम सूचना के सप्ताह थे।

सप्ताह? सोर्स कंट्रोल को स्वैप करना बड़ी बात है। नोटिस के महीनों को उस तरह के बदलाव के लिए अग्रणी होना चाहिए था ।

कुछ अपवादों के साथ, मेरी टीम के अधिकांश लोगों को अभी भी पता नहीं है कि गिट कैसे काम करता है।

तो, आपकी कंपनी एक स्रोत नियंत्रण प्रणाली में बदल गई है कि कुछ, अगर किसी को, उस समय समझ में आया?

जब तक कुछ अन्य संदर्भ नहीं है, ऐसा लगता है जैसे पूरी चाल को बीमार समझ लिया गया था (चाल, पसंद नहीं - मैं बहुत बड़ा प्रशंसक हूं)।


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

3
क्या किसी ने आपके पास मौजूद वर्कफ़्लोज़ का पता लगाने और उन्हें उन प्राथमिकताओं में मैप करने की जहमत उठाई जो नए VCS को पेश करनी थीं? अपने आप को पैर में अपने आप को शूट करना बहुत आसान है, जो आपके द्वारा उपयोग की जाने वाली आवाज़ों की तरह है, और आपको वास्तव में इसके लिए किसी को ऑर्केस्ट्रेट करने की आवश्यकता है। इस बदलाव के लिए जिम्मेदार कहां है?
लार्स विकलंड

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

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

7
सीखना कैसे काम करता है सुंदर तुच्छ है। यह निश्चित रूप से यह जानने के लिए नहीं है कि इसका उपयोग कैसे करें। मेरी राय में एक सरल "दोस्तों, हम कुछ हफ्तों में गिट का उपयोग करने जा रहे हैं। यह जानने के लिए कुछ घंटों का समय लें कि ऑनलाइन संसाधनों का एक समूह है।", पर्याप्त से अधिक होगा।
मोक्स

34

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

समस्या का एक हिस्सा यह है कि लोगों को एक अलग एससीएम में स्विच करने के लाभ नहीं दिखेंगे जब वे उनके लिए काम कर रहे हैं। इससे मदद मिली जब हम अपनी टीम के साथ एक-एक घंटे के सत्र में बैठे, जहां हम सिर्फ अपनी परियोजनाओं के मामलों का उपयोग करेंगे और जीआईटी ने इसे कैसे आसान बनाया। उदाहरण के लिए, जिन चीजों ने हमारी मदद की:

  • प्रयोग को प्रोत्साहित करने के लिए स्थानीय शाखाएँ
  • आसानी से नीचे कीड़ों को ट्रैक करने के लिए गिस बाइसेक्ट करें
  • दूसरों के बीच में आए बिना लगातार हंगामा करता है
  • शाखाओं के बीच तेजी से स्विचन

आदि। इनमें से प्रत्येक ने एक समस्या का हल किया जो हमने अपने पिछले SCM के साथ सामना किया था और इसलिए लोग Git की अधिक सराहना कर सकते थे।

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

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

जीआईटी का सीएलआई गूढ़ और तुच्छ समस्याएं हैं (आप और मैं) लोगों को काम करने से रोकेंगे। यहां हमारी टीम पर क्या हुआ (आप पर ध्यान दें, ये काफी सक्षम डेवलपर्स हैं):

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

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


7
@JoshuaSmith आपको लगता है कि लोगों की उच्च उम्मीदें हैं। क्या आप अपने साथियों में अक्सर निराश महसूस करते हैं?
maple_shaft

4
@maple_shaft मैं इस टीम पर अपने साथियों के साथ शायद ही निराश हूं (मेरी आखिरी नौकरी एक अलग कहानी थी)। आमतौर पर यहां के लोग पेशेवर हैं और उनके साथ काम करने की खुशी है। और हां, मुझे अपने और अपने आसपास के लोगों से बहुत उम्मीदें हैं। मैं हालांकि इसके बारे में एक झटका नहीं हूँ। यह शायद अनुभवहीन है, लेकिन मुझे लगता है कि अगर हम एक दूसरे से उत्कृष्टता की मांग करते हैं तो हम अनिवार्य रूप से सुधार करेंगे।
जोशुआ स्मिथ

9
@JoshuaSmith, अगर आप उम्मीद करते हैं कि लोगों को नियमित रूप से किताबें पढ़ने के लिए समय मिल जाएगा, तो मुझे एक अनुमान लगाने का खतरा है: आपके पास बच्चे नहीं हैं, क्या आप?
Kyralessa

13
@ JoshuaSmith लोगों को उन पुस्तकों को पढ़ने के लिए भुगतान मिलता है? यदि मेरे बॉस ने मुझे बताया कि "हम प्रौद्योगिकी को बदल रहे हैं, तो मुझे उम्मीद है कि आपने इसे अगले महीने तक अपने खाली समय में सीख लिया होगा" मुझे बहुत अफ़सोस होगा।
मात्सेमन्न

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

13

प्रवीण बनाम गित-उन्माद

बुनियादी प्रवीणता जैसे शब्द का मतलब अलग-अलग लोगों के लिए अलग-अलग हो सकता है। बहुत सारे लोगों को यह लगता है कि git-mania (ऐसा नहीं है कि इसमें कुछ भी गलत है)। हम में से कई स्रोत नियंत्रण के साथ अपने स्वयं के और अन्य लोगों की ढिलाई से वास्तव में बुरी तरह से जल गए हैं।

क्यों यह मामला (इतना)

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

बुनियादी प्रवीणता क्या दिखती है?

कुछ ठोस मानदंडों में शामिल हैं:

  • प्रलेखन के संदर्भ के बिना:

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

    • स्थानीय रेपो के लिए उपयोगकर्ता और क्रेडेंशियल्स जोड़ें।
    • स्थानीय रेपो में प्रवेश करें।
    • रिमोट रेपो प्रशासन।
    • अनदेखा फ़ाइलों को कॉन्फ़िगर करें, PKI सार्वजनिक / निजी कुंजी जोड़े उत्पन्न करें।
    • फ़ाइलों को स्थानांतरित करें और हटाएं।
    • किसी विशेष बग को प्रस्तुत करने वाले परिवर्तन को खोजने के लिए बाइसेक्ट का उपयोग करें।

गलतियों से बचने के लिए git का एक ठोस मानसिक मॉडल और प्रबंधित किया जा रहा कोड महत्वपूर्ण है।

आप उन्नत प्रवीणता / विशेषज्ञता के लिए क्या जोड़ेंगे?

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

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


11

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

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

जब तक मैं जानता हूं कि मेरे लिए जीआईटी काम कैसे करना है, मैं एक बंदर को नहीं देता कि जीआईटी कैसे काम करता है।


1
और कस्टम प्रशिक्षण की आवश्यकता है ... और फिर न तो लिनुस ने किसी से भी यह अपेक्षा की कि वे सभी गिट की तकनीकी को अपनाएंगे, इसीलिए आज्ञाओं के दो वर्ग हैं: चीनी मिट्टी के बरतन और नलसाजी।
ZJR

1
अगर आप करना चाहते हैं तो Git के लिए बहुत सारे व्यंजन हैं जो ब्रांड X में आपके द्वारा इस्तेमाल किए गए वर्कफ़्लो से Git में वर्कफ़्लो में माइग्रेट होते हैं।
झेरिको

10

हाँ।

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

Git कई लोगों के लिए एक कठिन संक्रमण है, इसलिए एक अनिवार्य बैठ प्रशिक्षण सत्र क्रम में हो सकता है। इससे लोगों को होने वाले बहुत सारे मुद्दों को सुलझाने में मदद मिलेगी।


3
"कुछ भी नहीं है कि एक उपकरण से डरने वाले या अनजान डेवलपर्स की एक गुच्छा से अधिक उत्पादकता को नुकसान पहुंचाता है।" तो संभवतः एक कंपनी एक उपकरण के साथ लाइव होने के लिए पागल होगी जिसे टीम में प्रशिक्षित नहीं किया गया है और समझ में नहीं आता है।
Jaydee

कंपनियों, विशेष रूप से बड़े लोगों को, कभी-कभी प्रौद्योगिकी को धक्का देना पड़ता है। टीटी एक संगठन के भीतर एक टीम भी हो सकती है जिसने पहले से ही धक्का दिया है और पूरी तरह से टूल का उपयोग कर रहा है।
बिल लीपर

3

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


2

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


1

नहीं; मुझे लगता है कि निम्नलिखित की अपेक्षा करना उचित है:

  1. हाथ से पकड़े बिना रोजमर्रा के कार्य (कमिट, पुश, पुल, ब्रांच, मर्ज, बाइसेक्ट आदि) करें।
  2. बार-बार निर्देश के बिना गैर-नियमित कार्य करें। (कुछ दोहराव ठीक है - मुझे किसी से 2-3 बार मिलना है इससे पहले कि उनका नाम वास्तव में चिपक जाए।)

यदि वे # 1 नहीं कर सकते, तो आपके रोल-आउट का प्रशिक्षण भाग संभवतः अपर्याप्त था। यदि वे # 2 नहीं कर सकते हैं, तो पहले यह सुनिश्चित कर लें कि आप बहुत परेशान होने से पहले चीजों को स्पष्ट रूप से समझा रहे हैं।


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

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

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

@JimmyHoffa मेरा जवाब है "नहीं, यहाँ एक न्यूनतम आपको उचित उम्मीद करनी चाहिए"; मैंने इसे उन सटीक शब्दों में नहीं कहा।
पीजीएस

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