क्या डेवलपर्स को प्रोजेक्ट पर घूमना अच्छा या बुरा विचार लगता है?


38

मैं एक छोटी टीम पर काम कर रहा हूं जो कि एक और छोटी टीम के साथ एक बड़े नए प्रोजेक्ट पर काम करना शुरू कर देगी। दूसरी टीम वर्तमान में एक विरासत प्रणाली पर काम कर रही है जिसे वे वर्षों से काम कर रहे हैं।

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

मैं हर 2-3 महीनों में परियोजना से डेवलपर्स को घुमाने के लाभ और कमियां (यदि कोई हो) जानना चाहता हूं।

मुझे पता है कि यह "क्या डेवलपर को एक अच्छा या बुरा विचार घुमा रहा है?" , लेकिन यह सवाल एक लीड डेवलपर पर केंद्रित है। यह सवाल पूरी टीम को प्रोजेक्ट को चालू और बंद करने के बारे में है (नई परियोजना के लिए लीड को घुमाया जा सकता है या नहीं - मुझे अभी तक पता नहीं है)।



2
मैंने प्रश्न में अपनी व्यक्तिगत राय देकर इसे व्यक्तिपरक / तर्कशील प्रश्न में नहीं बनाया। मेरी आंत की भावना यह है कि यह एक अच्छी विचारधारा नहीं है, लेकिन शायद कुछ ऐसा है जो मुझे नहीं पता है :)
क्रिश्चियन पी

1
जब आप उससे पूछते हैं तो प्रबंधक ने क्या कारण दिया? डेवलपर्स के अवकाश में किसी उत्पाद के बारे में ज्ञान साझा करना कंपनी के सर्वोत्तम हित में है।
dcaswell

1
ये एक समस्या है। यदि आपका प्रबंधन पहले से ही इस बारे में पूरी तरह से पारदर्शी नहीं हो रहा है, तो यह संभवतः एक संकेत है कि उन्होंने इसके बारे में बिल्कुल नहीं सोचा है।
एरॉन

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

जवाबों:


76

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

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

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

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

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

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

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

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


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

4
@mnnz: उच्च उत्पादकता, कर्मचारी प्रतिधारण, और समय पर / बजट पर जहाज करने में सक्षम प्रबंधक के अलावा "एंड गेम" क्या है? मैं यहां नैतिक प्रबंधकों के बारे में बात कर रहा हूं , जो वास्तव में ऐसा करना चाहते हैं जो कंपनी के लिए सबसे अच्छा है और अपने स्वयं के व्यक्तिगत कैरियर के लक्ष्यों को आगे बढ़ाने के लिए टीम या प्रोजेक्ट का उपयोग वाहन के रूप में नहीं कर रहे हैं। एक सॉफ्टवेयर संगठन साम्राज्य चाहता है - साम्राज्य स्थिर हैं और पैसा बनाते हैं - और हां, साम्राज्य गिर सकते हैं, लेकिन वे कार्ड के घर से गिरने की संभावना कम हैं।
एरोन

2
रोटेशन पूरी तरह से कंपनी छोड़ने वाले लोगों की तुलना में बेहतर है
वॉरेन

4
@warren: यदि वे दो विकल्प आपके ही हैं, तो उत्तरार्द्ध लगभग अपरिहार्य है।
आरोही

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

18

मैं अपने आप को यहां ज्यादा नीचे नहीं देखता। रोटेशन आपको मिलता है:

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

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


18
मैं यह नहीं देखता कि विरासत प्रणाली पर काम करने के लिए मुझे "मनोबल" मिला तो मेरा मनोबल कैसे सुधरेगा।
तैलस्टिन

3
नुकसान की एक जोड़ी प्रारंभिक विकास के समय में हो रही है और विरासत टीम के विशिष्ट अन्य कार्यों को कम प्राथमिकता मिल रही है।
ऊदबिलाव

16
@Telastyn अगर मेरी पुरानी कंपनी विरासत काम से बाहर निकल गई थी तो मैं अभी भी वहां काम करूंगा। यकीन है कि यह घुमाया जा करने के लिए बेकार है, लेकिन यह जानने के लिए और भी अधिक बेकार है कि आपको कभी भी बाहर नहीं घुमाया जाएगा क्योंकि उन्हें विरासत देव की जरूरत है।
दाढ़ी वाले

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

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

6

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

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

संभावित लाभों के एक जोड़े का उल्लेख नहीं किया गया है:

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

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

2
@Blake हां, दुर्भाग्य से यही मामला है। दुर्भाग्यपूर्ण है, क्योंकि यह एक कंपनी के लिए बहुत ही कम देखे जाने वाले और बहुत अधिक जोखिम वाले लोगों के लिए महत्वपूर्ण प्रणालियों के ज्ञान को "सीमित" करने का कम जोखिम है।
मार्जन वेनेमा

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

@ मार्जन: मैं शर्त लगाने के लिए तैयार रहूंगा कि नियमित रूप से क्रॉस-ट्रेनिंग करने से होने वाली लागत कहीं दूर होगी, नए भाड़े के प्रशिक्षण की लागत की तुलना में कहीं अधिक होगी जितनी कि कोई छोड़ता है। अब, अगर एक पूरी टीम निकलती है, तो यह एक अलग मामला है।
डंक

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

4

रोटेशन कंपनी के लिए अच्छी बात है, और डेवलपर्स के लिए भी अच्छी बात हो सकती है।

बहुत सारे अच्छे कारण हैं और व्याट ने अपने उत्तर में उनमें से कई का उल्लेख किया है।

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

यह सोचकर अच्छा हो सकता है कि शुरू करने के लिए 1 या 2 देवों को शुरू करने और घुमाने के लिए टीमों को थोक स्वैप न करने के बारे में कहा जाए, हालांकि यह ऐसा लग सकता है जैसे लोगों को डिमोशन (जो कुछ लोग इसे देख सकते हैं)।


मुझे शुरू करने के लिए सिर्फ 1-2 देवों की अदला-बदली का विचार पसंद है। यह उत्पादकता पर प्रारंभिक नकारात्मक प्रभाव को कम करने में मदद करेगा।
सुपरमैन

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

2

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


यह पोस्ट पढ़ना मुश्किल है (पाठ की दीवार)। क्या आप इसे बेहतर आकार में संपादित करना चाहेंगे ?
gnat

2

मैं आरोनियोथ के शीर्ष उत्तर से सहमत हूं और मेरे कुछ जोड़ हैं।

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

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

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

बस ज्ञान को फैलाने के लिए आसपास के लोगों के फेरबदल से कारोबार बढ़ने की संभावना है। इस तरह से ज्ञान का प्रसार होगा, लेकिन यह कंपनी के बाहर फैल जाएगा जो शायद इरादा नहीं है।


0

TL; DR इसे एक टीम बनाओ और फिर यह एक टीम है जो 2 परियोजनाओं का समर्थन करती है।

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

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

फिर एक परियोजना पर अधिक लोगों को प्राप्त करने का लाभ काफी अच्छी तरह से जाना जाता है, जैसा कि लागतें हैं।


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

0

प्रोग्रामर्स का रोटेशन कंपनी के दृष्टिकोण और डेवलपर के दृष्टिकोण से अच्छी बात है।

कंपनी के दृष्टिकोण से

  1. प्रबंधन को पता चल जाएगा, विशेष रूप से डेवलपर की ताकत और कमजोरी कि वे मल्टीटास्किंग को संभाल सकते हैं या नहीं और परिवर्तनों के लिए अनुकूल नहीं हैं।
  2. यदि कुछ डेवलपर किसी कारण से कंपनी छोड़ देते हैं, तो कंपनी के पास भविष्य के लिए पहले से ही बैकअप तैयार है।
  3. यह परियोजना के प्रदर्शन को बढ़ाएगा, जैसा कि कई लोग इस पर काम करेंगे, एक ही चीज को अधिक से अधिक डेवलपर्स द्वारा परीक्षण किया जाता है। (परीक्षण संसाधन अपव्यय कम से कम)
  4. टीम के सभी सदस्य टीम में काम करते हैं और यह परियोजना के प्रदर्शन को बढ़ावा देगा और भविष्य में प्रबंधन को यह पता चल जाएगा कि कठिन मॉड्यूल या कार्य को लागू करते समय किस तरह की टीम बनाने की आवश्यकता है।

एक डेवलपर दृष्टिकोण से

  1. यह डेवलपर को और अधिक सकारात्मक बना देगा क्योंकि उसका आत्मविश्वास बढ़ता है।
  2. डेवलपर्स को अन्य टीम साथियों के कोड से बेहतर और बेहतर विचार मिलते हैं और वे भविष्य के विकास में उन तकनीकों का उपयोग कर सकते हैं।
  3. अन्य टीम के सदस्यों के बेहतर विचारों और सुझावों से डेवलपर की उत्पादकता बढ़ती है।

केवल एक मुख्य बात, यह ध्यान रखने की जरूरत है कि,

प्रोग्रामर्स का रोटेशन बहुत बार नहीं होना चाहिए। ६०% - 60०% विकास के बाद ही शिफ्टिंग करना फायदेमंद होगा।


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

1
इन प्रस्तावित लाभों में से अधिकांश वास्तव में एक टीम से संबंधित होने के रूप में प्रतीत होते हैं, जैसे कि टीमों के बीच घुमाए जाने का विरोध ...
हारून

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

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