कैरियर विकल्प के रूप में आप कैसे "बेच" समर्थन करते हैं [बंद]

Question

हमें विभिन्न परियोजनाओं पर काम करने के लिए डेवलपर्स को नियुक्त करना अपेक्षाकृत आसान लगता है।

समस्या तब उत्पन्न होती है जब परियोजना समाप्त हो जाती है लेकिन फिर भी उसे समर्थन देने की आवश्यकता होती है।

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

वर्तमान में, हम प्रोजेक्ट टीम को अपनी टीम में से कुछ को सपोर्ट टीम को कुछ समय के लिए असाइन करके इसे राउंड करवाते हैं। असाइनमेंट का एक हिस्सा प्रोजेक्ट का "ब्रेन डंप" करना है ताकि सपोर्ट टीम इसे समझ सके। यह तब तक काम करता है जब तक असाइनमेंट केवल निश्चित अवधि के लिए हो।

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

(हालांकि वित्तीय वास्तविकता यह है कि समर्थन एक कंपनी के लिए बहुत ही आकर्षक हो सकता है और एक बार जब आप एक प्रतिष्ठा प्राप्त कर लेते हैं, तो आप अन्य कंपनियों द्वारा उनके समर्थन को करने के लिए संपर्क करते हैं, भले ही आप मूल विकास में शामिल नहीं थे।)

Comments

"यह मृत-अंत, कैरियर-सीमित, उबाऊ के रूप में देखा जाता है ..." - क्योंकि यह आमतौर पर है। डेवलपर्स अक्सर निर्माता हैं, और समर्थन, परिभाषा से, कुछ भी नहीं बनाता है।

— स्टीवन एवर्स

क्या आप समर्थन को परिभाषित कर सकते हैं जैसा कि आप इसका मतलब है? क्या यह बग फिक्सिंग या सब कुछ शामिल है, लेकिन उस बिंदु को शामिल नहीं करता है?

— जॉन हॉपकिंस

इसमें बग फिक्सिंग शामिल होगी।

— nzpcmad

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

— जॉब

Answer 1

नहीं

मेरे लिए सबसे अच्छा विकल्प यहां डेवलपर्स को पहले स्थान पर समर्थन और गैर-समर्थन में अलग करना नहीं है। IMHO के तीन मुख्य कारण हैं:

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

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

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

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

Comments

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

— nzpcmad

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

— बिल

Answer 2

अपने डेवलपर्स के लिए समर्थन नौकरी को मज़ेदार और मूल्यवान बनाएं।

मुझे निम्नलिखित कारणों से समर्थन करना पसंद है:

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

यह सिर्फ कुछ कारण हैं।

समर्थन के बारे में, मैं प्रक्रिया को प्रबंधित करने के लिए एक आसान लागू करने का सुझाव देता हूं।

जब हमें समर्थन मामला मिलता है, तो हम निम्नलिखित करते हैं:

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

Comments

ग्राहक वास्तव में क्या चाहता है , यह पता लगाने के सर्वोत्तम तरीके के रूप में समर्थन के लिए +1 ।

— एएसली

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

— निक जोसव्स्की

@ निक जोव्स्की - निश्चित रूप से, मौजूदा प्रणाली में सुधार / परिशोधन विकसित करने की स्वतंत्रता देने का अर्थ है कि 'समर्थन विकास' केवल 'काम नहीं करता है जब यह टूट जाता है'। मेरी पहली विकास भूमिका समर्थन / रखरखाव थी (हालांकि जब मैंने पहली बार वास्तविक परियोजना कार्य में कदम रखा तो मुझे इसका आनंद नहीं मिला)।

— एडम ल्यूजेनब्रॉवर्स

@ पियरे 303, मुझे संदेह है कि हर कोई आपके जैसा नहीं है। मैं शर्त लगाता हूं कि अंतर्मुखता बनाम बहिर्मुखता समीकरण का एक हिस्सा है।

— जॉब

मैं यहाँ अधिक जानकारी देता हूँ: pierre.mengal.eu/2011/09/27/in-praise-of-technical-support

Answer 3

क्यों नहीं बस और भूल भक्तों की तुलना में समर्थन देवों को 5 या 10k अधिक भुगतान करें?

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

Comments

मुझे नहीं लगता कि इससे अवधारण में सुधार होगा। ज़रूर, आप अधिक लोगों को साइन इन कर लेंगे, लेकिन एक बार जब वे कुछ नकद ले लेंगे, तो वे छोड़ देंगे। कुछ अध्ययनों से पता चला है कि पैसे ही है वास्तव में मायने रखती है कि आप इसे नहीं है जब। 'ज्ञान कार्यकर्ताओं ’के लिए संदेह है।

— स्टीवन एवर्स

Answer 4

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

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

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

Answer 5

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

Answer 6

कुछ विचार:

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

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

2 बी) यदि समर्थन में बग फिक्सिंग शामिल नहीं है, तो वे बहुत अलग काम करते हैं और विभिन्न कौशल पर जोर देते हैं। आपको यहां पर क्रॉस के बारे में चिंता नहीं करनी चाहिए, जितना आप विकास और सफाई के बीच क्रॉस ओवर की चिंता करते हैं।

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

आपकी पोस्ट पढ़ने से समस्या यह है कि आप विश्वास नहीं करते कि यह एक अच्छा काम है। अगर यह सच है तो कोई आश्चर्य नहीं कि आप इसे एक के रूप में नहीं बेच सकते।

Answer 7

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

1. अच्छे लोगों को रखने के लिए उद्योग की दरों के ऊपर भी अच्छा पैसा दें
2. अच्छा काम करने का माहौल प्रदान करें, काम की दोपहर के भोजन और पेय की मदद जैसी छोटी चीजें
3. एक छोटे से शोर कमरे में अपने सभी सहायक कर्मचारियों को रटना मत करो

Answer 8

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

Answer 9

मैंने कॉलेज से बाहर अपनी पहली कंपनी के लिए कुछ वर्षों तक समर्थन किया। मुझे कुछ वर्षों के लिए साइन अप करने के लिए क्या मिला था:

1. सॉफ्टवेयर इंजीनियर बनने के लिए आवश्यक कैरियर मार्ग।
2. मुझे कंपनी की मुख्य भाषा (फोरट्रान, लगभग 1989) पर ब्रश करने के लिए समय चाहिए था
3. मैंने शादी नहीं की थी तो मैं छोड़ सकता था अगर मैंने पाया कि मुझे कंपनी या नौकरी पसंद नहीं है।

Answer 10

विकास और समर्थन के कुछ मिश्रण के बारे में कैसे (विभाजन भूमिकाएं)? मुझे लगता है कि आप अभी भी खरीद पाने के लिए संघर्ष करेंगे क्योंकि पहले से बताए गए कारणों के कारण (डेवलपर्स! = उत्पाद समर्थन लोग)। लेकिन अगर आपका उत्पाद आंतरिक प्रौद्योगिकी की व्यापक समझ पर निर्भर करता है, तो शायद 80% विकास, 20% समर्थन एक निष्पक्ष व्यापार होगा। या नए कर्मचारियों के लिए किसी प्रकार की सलाह / छायांकन यह सुनिश्चित करने के लिए कि उन्हें उत्पाद के बारे में सही जानकारी मिले।