अंत-उपयोगकर्ताओं के साथ इस दुर्भाग्यपूर्ण गैर-काल्पनिक स्थिति को कैसे संभालना है?


22

मैं एक मध्यम आकार की कंपनी में काम करता हूं लेकिन बहुत कम आईटी बल के साथ।

पिछले साल (2011), मैंने एक एप्लिकेशन लिखा था जो अंत-उपयोगकर्ताओं के एक बड़े समूह के साथ बहुत लोकप्रिय है। हमने पिछले साल के अंत में एक समय सीमा तय की और कुछ कार्यक्षमता (मैं अब से funcA को कॉल करूंगा) को उस एप्लिकेशन में नहीं जोड़ा गया जो बहुत अंत में चाहता था। इसलिए, यह एप्लिकेशन 2011 के अंत से लाइव / प्रोडक्शन में चल रहा है, मैं बिना किसी मुद्दे के जोड़ सकता हूं।

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

मैंने कोड और प्रश्नों की तुलना की है और 2011 के बाद से कोई अंतर नहीं है, जो प्रूफ है। मैं तब एंड-यूज़र्स में से एक को स्वीकार करने में सक्षम था कि इसने कभी भी प्रूफ नहीं दिया, लेकिन उसके बाद से उस एंड-यूज़र ने वापस चला गया और कहा कि यह पहले काम कर रहा था ... मेरा मानना ​​है कि एंड-यूज़र्स की भीड़ को आत्मसात कर लिया है उसके। मैंने इस परियोजना के लिए अपने नोट्स की भी समीक्षा की है, जिसमें उस परियोजना के बारे में आवश्यकताओं और दैनिक अपडेट हैं, जो विशेष रूप से बताता है, "समय की कमी के कारण funcA हासिल नहीं किया गया", सबूतसी।

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

सबसे बुरी बात यह है कि अब समूह को लगता है कि मेरे बॉस और आईटी के प्रमुख वास्तव में उन पर विश्वास करने लगे हैं, भले ही कोई कोड या क्वेरी परिवर्तन न हो। जहां तक ​​तर्क की स्थिति की समीक्षा करने के लिए यह बहुत ही कट और शुष्क है अगर 1 = 1 के बिंदु पर, कवक काम नहीं करेगा।

तो, यह मेरे परिदृश्य के विवरण का अंत है, लेकिन मैं अपने प्रदर्शन के मैट्रिक्स पर इस कारण गंभीर रूप से विचलित नहीं होने की कोशिश कर रहा हूं, जो अनिवार्य रूप से मुझे एक उत्पादन समस्या को हल करने के लिए स्थानांतरित कर दिया गया है जो मौजूद नहीं है जो संभवतः खत्म हो जाएगा 1 महीना।


1
हम शब्द के पारंपरिक अर्थों में एक मंच नहीं हैं, हम एक प्रश्नोत्तर साइट हैं जो उत्तर देने योग्य प्रश्नों की तलाश में हैं। बारिश, मतदान और चर्चा आम तौर पर हमारे प्रारूप में फिट नहीं होती है।
maple_shaft

12
@maple_shaft: मैं असहमत हूं। यह एक गंभीर सवाल है जो वास्तविक समस्या से निपटने के लिए एक रास्ता खोज रहा है जो कि व्यवहार करते समय होता है, हम कहेंगे, कम-से-कम सुराग वाले अंतिम उपयोगकर्ता। हम सभी ने इसे देखा है और इससे निराश हुए हैं, क्या हम नहीं? तो इस तरह के परिदृश्य से निपटने के बारे में विचार इस साइट के प्रारूप के लिए बहुत अच्छे हैं।
मेसन व्हीलर

1
क्या यह संभव नहीं है कि इस प्रश्न का उत्तर हो सकता है? देखने वाले कौन देखेगा?
उपयोगकर्ता स्मिथ

2
इसे पढ़ने वाले अन्य लोगों को लाभान्वित करने के लिए, यह मामला हम में से एक अन्य पाठ का प्रतिनिधित्व करता है, जो मानते हैं कि प्रलेखन द्वितीयक है और यह कि गायन की आवश्यकताएँ महत्वपूर्ण नहीं हैं।
NoChance सेप

1
"कुछ भी नहीं बदला है" प्रसिद्ध अंतिम शब्द।
जेफ़ो

जवाबों:


18

आसानी से-अवलोकन योग्य तथ्यों के बारे में विवाद वास्तव में हल करना काफी आसान है: बस तथ्यों का निरीक्षण करें। अगर मैं कहता हूं "मेरे घर के बाहर बैंगनी लकड़ी वाला एक पेड़ है," तो मेरे घर पर आने वाला कोई भी व्यक्ति मेरे लिए अपने बयान की सच्चाई या झूठ को सत्यापित कर सकता है।

यदि वे शिकायत कर रहे हैं कि FuncA उत्पाद में हुआ करता था और पहले के संस्करण में काम करता था और अब यह काम नहीं कर रहा है, और आपको नहीं लगता कि यह उत्पाद में कभी था, तो इसे साबित करने के लिए कहें। (या, अधिक कोमल शब्दों में कहें, "हमें समस्या को हल करने में परेशानी हो रही है। क्या आप हमें यहाँ मदद कर सकते हैं?"

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


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

3
@UserSmith: यही कारण है कि मैंने LiveMeeting का उपयोग करने के लिए कहा। जब आप वास्तव में इसे देख रहे लोगों के साथ करते हैं, तो गलती करना मुश्किल है।
मेसन व्हीलर

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

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

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

13

यह एक ऐसा मुद्दा नहीं है जिसे तथ्यों पर निपटाया जा सकता है - यदि आप कोशिश करते हैं, तो आप विश्वसनीयता ढीली कर देंगे।

सबसे पहले, स्वीकार करें कि सॉफ़्टवेयर "टूटा हुआ" है - क्योंकि यह ऐसा नहीं करता है जो उपयोगकर्ता इसे करना चाहते हैं। अब, स्वीकार करें कि उपयोगकर्ताओं के पास सॉफ़्टवेयर का अधिकार है कि वे ऐसा करना चाहते हैं - इसलिए सॉफ़्टवेयर ऐसा है। तो जो हमारे पास दोषपूर्ण सॉफ्टवेयर है और एक इंजीनियर इसे ठीक करने से इनकार कर रहा है .....

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

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

जब तक आप सिस्टम को ठीक कर सकते हैं या कार्यालय की राजनीति को वास्तविक रूप से खेलना सीख सकते हैं, खेल खत्म: आप हार जाते हैं।

नोट: इस चर्चा में किसी में भी डेड लाइन, बग बनाम फीचर चर्चा शामिल नहीं है, कौन भुगतान कर रहा है आदि। ये तथ्य हैं - और तथ्यों से कोई फर्क नहीं पड़ता (ठीक है, वे ऐसा करते हैं, लेकिन उन्हें इतने तरीकों से जोड़-तोड़ किया जा सकता है ...) ) कार्यालय की राजनीति में।


1
यदि आप इसे साबित कर सकते हैं तो आप विश्वसनीयता कैसे खो सकते हैं ?
थॉमस एडिंग सेप

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

2
मैं इसके एक अच्छे हिस्से से सहमत हूं, यह निश्चित रूप से कार्यालय की राजनीति का एक रूप है। जब मैं किसी भी स्थिति से मिलता हूं तो मुझे लगता है कि तथ्यों से निपटने के लिए कार्रवाई का पहला कोर्स होगा, इसलिए आप मुझे वहां खो देंगे, लेकिन मैं ग्राहकों के साथ सहमत होना चाहूंगा कि जब तक आप निश्चित रूप से निकाल नहीं दिए जाते हैं, तब तक आप पहले स्थान पर दूसरे स्थान पर आते हैं। स्थिति पर एक अलग लेने के लिए +1। +1
उपयोगकर्ता स्मिथ 12

2
कभी शिकायत मत करो और कभी समझाओ भी नही। तर्क करने से आप कमजोर दिखते हैं। विनम्र अनुरोधों को सुनना अच्छा है। यह कहना कि आप प्राथमिकता के लिए अपने बॉस के साथ उनके अनुरोध पर चर्चा करेंगे, अच्छा है। यदि आप तर्क करते हैं, तो वे वही करें जिसके बारे में वे चिल्लाए थे, यह उनके अप्रिय व्यवहार को पुष्ट करता है। यदि वे आगे बढ़ते हैं, तो आपके बॉस की स्थिति शक्ति राजनीति को लागू करती है। आपका बॉस राजनयिक रूप से आपके समय के लिए उसकी पसंद की व्याख्या कर सकता है। यह भी दर्शाता है कि वे आप के बॉस नहीं हैं। जब आप अपने बॉस के साथ चुपचाप मुद्दे को संबोधित करते हैं, तो आपको "चिंता मत करो, मुझे तुम्हारी पीठ मिल गई" जैसे शब्द सुनने को मिलेंगे। केंद्रित रहें, उत्पाद बनाएं, रेंट बंद हो जाएगा।
DeveloperDon

@thomas किसी भी निर्दोष आरोपी से पूछें कि क्या कोई कण अनैतिक अपराध ....
मैटनज़

9

संगठनात्मक रूप से, मुझे एक समस्या है।

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

मेरे उत्तर के संदर्भ को निर्धारित करने के लिए कुछ बिंदु:

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

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


DevDon, काश यह उत्तर # 1 के साथ होता, जैसा कि मुझे लगता है कि यह हमारे मुद्दे का एक बड़ा हिस्सा है। .... इस परिदृश्य के लिए हमारी आईटी संरचना अत्यंत दुरूह है। +1
उपयोगकर्ता स्मिथ

1

इस तरह की वास्तविकता की विफलता के मामले में, सबसे अच्छी बात यह है कि आगे बढ़ना है। अतीत के बारे में बहस करने के बजाय, इसे काम करने के बारे में बात करें और यह कितना आसान या कठिन होगा। यह वास्तव में कोई बात नहीं है अगर समस्या इसे ठीक कर रही है या पहली बार लागू कर रही है। यदि प्रबंधन चाहता है कि ए बी से पहले किया गया है तो ऐसा करें।


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

0

क्या आप इस परियोजना पर काम करने वाले एकमात्र देव हैं? लगता है जैसे आपने प्रोजेक्ट बनाते समय किसी को उत्तर दिया। इस सब में वह व्यक्ति कहाँ है? परियोजना के लिए प्रलेखन क्या कह रहा है कि क्या वितरित किया गया था?

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

यह उनका शब्द उनके खिलाफ नहीं होना चाहिए, यह सभी दस्तावेज में होना चाहिए।

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

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


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

@UserSmith ~ मुझे लगता है कि एक दैनिक स्थिति अद्यतन के अधिक मतलब है। यह वास्तव में प्रलेखन मैं बात नहीं कर रहा था। क्या किसी ने अंतिम उत्पाद पर हस्ताक्षर किया था? क्या आपके पास अंतिम उपयोगकर्ता या स्टेक होल्डर का प्रशिक्षण या कोई एप्लिकेशन डॉक्यूमेंटेशन है?
तन्यना

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