क्या आपको एक ऐसी सुविधा देने का वादा करना चाहिए जो आपके कार्यान्वयन योग्य होने पर सुनिश्चित न हो?

Question

HN के एक लेख में , मैं निम्नलिखित सलाह पर आया:

हमेशा अपने ग्राहक / उपयोगकर्ता को "हां" बताएं, भले ही आपको यकीन न हो। 90% समय, आपको इसे करने का एक तरीका मिलेगा। 10% समय, आप वापस जाएँगे और माफी माँगेंगे। बड़ी व्यक्तिगत वृद्धि के लिए भुगतान करने के लिए छोटी कीमत

लेकिन मैंने हमेशा सोचा है कि किसी ग्राहक / उपयोगकर्ता को किसी भी तरह के वादे करने से पहले व्यवहार्यता विश्लेषण करना चाहिए , ताकि वे किसी भी बिंदु पर गुमराह न हों। तब, किन परिस्थितियों में उपरोक्त सलाह लागू होनी चाहिए?

Comments

प्रोग्रामिंग में, कुछ भी संभव है। बस याद रखें कि "हां" "कितना समय लगेगा" का जवाब नहीं है।

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

@SnOrfus: कुछ समस्याओं को आसानी से हल नहीं किया जा सकता है। यदि आपको लगता है कि अन्यथा मौसम की भविष्यवाणी करने वाली दिनचर्या का कार्यक्रम करें जो आपको बताएगा कि क्या हमारे पास एक सफेद क्रिसमस होगा।

— लोरेन Pechtel

@ एर्लज़: यह मानकर चल रहा है कि ब्रह्मांड निर्धारक है, जो जरूरी नहीं कि सच हो।

— whatsisname

क्षमा करें, असंभव। सात से दस दिनों के बाद मौसम अराजक हो जाता है। इस विषय पर एक बहुत प्रसिद्ध पत्र है, "भविष्यवाणी: ब्राजील में एक तितली के पंखों का फ्लैप टेक्सास में एक तूफान का सेट करता है? एडवर्ड लोरेंज द्वारा।

— डेविड हैमेन

यदि प्रोग्रामर वादे करने जा रहे हैं तो वे नहीं रख सकते, तो बिक्री करने वाले लोग क्या करने जा रहे हैं?

— जेफ ओक्ट

Answer 1

यह उस लेख द्वारा शुरू किए गए लघु उत्तराधिकार का दूसरा प्रश्न है।

• अच्छा प्रोग्रामर: मैं कोड का अनुकूलन करता हूं। बेहतर प्रोग्रामर: मैं डेटा संरचना करता हूं। बेस्ट प्रोग्रामर: क्या अंतर है?
  इसके लिए एक और नाम है: समयपूर्व अनुकूलन।

• कभी भी शुरुआती निकास का उपयोग न करें।
  वह "प्रविष्टि का एकल बिंदु / निकास का एकल बिंदु" नियम है। यह वास्तविक समस्या पर एक पैच है, जो कि जल्दी से बाहर निकलने से एक गड़बड़ हो सकती है। सही नियम है "अपनी गंदगी साफ करो"। एक बेहतर नियम यह भी है कि डेटा कंस्ट्रक्टर्स का इस्तेमाल किया जाए जो अपने आप साफ हो जाएं ताकि प्रोग्रामर को अपनी गंदगी साफ करने के लिए परेशान न होना पड़े।

• और अब, हमेशा अपने ग्राहक / उपयोगकर्ता को "हां" बताएं, भले ही आपको यकीन न हो। 90% समय, आपको इसे करने का एक तरीका मिलेगा।
  यह भी अविश्वसनीय रूप से बुरी सलाह है।

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

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

इस तरह से सोचें: आपको क्या लगता है कि एयरलाइन उद्योग का क्या होगा अगर सभी हवाई जहाज लैंडिंग में से 90% सफल रहे? क्या आपको लगता है कि वापस जाने और दुर्घटनाग्रस्त होने वाले 10% के लिए माफी मांगना कुछ भी तय करेगा?

Comments

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

— जिमी होफा

+1 - मैं कभी भी ग्राहकों को "नहीं" कहता हूं (जब तक कि मैं उन्हें दोबारा नहीं देखना चाहता) - यह हमेशा "एक्स डॉलर का खर्च आएगा" की तर्ज पर है, "आपकी तकनीक स्टैक का समर्थन नहीं करती है" आदि। "नहीं" इस मुद्दे को बंद कर देता है। प्रतिक्रियाओं का उपयोग करें जो इसे आगे की चर्चा के लिए खोलते हैं। उदा "... लेकिन मैं आपको लागत का 10% जो आप चाहता हूं उसका 90% दे सकता हूं" या ".... लेकिन मैं इसे इस तरह से लागू कर सकता हूं और आपको एक समाधान दे सकता हूं जो इस तरह से काम करता है ...."

— 20

@mattnz - "नहीं" कहना कठिन है, लेकिन कभी-कभी इसकी आवश्यकता होती है। "क्या आप उस बदलाव को कल तक कर सकते हैं?" नहीं। लेकिन मैं इसे सप्ताह के अंत तक प्राप्त कर सकता हूं। "क्या आप एक मोंटे कार्लो विश्लेषण कर सकते हैं इन प्रत्येक कई सौ नियंत्रण चर के साथ विभिन्न यादृच्छिक रूप से प्रति रन?" यह वही है जिसने "किस सहस्राब्दी में आप परिणाम चाहते हैं" प्रतिक्रिया प्राप्त की है। मैंने आयामीता के अभिशाप पर चर्चा की और सुझाव दिया कि हम उस सूची को कुछ उचित करने की हिम्मत करें। आप कैसे कहते हैं कि कोई महत्वपूर्ण नहीं है, लेकिन आप कभी-कभी कहते हैं कि नहीं। कूटनीतिक रूप से, बिल्कुल।

— डेविड हैमेन

एक 10% असफल दर वर्तमान औसत सॉफ्टवेयर डिलीवरी सफलता दर पर एक बेहतर सुधार होगा।

— ग्राहम

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

— क्लिफ

Answer 2

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

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

Comments

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

— साइमन व्हाइटहेड

+1 और अधिक - आपके द्वारा बनाए गए दो बहुत अच्छे बिंदु - कभी भी "नहीं" कहें, और आप ग्राहक के साथ विश्वसनीयता न खोएं।

— मटनज़

+1 "यदि आप ईमानदार हैं तो ग्राहक आपका सम्मान करेगा"। यह कथन इतना सत्य है और सोने के लायक है। जब ग्राहक को विकल्प प्रस्तुत करना ईमानदार हो। बस उन्हें बताएं कि वे जो पूछ रहे हैं वह कुछ पूर्व-निर्मित विजेट नहीं है जिसे आप खरीद सकते हैं और प्लग कर सकते हैं। आपको बता दें कि वे कस्टम निर्मित समाधान के लिए पूछ रहे हैं और कस्टम सॉफ्टवेयर बहुत महंगा है। यह आमतौर पर दो चीजों में से एक का कारण बनता है। 1.) वे एक लागत प्रभावी विकल्प चाहते हैं। 2.) वे कस्टम समाधान के लिए भुगतान करने को तैयार हैं। किसी भी तरह से यह एक जीत / जीत है।

— माइकल रिले - AKA Gunny

Answer 3

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

Answer 4

इस सवाल का औपचारिक रूप से अध्ययन किया गया है और संयुक्त रूप से निर्मित IEEE कंप्यूटर सोसायटी / ACM कोड ऑफ एथिक्स द्वारा संबोधित किया गया है ।

2.01। अपने अनुभव और शिक्षा की किसी भी सीमा के बारे में ईमानदार और स्पष्ट रूप से सक्षम होने के अपने क्षेत्रों में सेवा प्रदान करें।

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

3.09। किसी भी परियोजना पर लागत, शेड्यूलिंग, कर्मियों, गुणवत्ता और परिणामों के यथार्थवादी मात्रात्मक अनुमान सुनिश्चित करें, जिस पर वे काम करते हैं या काम करने का प्रस्ताव करते हैं और इन अनुमानों की अनिश्चितता का आकलन करते हैं।

5.05। किसी भी परियोजना पर लागत, शेड्यूलिंग, कर्मियों, गुणवत्ता और परिणामों के यथार्थवादी मात्रात्मक अनुमान सुनिश्चित करें जिस पर वे काम करते हैं या काम करने का प्रस्ताव करते हैं, और इन अनुमानों की अनिश्चितता का आकलन प्रदान करते हैं।

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

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

http://en.wikipedia.org/wiki/Control_Data_Corporation#CDC_6600:_defining_supercomputing

Comments

नैतिकता के बारे में एक सवाल का जवाब देने के लिए नैतिकता का एक कोड संदर्भित करने के लिए +1।

— २०:०५ पर जे एलस्टन

Answer 5

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

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

क्या फीचर प्रयास के खर्च को सुनिश्चित करने के लिए पर्याप्त मूल्य जोड़ता है?

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

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

दूसरी ओर, जब उचित ग्राहकों के साथ उचित संसाधनों के साथ व्यवहार करना होता है, तो कभी-कभी ग्राहक को यह बताने से बुरा कुछ नहीं होता है कि आपके द्वारा सहमत होने के बाद कुछ सुविधा में कटौती करनी होगी क्योंकि वे पहले ही भाग चुके होंगे और समय / धन / संसाधनों को बढ़ावा दे रहे होंगे या यह दस्तावेज करना और वह 10% वह चीज हो सकती है जिसे पहली बार में प्रोजेक्ट ग्रीनलाइट मिला है। उन स्थितियों में गिर जाते हैं और आप सिर्फ एक ग्राहक खो चुके हैं, और अधिक से अधिक संभावना एक पूरे बाजार में एक बहुत ही मौखिक बुरा संदर्भ प्राप्त की है।

Answer 6

शैतान का वकील खेलना

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

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

इसका कारण यह है कि ग्राहकों को यह आकलन करने में मुश्किल समय हो सकता है कि क्या किसी ठेकेदार का अनुरोध करने में संकोच है या ठेकेदार की क्षमता में कमी के कारण है।

जैसा कि किसी अनुरोध की कठिनाई को मापने के लिए कोई पूर्ण मानदंड नहीं हैं, अक्सर ग्राहक के लिए जो अधिक महत्वपूर्ण होता है वह यह है कि ठेकेदार 100% प्रयास दे रहा है, बजाय इसके कि 90% या 100% अनुरोधों को पूरा किया जाता है।

मान लीजिए कि ग्राहक को दो परिदृश्यों के बीच चयन करना है:

ठेकेदार ए :

• आत्मविश्वास से वे सभी अनुरोधों पर पहुंच सकते हैं
• परिणाम: 90% अनुरोध वितरित किए गए
• ग्राहक खुश है कि ठेकेदार ने 100% प्रयास दिया
• ग्राहक का मानना ​​है कि अपूर्ण अनुरोध अप्रत्याशित मुद्दों के कारण थे, जो शायद ठेकेदारों के नियंत्रण से बाहर हैं

ठेकेदार बी :

• 90% अनुरोधों पर वितरित करने के लिए। भरोसा नहीं कि वे शेष 10% पर वितरित कर सकते हैं
• परिणाम: 90% अनुरोध वितरित किए गए
• ग्राहक निराश है कि ठेकेदार ने अपने अनुरोधों के अन्य 10% को पूरा करने की कोशिश नहीं की
• ग्राहक मानता है कि 10% अनुरोधों की अपूर्णता या तो प्रयास के अभाव या ठेकेदार की क्षमता के कारण थी

दोनों परिदृश्यों में, समान संख्या में अनुरोध वितरित किए गए; हालाँकि, ग्राहक को लगा कि "ओवरकॉमिटिंग" कॉन्ट्रैक्टर ए 100% प्रयास कर रहा था और उसने इसका इस्तेमाल यह प्रमाणित करने के लिए किया कि कॉन्ट्रैक्टर ए के क्रेडिट के लिए शेष अनुरोध वास्तव में मुश्किल थे।

दूसरी तरफ, ग्राहक को लगा कि ठेकेदार बी 100% प्रयास नहीं कर रहा है और सभी अनुरोधों को पूरा करने में असमर्थता या तो ठेकेदार बी के प्रयास या क्षमता की कमी के कारण थी।

अस्वीकरण: मैं एक रणनीति के रूप में अतिआवश्यकता की वकालत नहीं कर रहा हूं; यह सिर्फ एक संभावित वास्तविक दुनिया की स्थिति का अवलोकन है जिसमें ओवरकमिटमेंट के सकारात्मक परिणाम हो सकते हैं।

Answer 7

आपको उन्हें "स्पाइक समाधान" बनाने के लिए समय देने के लिए कहना चाहिए ।

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

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

यहाँ क्या eXtreme प्रोग्रामिंग प्रलेखन इस पर कहते हैं:

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

Answer 8

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

Comments

यह सबसे अच्छा तरीका है ... उपयोगकर्ताओं को दुखी करते हैं। अधिक बार नहीं, इससे मुनाफा कम हो जाएगा

— gnat

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

— ग्राहम