क्या फ्रेड ब्रुक्स की "सर्जिकल टीम" प्रभावी रूप से बस कारक को संभालती है?


10

4 अनुभवी डेवलपर्स की मेरी टीम एक बड़े, मॉड्यूलर विंडोज एप्लिकेशन (लगभग 200 केएलओसी) पर काम करती है। मैंने परियोजना की शुरुआत से (3 साल पहले) कोर कोडबेस पर ध्यान केंद्रित किया है और धीरे-धीरे एक सेमी-लीड डेवलपर की स्थिति में स्थानांतरित कर दिया है, हालांकि मैं टीम मैनेजर नहीं हूं।

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

तीन दिनों में जब से हमने काम शुरू किया, मैंने दो चीजें देखी हैं:

  1. अन्य अनुभवहीन टीम के सदस्यों ने लगभग 1 या उससे कम कार्य पूरा किया।

  2. कार्रवाई में ब्रूक का नियम : मैंने अपना लगभग आधा समय सहायता प्रदान करने में लगाया (घटकों का उपयोग करने पर उन्हें कोच करने का प्रयास)। नतीजतन, मैंने अपेक्षित 5 या 6 के बजाय केवल 2 कार्य खुद ही समाप्त कर दिए।

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

  1. ट्रक / बस फैक्टर को सीमित करें - अब इन कौशलों पर अन्य डेवलपर्स को रैंप दें, ताकि भविष्य में किसी को भी काम दिया जा सके, सिर्फ मुझे नहीं।
  2. एक "अड़चन" (मुझे) को खत्म करने और तेजी से काम पूरा करने के लिए।

स्पष्ट होने के लिए, मुझे कोई समस्या नहीं है: ए) समय शिक्षण का निवेश, बी) मेरे कोड को छूने वाले लोग, या सी) नौकरी की सुरक्षा। वास्तव में, मैं नियमित रूप से टीम लीडर को सुझाव देता हूं कि मैं जोखिम कम करने के लिए कोर कोडबेस के कुछ पहलुओं पर अन्य देवों को प्रशिक्षित करूं।

इस पुनरावृत्ति में हमारे पास लक्षित उच्च प्राथमिकता वाले बग फिक्स का एक बड़ा संग्रह है, इसलिए ऐसा प्रतीत होता है कि यदि कार्यभार को पुनर्वितरित किया गया तो अधिक प्रगति हो सकती है।

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

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

इसी तरह के सवाल:


1
टीम में अपने कौशल का संचार करने के लिए इसे प्रशिक्षण मानें।

जवाबों:


5

वास्तव में, मैं तर्क दूंगा कि आप "सर्जिकल टीम" मॉडल का अनुसरण कर रहे हैं। सौभाग्यशाली!

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

यह सर्जन का काम है कि वे कमजोर स्थानों की तलाश करके और उन्हें हल करने के साथ-साथ शीर्ष डेवलपर होने के नाते अपनी टीम की जांच और प्रबंधन करें। आपके पास एक गैर सर्जन (व्यवसाय प्रबंधक) ऐसा नहीं हो सकता है, क्योंकि वे आवश्यक कौशल को नहीं समझते हैं, एक मास्टर शिल्पकार को एक प्रशिक्षु की तरह।

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

या, जूनियर्स गलती कर सकते हैं। उनके लिए ऐसा करने का यह सही समय है, क्योंकि उनके पास कोई न कोई अपने कंधे पर देखता है। ऑस्कर वाइल्ड ने कहा

अनुभव बस नाम है जो हम अपनी गलतियों को देते हैं।

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


जवाब के लिए धन्यवाद। पहले से ही, यह अनुभव निश्चित रूप से हमारी टीम की दो कमजोरियों को प्रकट कर रहा है: 1) हमारा कोर कोडबेस बहुत बड़ा है, और अधिक संशोधन की आवश्यकता है, और 2) जब हम अधिक संशोधित करते हैं, तो अन्य डेवलपर्स को इसके बजाय नए घटकों का नेतृत्व करने की आवश्यकता होती है; मुझे। इससे भी बड़ा मुद्दा, जो मेरे मूल प्रश्न का हिस्सा नहीं है, यह है कि मुझे प्रबंधक (जो "आधिकारिक" सर्जन) है, की तुलना में कोड का बड़ा ज्ञान है, इसलिए वह प्रभावी ढंग से प्रतिनिधि नहीं बना रहा है क्योंकि वह इमो कर सकता है। ।
केविन मैककॉर्मिक

@KevinMcCormick - ऐसा लगता है कि आपको अपने प्रबंधक को इन चीजों के बारे में चिंता करने की अनुमति देनी चाहिए। अपने अनुमानों को समायोजित करें अब अपने कार्यों के साथ अपने टीम के सदस्यों की मदद करें। आपने ऐसा करने के औचित्य के बारे में कहा।
रामहुंड १४'१२

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

7

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

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

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

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

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


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

6

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


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

@KevinMcCormick - क्या होगा अगर मीडिया प्लेयर को विंडोज कर्नेल में जोड़ा जा रहा है, ऐसा करने के लिए वैध बहाना। ऐसा लगता है कि आप नहीं चाहते कि टीम के सदस्य कोर सिस्टम आर्किटेक्चर के साथ अधिक फेमस हो जाएं, और मैं ऐसा करने का कारण नहीं देख सकता, यह केवल लंबे समय में आपकी मदद करेगा।
रामहाउंड

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

3

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

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

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

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

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

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


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

3
+1 कुछ बॉस बेवकूफ हो सकते हैं, लेकिन कई बार आपके बॉस के पास एक व्यापक दृष्टिकोण होता है और आपको बस उस पर भरोसा करना होता है।
फिल

@Phil - यह ईमानदारी से लगता है कि इस मामले में बॉस वास्तव में एक अच्छा दृष्टिकोण हो सकता है। उसे समय के बारे में चिंता करने दें, देर से आने की चिंता करें, उसने आखिर अनुमान प्रदान किया। सबसे खराब स्थिति, क्रंच का समय होता है, और आप बाकी सब कुछ खुद समाप्त कर लेते हैं।
रामहुंड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.