क्या पैच ग्राहक के लिए बुरा संकेत हैं? [बन्द है]


14

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

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

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

इसलिए मेरा प्रश्न अधिक विस्तार से: क्या अपडेट प्राप्त करना अक्सर रिसीवर को एक 'नकारात्मक' संदेश देता है?

बेशक, मैं ग्राहकों से पूछ सकता था, लेकिन मैं उस स्थिति में नहीं हूं और न ही मैं 'सोए हुए कुत्तों को जगाना' चाहता हूं।

पुनश्च: अगर मेरे सवाल को सुधारने के लिए कुछ भी हो सकता है, तो कृपया एक टिप्पणी छोड़ दें।


@downvoter, समझाने की परवाह?
मिक्सक्सीफाइड

6
यदि आप ग्राहक धारणा के बारे में चिंतित हैं, तो शायद उन्हें "पैच" के बजाय "अपडेट" के रूप में वर्णित करें? :)
क्रिस टेलर

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

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

@ MichaelKjörling समस्या यह है कि उस दौर में मिशन क्रिटिकल फीचर्स फेल हो गए थे, इसलिए यह वास्तव में मायने नहीं रखता था कि प्रोडक्शन का माहौल या टेस्ट का माहौल पहले अपडेट हुआ था या नहीं। बस ASAP को काम करने की जरूरत थी।
मिक्सक्सिफ़ॉइड

जवाबों:


24

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

यहाँ छवि विवरण दर्ज करें

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


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

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

2
@DocBrown: ग्राफ अभी भी सही है। छोटे विकास चक्र का मतलब प्रति चक्र कम लागत है, जो ग्राफ के अनुरूप है। लेकिन इसका मतलब यह नहीं है कि आपको अपने ग्राहकों पर अपने सॉफ़्टवेयर का परीक्षण करना चाहिए, जब तक कि एक स्पष्ट समझ और समझौता न हो कि यह प्रक्रिया का हिस्सा है।
रॉबर्ट हार्वे

ठीक है, दोषों की लागत कम हो जाती है पहले बग पाया जाता है और तय किया जाता है। और मौका मिला एक बग नाटकीय रूप से बढ़ जाता है पहले आप अपने सॉफ़्टवेयर को दरवाजे से बाहर निकालते हैं। इसका मतलब यह नहीं है कि किसी को भी अनटाइटेड सॉफ्टवेयर को प्रोडक्शन में धकेलना चाहिए। मैं सलाह देता हूं, उदाहरण के लिए, यह लेख agileelements.wordpress.com/2008/04/22/cost-of-software-defects
Doc Brown

1
यह सब कुछ थोड़ा आत्म-प्रतिबिंब है यह देखने के लिए कि सिद्धांत स्वयं ध्वनि है, भले ही संख्या या वक्र का आकार केवल जंगली-गधा अनुमान हो। यहां तक ​​कि हमारे पास प्रोग्रामिंग पार्लेंस में इसका एक नाम है: फेल फास्ट।
रॉबर्ट हार्वे

10

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

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

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


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

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

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

जब रिलीज चक्र में भी निर्भर करता है। यदि रिलीज़ के बाद पहले दिनों में पैच एक साथ बंद हो जाते हैं, तो इससे एक अलग ही आभास होता है जब वे कई महीनों बाद भी एक साथ बंद होते हैं।
jwenting

7

अधिक से अधिक कंपनियां क्रोम के नक्शेकदम पर चलती हैं और अधिक से अधिक बार ग्राहक जारी करती हैं।

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

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

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

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


2
+1, सॉफ़्टवेयर के लगातार ग्राहक के रूप में, मैं चाहता हूं कि लगातार अपडेट वाले लोग और उन्हें तैनात करने के अच्छे तरीके। जो उत्पाद स्थिर होते हैं, वे यहां असली लाल झंडा होते हैं - बहुत कम से कम इसका मतलब है कि विक्रेता उत्पाद में निवेश नहीं कर रहा है। या vNEXT में निवेश करना चाहते हैं कि वे आपको फिर से भुगतान करना चाहते हैं।
वायट बार्नेट

आपके अंतिम पैराग्राफ से मुझे जो समझ में आता है वह यह है कि हमें ग्राहक के प्रति अपने संचार में हमेशा ईमानदार और पारदर्शी होना चाहिए। क्या ऐसी परिस्थितियाँ हैं जो हमें (अभी तक) ग्राहक को कुछ चीजों के बारे में सूचित नहीं करनी चाहिए?
मिक्सक्सीफॉइड

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

2

विशेष रूप से समस्या का पता लगाने वाले ग्राहकों के लिए पैच स्पष्ट रूप से जल्द से जल्द बाहर जाने की आवश्यकता है।

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

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

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

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

सास एप्लिकेशन पृष्ठभूमि में अद्यतन करके पूरे मुद्दे के आसपास हो जाते हैं।

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


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

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

फ़ेसबुक के लिए यह संदर्भ मिला: blogs.wsj.com/cio/2013/04/17/… , इसलिए प्रति दिन दो नहीं, दो रिलीज़ होने लगते हैं। फिर भी प्रभावशाली, मुझे लगता है।
डॉक्टर ब्राउन

मैंने हर 17 सेकंड में अमेजन पुश कोड 'सुना'। लेकिन मैं इसे एक टिप्पणी में डाल रहा हूं क्योंकि मुझे याद नहीं है कि मुझे किसने बताया और एक Google इसे नहीं दिखाता है। :-)
एनकरिट

@Encaitar: सही है, अमेज़ॅन की वास्तुकला में सैकड़ों सहभागिता सेवाएं हैं। इसलिए मुझे आश्चर्य नहीं है कि अगर वे किसी चीज को बहुत बार धक्का देते हैं, लेकिन मुझे बहुत संदेह है कि प्रत्येक धक्का सीधे एक से अधिक घटकों को प्रभावित करता है। क्या आप एक एकल वेबसाइट के रूप में देखते हैं जरूरी नहीं कि एक समग्र संस्करण हो। यह कहना अधिक पसंद है कि शहर का सड़क नेटवर्क हर 17 सेकंड में अपडेट किया जाता है क्योंकि आपके कर्मचारी एक दिन में कुल 5 हजार ताजी लाइनों में पेंट करते हैं :-)
स्टीव जेसप
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.