मैं एक प्रबंधक हूं। मैं प्रोग्रामर के साथ काम के संबंधों और संचार को कैसे बेहतर बना सकता हूं? [बन्द है]

431

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

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

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

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

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

मैं उम्मीद कर रहा हूं कि लोग अच्छी चीजों के बारे में शिकायत न करें। यदि आप अपने कार्यस्थल और प्रेम को पसंद करते हैं (या कम से कम जैसे :)) आपके प्रबंधक, कृपया मुझे उनके बारे में बताएं। वे सही क्या कर रहे हैं? इसी तरह, यदि आप इसे नफरत करते हैं, तो कृपया विस्तार से वर्णन करें कि क्यों। मैं संचार में सुधार के बारे में उत्तर ढूंढ रहा हूं क्योंकि मुझे लगता है कि यह मेरी समस्या है, लेकिन मैं गलत हो सकता हूं।

management

— AgentSmith
स्रोत

45

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

— रैंडी मिंडर जूल

97

उपकरण के बारे में: आपकी टीम की लागत लगभग $ 100 / घंटा है। अगर वे कहते हैं कि उन्हें कुछ चाहिए, एक मशीन, एक किताब, एक और मॉनिटर, एक कुर्सी, एक डेस्क, एक हेडसेट, इसे प्राप्त करें। यदि आपके पास इन तुच्छ व्यय के लिए अधिकार नहीं है, तो जारी टर्नओवर की अपेक्षा करें।

— केविन क्लाइन

22

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

— जॉब

27

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

— एरिक ब्राउन - काल

29

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

— माइकल एम्स

331

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

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

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

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

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

मुझे लगता है कि मेरे पसंदीदा प्रबंधकों के बारे में मुझे जो # 1 बातें पसंद हैं, वह थी:

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

— बेटलक्ष्मी
स्रोत

14

इंट्रोवर्ट्स के साथ समस्या यह है कि हम हमेशा याद नहीं रखते हैं कि एक्सोवर्ट भी मानसिक नहीं हैं।

— मिररफेडेट

2

ओह रुको, यह एक ब्लॉग पोस्ट नहीं था - मैं अभी भी प्रोग्रामर पर हूँ! बहुत बढ़िया!

— Xeoncross

17

कहीं +10 बटन होना चाहिए ...

— मार्जन वेनमा

3

धन्यवाद गिरोह! मैं नहीं कह सकता कि इन टिप्पणियों को देखना कितना अच्छा है! यह मुझे लिखता रहता है! :)

— १

3

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

— क्ज़कई

160

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

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

इसलिए, IMHO जवाब का पहला हिस्सा आपके डेवलपर्स को यह बताने के लिए होना चाहिए कि आप मानसिक नहीं हैं, और वास्तव में यह तकनीकी रूप से मूर्खतापूर्ण है। आप भरोसा कर रहे हैं, समय पर फैशन में आप पर आने के लिए भरोसा कर रहे हैं और उन पर भरोसा कर रहे हैं। आप उनके जीवन को आसान बनाने के लिए हैं, कठिन नहीं।

और आप जो भी करते हैं, उनसे ऐसे प्रश्न न पूछें, जिनका उत्तर आप वास्तव में नहीं जानना चाहते हैं - ऊपर "गलत अनुमान" का उल्लेख; ;-)। यह एक डेवलपर की क्रिप्टोनाइट है।

— जोरिस टिम्मरमन्स
स्रोत

5

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

— क्रिस्टोफर जॉनसन

7

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

— झूल

5

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

— एसटीडब्ल्यू

11

@Charles ई। अनुदान: "जिनमें से सभी को कठिन तिथियों की आवश्यकता है" ... जबकि सच; शुरुआती अनुमान कल्पना मात्र हैं। एक प्रबंधक जो हाथ में काम किए सॉफ्टवेयर के बिना गंभीर नकद प्रतिबद्धता करता है, वह आश्चर्यजनक रूप से काम कर रहा है। अशुद्धि के लिए दोष देने वाले डेवलपर्स की बात याद आती है। "अनुमान" के आधार पर प्रतिबद्धताएं बनाना अक्सर खराब व्यवसाय होता है।

— S.Lott

4

@ -S.Lott, लड़का, जो मैंने एक प्रमुख सिकुड़ने वाले रैप सॉफ्टवेयर कंपनी, और छोटे सॉफ्टवेयर ठेकेदारों के एक जोड़े में काम किया है, और मैंने कभी उनमें से किसी को भी आपके सुझाए दृष्टिकोण का उपयोग करते नहीं देखा। यह निश्चित रूप से विकास करने वाली कंपनी के लिए जोखिम को कम करेगा, लेकिन यह ग्राहकों के लिए जोखिमों की अनदेखी करता है: प्रतियोगिता, बाजार की खिड़कियां, नियामक आवश्यकताएं, आदि मैंने कभी किसी को निर्दिष्ट कार्यक्रम के बिना कस्टम विकास के लिए एक अनुबंध की पेशकश नहीं देखी। क्या आप किसी प्रकार की प्रतिबद्धता प्राप्त किए बिना किसी होम रीमॉडेल के लिए एक ठेकेदार को काम पर रखेंगे, क्योंकि नौकरी में कितना समय लगेगा?

— चार्ल्स ई। ग्रांट

69

यहाँ बहुत सारी अच्छी चीजें हैं लेकिन मुझे लगता है कि निम्नलिखित की आवश्यकता है .. .. कठोर होने के लिए कहें .. लेकिन यह कहा जाना चाहिए:

एक पीएम के रूप में 5 साल, और यह नहीं पता कि एक डेवलपर को किस तरह के पीसी की जरूरत है, अपमानजनक है।
अपने पहले वास्तविक लाल झंडे के रूप में खराब काम करने की स्थिति के कारण एक डेवलपर को छोड़ देना , पागल है।

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

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

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

"अगर आप कुछ नहीं करते हैं तो हम अपना सर्वश्रेष्ठ आदमी खो देंगे"

वह लाल झंडा # 2 होना चाहिए।

— मोरोन
स्रोत

10

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

— n

"कोई नहीं बताता कि क्या गलत है", बिल्कुल सच।

— बज़

37

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

आपने स्वीकार किया कि आपके पास एक समस्या है, इसलिए, यह एक शानदार शुरुआत है।

काइज़ेन के पाँच प्राथमिक तत्व हैं:

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

( स्रोत )

यदि आप इसे लंबे समय तक देखते हैं तो उन तत्वों पर एक निरंतरता टीम वर्क और प्रतिक्रिया पर जोर देती है।

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

तो, मेरी पहली सलाह:

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

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

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

— विटर पाय
स्रोत

7

+1, पौराणिक मानव-महीना। वह किताब पुरानी हो सकती है, लेकिन यह कभी पुरानी नहीं होती।

— डेविड हैमेन

इसके अलावा वर्षगांठ संस्करण नब्बे के दशक के लिए कुछ उत्कृष्ट नई सामग्री जोड़ता है। मुझे उम्मीद है कि वे 2015 में एक 40 वीं वर्षगांठ संस्करण का उत्पादन करेंगे। * 8 ')

— मार्क बूथ

3

कुछ भी नहीं झूठ से तेजी से मनोबल को मारता है। सबसे बड़ा झूठ प्रबंधन कहता है, "आपको अपना काम करने के लिए XYZ की आवश्यकता नहीं है।" वे संभवतः आपसे बेहतर कैसे जान सकते हैं? इसलिए वे झूठ बोलते हैं, इसलिए कोई भरोसा नहीं है, इसलिए कोई मनोबल नहीं है। XYZ को "मॉनिटर, सॉफ्टवेयर, तेज हार्डवेयर, सर्वर, भोजन, शांत कार्य क्षेत्र, बड़ी मात्रा में डेस्क स्पेस, व्हाइट बोर्ड, अन्य-शुगर खाद्य पदार्थों के साथ ब्रेक रूम, लचीली अनुसूची, आदि के साथ बदलें ..." जब प्रबंधन नहीं होता है ' t बाहर आओ और विशेष रूप से पूछें: "आपको अपना काम अच्छी तरह से करने की क्या आवश्यकता है, मेरा मतलब है, मैं इसे आपके लिए लाऊंगा" वे स्पष्ट रूप से नहीं करना चाहते हैं। कोई मनोबल नहीं।

— क्रिस्टोफर महान

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

— अल्ज

26

इसे पढ़ें:

http://agilemanifesto.org/

व्यक्तियों और प्रक्रियाओं और उपकरणों पर बातचीत

व्यापक प्रलेखन पर काम कर रहे सॉफ्टवेयर

अनुबंध बातचीत पर ग्राहक सहयोग

एक योजना के बाद बदलने का जवाब

कई मामलों में, संगठन (यानी, आपके बॉस) आप की मांग करता है

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

यह हो सकता है कि समस्या आपकी व्यक्तिगत संचार कौशल न हो।

हो सकता है कि संपूर्ण विकास "पर्यावरण" या "कार्यप्रणाली" बुरी तरह से टूट गया हो, और बुरी भावनाएं केवल सामान्य बुरी प्रथाओं का एक लक्षण हैं।

— एस.एल.टी.
स्रोत

3

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

— एंडी

@ ऑंडी: एक विषाक्त संगठन अक्सर खराब संचार का मूल कारण होता है। लोग संवाद करना चाहते हैं। हालांकि, एक उच्च-स्तरीय प्रबंधक आसानी से चुप्पी को पुरस्कृत करने और संचार को दंडित करके इसे रोक सकता है।

— S.Lott

3

@ एस.लॉट: हर कोई "संवाद" नहीं करना चाहता।

— मिररफाइंड

3

@ एस.लॉट: हर कोई संवाद नहीं करना चाहता। और यहां तक कि अगर वे करते हैं, तो हर प्रभावी रूप से संवाद नहीं करता है, जो इस संगठन में मामले की तरह लगता है।

— एंडी

1

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

— बेंजोल

22

मेरे लिए यह ऐसा लगता है जैसे आपने एक आसान वातावरण में देवताओं के साथ कभी बात नहीं की। उनके साथ आपकी बातचीत केवल आधिकारिक प्रकृति की थी? यह बहुत बुरा है।

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

यदि वे आप पर भरोसा करते हैं और मोहरा ऑफर होने के बारे में डरने की जरूरत नहीं है, तो वे सबसे अधिक संभावना आपको अनाकर्षक सत्य भी बताएंगे।

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

— चलता है
स्रोत

बहुत अच्छा उद्धरण: "मैं सभी दोष लेता हूं और मैं उनके साथ प्रसिद्धि साझा करता हूं।"

— जेरेड बुरो

20

ताली! ताली! ताली! आपको निश्चित रूप से एक अच्छा व्यक्ति होना चाहिए, क्योंकि आप यह देखने के लिए खुले में निकल आए हैं कि आपकी नौकरी में बेहतर होने के लिए क्या किया जा सकता है।

कृपया नीचे देखें कि मैंने एक महान प्रबंधक में क्या देखा है, और व्यक्तिगत रूप से अपनाया है जब मैं एक वरिष्ठ सदस्य के रूप में टीम का नेतृत्व करता हूं।

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

आप अपने ईमानदार प्रयास में शुभकामनाएँ :)

— karthiks
स्रोत

2

हां, वह निश्चित रूप से एक अच्छा इंसान होना चाहिए । मुझे बुरे लोगों से नफरत है।

— Xeoncross

विस्फोटक रूप से भी आग लगा सकता है;)

— वेन वर्नर

23

अपने अंडरलाइनिंग के साथ संवाद करने के लिए उस तरह के सिंक का उपयोग न करें।

— RMorrisey

16

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

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

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

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

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

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

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

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

— कीथ को प्रकट करता है
स्रोत

1

टाइप-वाई व्यक्तित्व विशेषता क्या है जिसके बारे में आप बात कर रहे हैं? क्या इस पर अधिक विस्तार के लिए कोई लिंक है?

— टाइलेरमैक

3

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

— कीथ्स

3

Google के लिए उचित शब्द थ्योरी X और थ्योरी Y है

— मार्क कैनलस

11

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

और भगवान के प्यार के लिए, एक 40 घंटे काम सप्ताह रखने की कोशिश करें। इसके अलावा, अस्थायी। पूरी दुनिया बकवास के लिए फ्लेक्सटाइम बना सकती है। मेरे लिए कम से कम।

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

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

— फिलिप
स्रोत

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

— मार्क बूथ

8

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

सौभाग्य।

— पीएसयू
स्रोत

7

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

— JeffO
स्रोत

3

प्रतिक्रिया स्वीकार करने और उस पर अभिनय करने के लिए +1। संभवतः सबसे महत्वपूर्ण चीजें जो एक प्रबंधक कर सकता है।

— PSU

1

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

— झूल

7

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

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

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

— Codism
स्रोत

5

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

मैं जो बहुत बार देखता हूं कि मूल्य प्रणालियों और परिचालन विधियों / प्रबंधन और डेवलपर्स के बीच दृष्टिकोण में पर्याप्त अंतर हैं।

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

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

— wolfgangsz
स्रोत

5

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

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

— मॉर्गन हेरलॉकर
स्रोत

1

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

— ट्रिडस

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

— मॉर्गन हेरलॉकर

1

+1 के लिए "मेरे पास मौजूद हर मुद्दा मुझे अवास्तविक अनुमानों को छोड़कर अपवाद के साथ एक डोनट सौंपकर हल किया जा सकता है।"

— केके

4

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

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

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

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

— जेबी किंग
स्रोत

3

क्या देवों को लगता है कि आप उनके वकील हैं? इसके द्वारा मेरा मतलब है कि वे जानते हैं कि वे आपकी चिंताओं / कुंठाओं को बिना पीटे आपके साथ साझा करने के लिए स्वतंत्र हैं? क्या उन्हें लगता है कि आप उनके लिए लड़ते हैं? क्या उन्हें लगता है कि आप उनके काम की सराहना करते हैं? क्या उन्हें लगता है कि आप वास्तव में उन्हें अपने करियर में सफल बनाना चाहते हैं?

यदि वे सराहना महसूस करते हैं, तो आपके पास बेहतर संचार होगा।

— डेविड वेसर
स्रोत

3

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

मुझे पता है कि कुछ डेवलपर्स बहुत सामाजिक रूप से आश्चर्यजनक हैं, लेकिन मुझे लगता है कि मंझला अंतर्मुखी नीरद की ओर झुकता है।

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

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

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

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

— जेसी ग्रीथहाउस
स्रोत

2

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

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

एक-से-एक पर अच्छा संदर्भ - http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html

— जॉन क्रिस्टेंसन
स्रोत

2

छोटा एवं सुन्दर। एक्सेल में आप क्या करते हैं - यह संचार को बढ़ाएगा।

आपके डेवलपर्स के लिए क्या बढ़िया है? .. पढ़ें, फिर से पढ़ें, हाँ यहां तक कि PeopleWare का अध्ययन करें

— स्टीफन बेली
स्रोत

1

ऊपर पोस्ट में सभी महान विचारों और टिप्पणियों!

यहां एक विचार है: अपने स्थानीय सामुदायिक कॉलेज में संचार कार्यशालाओं में अपने आईटी कर्मचारियों को भेजें - कंपनी द्वारा भुगतान किया गया, निश्चित रूप से।

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

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

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

बस मेरे 2 बिट्स :)

— मार्टिन एस। स्टोलर
स्रोत

3

यह मानते हुए कि समस्या प्रोग्रामर के साथ है और मेरे पास नहीं है ... ऊपर दिए गए उत्तरों को पढ़ने से मुझे पहले से ही बहुत जानकारी मिली है।

— एजेंटस्मिथ

1

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

— रिवाइज ह्यूटसेकर
स्रोत

1

बियर के लिए टीम को बाहर ले जाएं (और आप खरीद रहे हैं)।

— ग्राहम बोरलैंड
स्रोत

2

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

— एक CVn

+1: हां पता है ... यह एक चांदी की गोली नहीं है (और आपने कभी नहीं कहा कि यह था), लेकिन यह अभी भी घावों को ठीक कर सकता है।

— जिम जी।

1

मुझे पार्टी के लिए देर हो रही है, लेकिन बस इस सवाल को देखा।

एक बात जो मुझे बहुत अच्छी तरह से पता नहीं है वह यह है:

ग्रंट कभी भी सूट को पूरी सच्चाई नहीं बताते हैं। रैंड्स डीएनए में यह कहते हैं, लेकिन यह सिर पर नहीं है, वह एक अलग विषय पर है।

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

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

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

— पॉल नाथन
स्रोत

1

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

— मैथ्यू
स्रोत

0

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

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

— थॉमस ओवेन्स
स्रोत

0

कुछ महान उपन्यास पढ़ें जो तकनीकी कर्मचारियों के दृष्टिकोण में अंतर्दृष्टि देते हैं:

हैकर्स, स्टीवन लेवी - http://en.wikipedia.org/wiki/Steven_Levy
माइक्रोसेफ्स, डगलस कपलैंड - http://en.wikipedia.org/wiki/Douglas_Coupland
कैथेड्रल और बाज़ार, एरिक रेमंड - http://en.wikipedia.org/wiki/Cathedral_and_the_B बाज़ार

ये प्रबंधन पर किसी भी विशिष्ट संस्मरण के रूप में महत्वपूर्ण हैं (ड्रकर एट अल)।

— जोनाथन क्लाइन आईईईई
स्रोत

0

मैंने कई वर्षों में विभिन्न भूमिकाएँ की हैं - डेवलपर, वरिष्ठ डेवलपर, तकनीकी लीड आदि।

आपके प्रश्न से - यह काफी स्पष्ट है कि आपके डेवलपर्स आपको सामान नहीं बताते हैं क्योंकि उन्हें नहीं लगता कि आप मदद कर सकते हैं।

इसकी वजह 2 कारण हो सकते हैं।

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

यदि यह किसी भी या उपरोक्त सभी है, तो आपको इसे सुधारने की आवश्यकता है।

— user93353
स्रोत

-1

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

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

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

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

— रिचर्ड
स्रोत

-1

टीम को खुश रखना बहुत आसान है

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

टीम आउटिंग एक अच्छा विचार है (कुछ गेम प्लान हो सकते हैं)

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

यह सुनिश्चित करने के लिए टीम के प्रत्येक सदस्य के साथ 1: 1 द्वैमासिक करें कि वे सहज हैं।

अंतिम लेकिन कम से कम यह एक अच्छा विचार हो सकता है कि आप परियोजना को कार्यात्मक रूप से और कुछ तकनीकी रूप से भी समझें।

कृपया मुझे बताएं कि क्या आपके पास अधिक प्रश्न हैं

— राहुल
स्रोत

1

-1: आप बहुत ही "मैकेनिकल" उपचार बता रहे हैं और आप ऑटोमेटन जैसे डेवलपर्स का इलाज कर रहे हैं।

— जिम जी।

-1

मैं भी (फ्रेंच तो मेरी अंग्रेजी माफ) सॉफ्टवेयर प्रबंधक जो एक वैज्ञानिक इंजीनियरिंग पृष्ठभूमि है, लेकिन विशेष रूप से आईटी सॉफ्टवेयर पृष्ठभूमि मूल रूप से नहीं है। इसलिए मुझे भीख मांगने में कोई विशेष आत्मीयता नहीं है, लेकिन मैं डेमिंग के स्कूल से एक सांख्यिकीय गुणवत्ता इंजीनियर रहा हूं, जो हर "आधुनिक" स्कूलों में एक बहुत बड़ा शिक्षण है, जिसके बाद वे डेमिंग से विरासत का नाटक करते हैं। सबसे बुरा 6 सिग्मा है, दुबला बेहतर था लेकिन दुर्भाग्य से यह क्या हुआ है http://leanandkanban.wordpress.com/2011/05/13/what-did-deming-really-say :

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

"जब टूलकिट (जैसे, वैल्यू-स्ट्रीम मैपिंग, KPI बोर्ड, सेल, कानबन) में यह घटता है, तो एक समान बात घटित हुई।"

"झुक और सिक्स सिग्मा किसी भी तरह से उत्कृष्ट जापानी कंपनियों या उनके शिक्षकों की मूल सोच को प्रतिबिंबित नहीं करते हैं।"

आज का फुर्तीला आंदोलन दुबला जैसा है (जेफ सदरलैंड पाठ्यक्रम देखें और डेमिंग http://blogs.forbes.com/stevedenning/2011/05/27/Jff-sutherland-the-21st-century-will-be-the का सम्मान -century-of-scrum / ), यह झरना से बेहतर है, लेकिन यह अभी भी डेमिंग के मूल शिक्षण से बहुत दूर है क्योंकि अपने मूल पाठ में डेमिंग को पढ़ने के बजाय, गुरु ने उसे फिर से पैकेज किया, जो प्रबंधन के अपने पूरे 14 सिद्धांतों को उद्धृत नहीं करता है। और उन उपकरणों और सेमिनारों को बेचता है जिनका मूल्य बहुत कम है।

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

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

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

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

निष्कर्ष के रूप में: डेवलपर्स के साथ नारों को खत्म करें (यह वास्तव में डेमिंग के 14 सिद्धांतों में से एक है), उन्हें दिखाएं कि आप प्रोजेक्ट कंक्रीट सॉफ़्टवेयर के बारे में परवाह करते हैं, न कि केवल दस्तावेजों या ऊपरी प्रबंधन के साथ आपकी बैठक के बारे में।

— लेपिन कोन्ग
स्रोत

-1: ओपी की समस्याओं को हल करने का प्रयास नहीं करेगा। इस पोस्ट से सभी डेमिंग संदर्भ निकालें। वे लागू नहीं हैं।

— जिम जी।