क्या सॉफ्टवेयर इंजीनियरों को भी तकनीकी सहायता के रूप में कार्य करना चाहिए? [बन्द है]

Question

क्या एक सॉफ्टवेयर इंजीनियर को तकनीकी सहायता के रूप में भी कार्य करना चाहिए? यही है, एक कंपनी को अपने इंजीनियरों को सॉफ्टवेयर इंजीनियर और तकनीकी सहायता टोपी दोनों पहनने की अनुमति देनी चाहिए। ऐसा लगता है कि यह सॉफ्टवेयर को लिखने की क्षमता को हटा देगा यदि किसी इंजीनियर के समय को तकनीकी सहायता द्वारा लिया गया हो।

Comments

संबं धत

— ल ं क

तकनीकी सहायता से, क्या आपका मतलब उन विशिष्ट ऐप्स का समर्थन करना है जो वे विकसित कर रहे हैं, या सामान्य "सिस्टम एडमिन" सामान की तरह? मैं आपको बता सकता हूं कि थोड़ी सी फर्म में काम करना और एक्सेल को स्थापित करने के लिए लोग आपको बग कर रहे हैं।

— कार्लोस

क्या हमें? नहीं हम? हाँ। मुझे इससे घृणा है।

— राचेल

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

— एरिक रिपेन

Answer 1

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

डिवेलपर्स सपोर्ट में शामिल होने वाले डेवलपर्स

पेशेवरों

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

विपक्ष

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

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

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

Comments

मुझे लगता है कि विकास में एक परियोजना के लिए समर्थन करना बुरा नहीं है। क्लाइंट के साथ बात करना अच्छा है। लेकिन अगर आप 7 अलग-अलग समय सीमा और तात्कालिकता के साथ 7 परियोजनाओं पर काम करते हैं ... थोड़ी देर बाद यह वास्तव में अच्छा नहीं है। यह बहुत बुरी तरह से चूसना।

— Lo --c Faure-Lacroix

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

— केट ग्रेगोरी

आरटीएफएम प्रश्नों को पकड़ने के लिए एक फ्रंट-लाइन सपोर्ट लेयर होनी चाहिए, जिससे डेवलपर्स के लिए उपयोगी तकनीकी सामग्री / फीडबैक के साथ केवल प्रश्न ही रह जाएँ।

— रॉबर्ट हार्वे

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

— रॉबर्ट हार्वे

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

— जॉन स्टोरी

Answer 2

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

Answer 3

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

मैं एक समस्या को हल करने पर ध्यान केंद्रित नहीं कर सकता क्योंकि हर 5 मिनट में मुझे फोन उठाना पड़ता है। न तो नौकरी मिलती है और साथ ही यह भी हो सकता है क्योंकि मैं लगातार सोच रहा हूं कि मैं एक समस्या को हल करने के लिए क्या कर सकता हूं, और मैं कभी भी प्रोग्रामिंग पर काम नहीं कर रहा हूं जो किसी भी समाधान को पूरी तरह से लागू करने के लिए हो सकता है।

फिर से, मैं इस बात पर जोर नहीं दे सकता था कि एक पहलू या दूसरे पर ध्यान केंद्रित करने में सक्षम होना कितना महत्वपूर्ण है।

Comments

+1 मैं आपकी कही हर बात से संबंधित हो सकता हूं। मैं कुछ हफ्ते पहले इसी तरह की स्थिति में था। अब हमारे पास फोन नहीं है, लेकिन वे दरवाजे को वैसे भी खटखटाते हैं, जैसे सामान के लिए: "अरे दोस्तों, क्या आपने एक्स को चारों ओर देखा है?" geez!

— जसोन्को

व्यवधानों से बचने के लिए आप 'कार्यालय समय' को निर्धारित कर सकते हैं। कॉल समर्थन पर एक अच्छा विचार नहीं है।

— जेएफओ

सहमत, भी, अर्द्ध-

— दुस्साहसी

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

— जय

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

— आईब्रेट जूल

Answer 4

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

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

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

Comments

जैपोस ने एक साम्राज्य बनाया है जो पहले व्यक्ति शासन के खिलाफ जाता है।

— जेएफओ

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

— बेरिन लोरिट्श

कभी नहीँ? जैसा कि कभी नहीं, कभी में? भले ही आप salespeople और एक या दो डेवलपर्स से बना एक छोटी सी कंपनी थे? भले ही आपके डेवलपर्स बहुत मजबूत संचारक थे और ग्राहकों के साथ बात करना पसंद नहीं करते थे?

— ब्रायन ओकले

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

— बेरिन लोरिट्श

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

— डबलडबल डबल

Answer 5

यह कंपनी पर निर्भर करता है।

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

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

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

Comments

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

— Htbaa

Answer 6

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

Comments

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

— बेरिन लोरिट्श

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

— मिलिंद आर

Answer 7

डेवलपर्स को समर्थन की अंतिम पंक्ति होनी चाहिए।

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

अगर यह एक बहुत बड़ी समस्या है तो हम इसे सुनेंगे।

Answer 8

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

Answer 9

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

Answer 10

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

यह छोटे आवधिक चरणों के लिए होना चाहिए, ताकि विकास के वास्तविक कार्य को बाधित न करें।

Answer 11

ऐसी प्रतिभाएं और कौशल हैं जिनके लिए आपको सॉफ्टवेयर विकसित करने की आवश्यकता है, और प्रतिभाएं और कौशल आपको पहली पंक्ति के समर्थन पर प्रभावी होने की आवश्यकता है। मुझे नहीं पता कि इन प्रतिभाओं का कोई संबंध है।

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

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

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

Answer 12

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

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

Answer 13

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

आपके द्वारा अपने कोड का समर्थन और रखरखाव करने की क्षमता पर कुछ डिज़ाइन निर्णयों और / या शॉर्टकटों का क्या प्रभाव पड़ता है, यह महसूस करने के लिए कई 3AM कॉल की तरह कुछ भी नहीं है।

Comments

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

— डेविड थॉर्नले

Answer 14

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

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

Answer 15

मैं इस जाल में तब फंसा जब मैंने अच्छी तनख्वाह वाली कंपनी ज्वाइन की। साक्षात्कार के दौरान मुझे बताया गया है कि 70% विकास और 30% समर्थन होगा और मैंने प्रस्ताव स्वीकार कर लिया। हो सकता है कि यह कंपनी या पर्यावरण है जिस पर मैं वर्तमान में काम कर रहा हूं। लेकिन वास्तव में यह 90% समर्थन और 10% विकास है। इसके कुछ साल हो गए हैं अब मैंने विकास की पकड़ खो दी है। मुझे खेद है कि मैंने इस प्रस्ताव को स्वीकार कर लिया।

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

दुर्भाग्य से मैं गतिरोध में हूं।

यदि आप पसंद नहीं करते हैं या आप में रुचि नहीं है तो कृपया भूमिकाएँ स्वीकार न करें।

Answer 16

विपक्ष - यह मानते हुए कि आपको ग्राहकों से सीधे निपटना है।

1) अपने ग्राहकों को परेशान करना

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

2) अपने डेवलपर्स को लेट और मेक अप स्टोरीज़ के लिए कंडीशनिंग करना।

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

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

3) अपने पाठ्यक्रम Vitae पीड़ित।

जब तक आप सॉफ्टवेयर इंजीनियर से बिजनेस एनालिस्ट / आईटी कंसल्टेंट / प्रोजेक्ट मैनेजमेंट का स्विच नहीं बनाते, आपका सीवी तकनीकी पहलू से प्रभावित होने वाला है।

पेड सपोर्ट का काम जो टीम के बीच घूमता है वह एक अलग कहानी है।

पेशेवरों

1) व्हिनर्स को व्हिनिंग से रोकें

डेवलपर्स जो वे नफरत करते हैं, वे उन्हें बहुत अधिक कोडिंग की सराहना करेंगे। एक प्रोग्रामर है जो लगातार फुसफुसा रहा है? उन्हें एक महीने के लिए हॉटलाइन पर रखें।

Comments

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

— डेविड थॉर्नले

डेविड से सहमत हैं, अगर आपको अपनी टीम को एक कक्षा की तरह चलाना है, तो आप अपनी भर्ती प्रथाओं, और / या अपने काम के माहौल पर पुनर्विचार करना चाह सकते हैं।

— मैथ्यू

Answer 17

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