सॉफ्टवेयर डेवलपर और व्यवसाय ग्राहक के बीच उचित संबंध क्या है?


10

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

यहाँ एक सादृश्य के बारे में सोचना है। एक मरीज जोर देकर कहता है कि उसके पैर को विच्छिन्न करने की आवश्यकता है। उनका डॉक्टर असहमत है लेकिन मरीज को राजी नहीं किया जा सकता है। क्या रोगी को संतुष्ट करने के लिए डॉक्टर को केवल पैर को काटना चाहिए?

एक और सादृश्य। एक ग्राहक एक सिविल इंजीनियर को असुरक्षित डिजाइन के लिए एक पुल का निर्माण करना चाहता है। यहां तक ​​कि जब इंजीनियर समझाता है कि यह असुरक्षित है तो ग्राहक उस पर विश्वास नहीं करता है। क्या इंजीनियर को वैसे भी पुल का निर्माण करना चाहिए?

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


2
एक सम्मेलन में मैंने एक बार एक वक्ता को यह कहते सुना, "आप जो भी करते हैं, ग्राहक को आपके लीडर प्रोग्रामर तक सीधी पहुँच नहीं देते। यदि आप ऐसा करते हैं तो वे सचमुच उसका बलात्कार करेंगे।" मुझे लगता है कि यह एक सॉफ्टवेयर डेवलपर और ग्राहक के बीच गलत संबंध और सचमुच मैंने कभी सुना है, दोनों का सबसे खराब उपयोग होगा।
जॉन हॉपकिंस

और यहां मेरे काम पर यह एक संस्थापक सिद्धांत है कि ग्राहक हमेशा लीड प्रोग्रामर तक सीधी पहुंच रखता है!
फ्रैंक शीयर

"शाब्दिक" के छोटे मूल्यों के लिए, संभवतः?
मावग का कहना है कि मोनिका

जवाबों:


9

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

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


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

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

1
तो आप सभी कहाँ काम करते हैं कि "व्यापार ग्राहक" वास्तव में समस्या डोमेन में एक उम्मीद है? बहुत बार मैंने पाया है कि ऐसा नहीं है ...
कैफ़ीक

चाड: मेरे अनुभव में, कुछ सॉफ्टवेयर कंपनियां शीर्ष स्तर के प्रबंधन को बेचने पर ध्यान केंद्रित करती हैं, जो तब कागज पर जो भी अच्छा लगता है उसे लागू करने के लिए मध्य स्तर के प्रबंधन को मजबूर करता है। ऐसी कंपनियों में, आप शायद ही कभी "व्यावसायिक ग्राहक" पाते हैं, जो समस्या क्षेत्र के विशेषज्ञ भी हैं, क्योंकि एक प्रवृत्ति है कि एक ही प्रबंधक जिसने सौदे पर हस्ताक्षर किए हैं, वह संपर्क व्यक्ति रहता है, चाहे वह समझ में आता हो या नहीं। अन्य कंपनियां संबंधित विभाग को बेचती हैं, इसलिए प्राथमिक संपर्क व्यक्ति आमतौर पर अपनी नौकरी जानता है।
14:28 पर user281377

1

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

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

एक कर्मचारी के रूप में, सेवा करने से इनकार करने वाले एक सलाहकार के समतुल्य नेपोलियन बोनापार्ट के एक उद्धरण द्वारा कवर किया गया है:

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

आपको अपनी लड़ाई चुननी होगी। क्या आपको इतना जघन्य और अनैतिक काम करने के लिए कहा गया है जिसे आप छोड़ेंगे? यदि नहीं, तो या तो हितधारकों को समस्या समझाएं और कुछ उचित बातचीत करें, या बस करें।

और उन चीजों को न करें जिन्हें आपने खरीद-बंद नहीं किया है। जो लोग ऐसा करते हैं उन्हें "ढीले तोपों" कहा जाता है।

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


2
कई डेवलपर सलाहकार हैं! मैं एक हूँ।
अमीर रज़ाई

1
मैं एक सलाहकार हूँ!
nvogel

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

4
मैं 1991 से 2006 तक पूर्णकालिक सलाहकार था, और जुलाई में पूर्णकालिक रूप से लौट आया। मुझे लगता है कि एक ग्राहक मुझे कुछ गूंगा करने के लिए भुगतान करना चाहता है लेकिन अनैतिक या खतरनाक नहीं है, और मेरी आपत्तियों पर जोर देता है ... हे, यह बर्बाद करने के लिए उनका पैसा है। और मैंने आमतौर पर पाया कि मेरे ग्राहक मेरे व्यवसाय के बारे में अधिक जानते हैं, इसलिए वे चाहते हैं कि मुझे समझ में आने के बाद वे पहली बार में पागल हो जाएं। मुझे लगता है कि मुझे एक कर्मचारी के रूप में घंटे से भुगतान किए गए सलाहकार के रूप में गूंगा चीजें करने के लिए कहा जाता है, जिसका ओवरटाइम नियोक्ता के लिए "मुक्त" है।
बॉब मर्फी

1

डॉक्टर 'कोई नुकसान नहीं' करने की शपथ लेते हैं और पहले रोगी के सर्वोत्तम हित के लिए कानूनी रूप से आवश्यक होते हैं । एक डॉक्टर जो एक अनावश्यक और हानिकारक ऑपरेशन करता था (भले ही रोगी ने इसकी मांग की थी) खुद को एक कदाचार सूट तक खोल रहा होगा और अपना लाइसेंस खो सकता है।

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

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

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


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

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

0

जब आईटी पेशेवर निर्णय लेने के लिए योग्य है, लेकिन उसके ग्राहक नहीं हैं, तो क्या आईटी पेशेवरों के लिए भी यह लागू नहीं होना चाहिए?

मेरी राय में हाँ!

यदि आप अपने ग्राहक के साथ एक लंबा रिश्ता रखने जा रहे हैं।


0

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


0

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

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

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

प्रोग्रामर को लाइसेंस देने के प्रस्ताव आए हैं, लेकिन किसी को भी मेरी जानकारी नहीं है कि वे कभी कहीं गए हैं। संभवतः परियोजनाओं पर काम करने के लिए लाइसेंस प्राप्त प्रोग्रामर रखने के लिए कानूनी रूप से आवश्यक होना आवश्यक होगा, और यह जल्द ही किसी भी समय नहीं हो रहा है। चिकित्सा या इंजीनियरिंग कोड के लिए नैतिकता के कोड वाले पेशेवर संगठन हैं, लेकिन किसी भी कानूनी बल के बिना वे नैतिकता के व्यक्तिगत कोड के लिए गाइड की तरह हैं।


0

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.