आप अपने साथी प्रोग्रामर को बढ़ने में कैसे मदद करते हैं?


20

एक टीम के नेतृत्व के रूप में, आप अपने प्रोग्रामरों को विकसित करने में कैसे मदद कर सकते हैं?

मैं इसका कारण पूछता हूं क्योंकि मेरे साथ काम करने वाले कुछ प्रोग्रामर हैं, और मैं वास्तव में "उन्हें ढीली चालू करना चाहता हूं", उनकी अधिकतम क्षमता का एहसास करने के लिए, और उन्हें खुश रखने के लिए।

लेकिन मैं यह नहीं जानता कि यह कैसे करना है, क्या मुझे करना है

  1. उनके साथ अक्सर बातचीत करते हैं, या उन्हें शांत समय देते हैं, उन्हें अनदेखा छोड़ देते हैं?
  2. उन्हें कोडिंग दिशानिर्देशों का पालन करने के लिए कहें, जैसे कि इकाई परीक्षण लागू करना, शैलियों को कोड करना, या उन्हें जो कुछ भी उचित लगे, उन्हें करने दें?
  3. उनके साथ उदार रहें। जैसे कि वास्तव में परवाह नहीं है कि क्या वे वास्तव में 8 घंटे या 4 घंटे के लिए कार्यालय में आते हैं, या कार्यस्थल में कुछ "विषयों" को लागू करने की आवश्यकता है?

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

तुम क्या सोचते हो?


21
उन्हें डोनट्स खिलाएं।
तर्क

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

@ एसके-लॉजिक: राउंड जहां मैं काम करता हूं, पिज्जा पसंदीदा तरीका है।
डोनाल्ड फेलो

जवाबों:


9

यह बहुत ही महीन रेखा है जिसे आपको चलना होगा।

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

दूसरी ओर, प्रक्रिया विकल्प आपके हैं। उन फैसलों में, टीम को आपका मार्गदर्शन करने दें लेकिन अंततः आपको उन्हें बनाने की आवश्यकता है। कम से कम पहले।

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

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


6

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

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

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

उन्हें कोडिंग दिशानिर्देशों का पालन करने के लिए कहें, जैसे कि इकाई परीक्षण लागू करना, शैलियों को कोड करना, या उन्हें जो कुछ भी उचित लगे, उन्हें करने दें?

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

उनके साथ उदार रहें। जैसे कि वास्तव में परवाह नहीं है कि क्या वे वास्तव में 8 घंटे या 4 घंटे के लिए कार्यालय में आते हैं, या कार्यस्थल में कुछ "विषयों" को लागू करने की आवश्यकता है?

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


3

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

हालांकि, आप उन्हें बढ़ने में मदद करना चाहते हैं जो एक नेता में एक महान विशेषता है।

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

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

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

पहले उन्हें इस मुद्दे को स्वयं जानने का मौका दें। लेकिन कभी-कभी लोग फंस जाते हैं और नहीं जानते कि कहां से शुरू करें (एक ऐसा कौशल जिसे आपको विशेष रूप से नए प्रोग्रामर में विकसित करने की आवश्यकता है) या किसी समस्या को हल करने के लिए क्या करना चाहिए।

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

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

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

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

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

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

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


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

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

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


1

उनके साथ अक्सर बातचीत करते हैं, या उन्हें शांत समय देते हैं, उन्हें अनदेखा छोड़ देते हैं?

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

उन्हें कोडिंग दिशानिर्देशों का पालन करने के लिए कहें, जैसे कि इकाई परीक्षण लागू करना, शैलियों को कोड करना, या उन्हें जो कुछ भी उचित लगे, उन्हें करने दें?

आपको उनसे अपेक्षा करनी चाहिए कि आप ठीक उसी मानकों पर काम करें जो आप करते हैं। यदि आप इकाई परीक्षण करते हैं और दिशानिर्देशों का पालन करते हैं तो उन्हें करना चाहिए। उन्हें यह सीखने की ज़रूरत है कि कैसे अच्छी तरह से कोड करें और इसे सिखाने के लिए आपकी ज़िम्मेदारी।

उनके साथ उदार रहें। जैसे कि वास्तव में परवाह नहीं है कि क्या वे वास्तव में 8 घंटे या 4 घंटे के लिए कार्यालय में आते हैं, या कार्यस्थल में कुछ "विषयों" को लागू करने की आवश्यकता है?

मैं पहली बार में अधिक अनुशासित हो जाऊंगा लेकिन आसानी से जब वे साबित हो जाएंगे कि उन पर भरोसा किया जा सकता है। लोगों को विश्वास दिलाते हुए कि एक 4h दिन से काम करना सही है, लेकिन परेशानी के लिए पूछ रहे हैं, जो एक मूल्यवान कर्मचारी को नियमित रूप से देर से काम करने देता है, परियोजनाओं के बीच कुछ सुस्ती है।


5
"मोटे तौर पर हर कुछ घंटों में एक बार सही आवृत्ति लगती है" - मैं व्यक्तिगत रूप से नफरत करता हूँ अगर मेरा प्रबंधक मुझे बार-बार
परेशान करता रहे

1
@ Péter Török Thats क्यों मैंने कहा कि इसे कान से बजाओ। मेरे लिए सही स्तर है, लेकिन यकीन है कि बहुत से लोग कम पसंद करेंगे
टॉम स्क्वायर्स

0

आपके तीन बिंदुओं से संबंधित:

उनके साथ अक्सर बातचीत करते हैं, या उन्हें शांत समय देते हैं, उन्हें अनदेखा छोड़ देते हैं?

मैं कहूँगा कि यह वास्तव में आपके साथ काम करने वाले व्यक्ति के प्रकार पर निर्भर करता है। कुछ निश्चित कॉफी समय (लगभग 10 बजे के आसपास) पर चर्चा करना पसंद करते हैं और अन्यथा अकेले काम करते हैं, बिना किसी बाधा के। उनके साथ (ठीक है, मैं मानता हूं, मैं बिल्कुल वैसा ही हूं), मैं आम तौर पर ईमेल भेजता हूं (यहां तक ​​कि जब वे मेरे पास होते हैं, जैसे कि 2-3 मीटर दूर), ताकि आप जब वे आपकी जानकारी पढ़ें, तो आप उन्हें पसंद छोड़ दें । और वैसे, उनसे यह न पूछें कि क्या उन्हें "आपका मेमो मिला" :-) और निश्चित रूप से, कुछ को "अधिक" मार्गदर्शन, और अधिक सहभागिता की आवश्यकता है।

उन्हें कोडिंग दिशानिर्देशों का पालन करने के लिए कहें, जैसे कि इकाई परीक्षण लागू करना, शैलियों को कोड करना, या उन्हें जो कुछ भी उचित लगे, उन्हें करने दें?

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

उनके साथ उदार रहें। जैसे कि वास्तव में परवाह नहीं है कि क्या वे वास्तव में 8 घंटे या 4 घंटे के लिए कार्यालय में आते हैं, या कार्यस्थल में कुछ "विषयों" को लागू करने की आवश्यकता है?

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


0

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


0

लेकिन मैं यह नहीं जानता कि यह कैसे करना है, क्या मुझे करना है

  1. उनके साथ अक्सर बातचीत करते हैं, या उन्हें शांत समय देते हैं, उन्हें अनदेखा छोड़ देते हैं?
  2. उन्हें कोडिंग दिशानिर्देशों का पालन करने के लिए कहें, जैसे कि इकाई परीक्षण लागू करना, शैलियों को कोड करना, या उन्हें जो कुछ भी उचित लगे, उन्हें करने दें?
  3. उनके साथ उदार रहें। जैसे कि वास्तव में परवाह नहीं है कि क्या वे वास्तव में 8 घंटे या 4 घंटे के लिए कार्यालय में आते हैं, या कार्यस्थल में कुछ "विषयों" को लागू करने की आवश्यकता है?

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

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


0

आप उनसे पूछें कि वे कैसे काम करना पसंद करेंगे।
वे क्या बदलना चाहते हैं और इसी तरह।

एक बार में सभी नहीं। बस ... जैसा कि चीजें दिखाती हैं।
प्राकृतिक रहें। (या वे डर को सूंघेंगे)

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

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

एक स्थापित करें लोकतांत्रिक प्रक्रिया , चीजों को वोट दें, मुद्दों पर चर्चा करें।

हर राष्ट्रपति की तरह, आप अंतिम शब्द रखते हैं: वीटो
बाकी समूह पर निर्भर है।


0

अपने लोगों को विकसित होने में मदद करने का एक तरीका यह है कि उन्हें वह करने दें जो वे सर्वश्रेष्ठ करते हैं।

यदि आप भाग्यशाली हैं, तो आपके पास एक या दो प्रोग्रामर होंगे जिनके व्यक्तिगत "परीक्षण" मानक पूरे विभाग की तुलना में सख्त हैं। उस मामले में, आप उन्हें उन मुद्दों के लिए "सम्मान प्रणाली" पर रख सकते हैं, या यहां तक ​​कि उनके तरीकों को भी अपना सकते हैं।

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

लेकिन प्रबंधक के रूप में आपका एक काम WEAKNESSES को सही करना है। यही है, आपको उन सुस्त प्रोग्रामर पर BEAR DOWn करना होगा जिनके परीक्षण मानक अपर्याप्त हैं, या वे लोग जो पर्याप्त उत्पादक नहीं हैं - क्योंकि वे समय नहीं लगा रहे हैं।

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