जब किसी प्रोजेक्ट को पूरा करने के लिए डिज़ाइन की "नीरसता" का त्याग करना ठीक है?

15

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

design

— श्री जेफरसन
स्रोत

3

केवल जब यह बिल्कुल आवश्यक है।

— FrustratedWithFormsDesigner

1

यह बहुत आदर्श है जहां मैं काम करता हूं। "आप अभी भुगतान कर सकते हैं, या आप मुझे बाद में भुगतान कर सकते हैं" इतना सच कभी नहीं रहा।

— मेटलमीस्टर

एक उभरते समय सीमा की तरह लगता है ...

1

मैं विरोधाभासी दृश्य लूंगा और हमेशा कहूंगा । यदि कोई परियोजना नहीं की जाती है, तो कोई भी साफ-सुथरा नहीं है।

— drxzcl

1

@MrJ, मैं वास्तव में उपयोगकर्ताओं के बारे में सोच रहा था।

— drxzcl

18

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

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

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

— RationalGeek
स्रोत

3

मैं आपके उत्तर की भावना से सहमत हूं, लेकिन आपको कुछ विवरण याद आ रहे हैं। You need to strike a balance between a technically perfect solution, and the time to market of your productमैं असहमत हूं, जो एक डेवलपर की जिम्मेदारी से परे है। उन्हें पूरी तरह से इसके बारे में पता होना चाहिए, लेकिन उन्हें व्यवसाय निर्णय लेने के लिए जिम्मेदार किसी व्यक्ति को जानकारी देनी चाहिए।

— स्टुपरयूसर

2

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

— फाल्कन

1

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

— तर्कसंगत

1

@ फाल्कन ब्लिज़ार्ड वास्तव में एक ठोस, स्थिर, सुखद खेल में दीर्घकालिक खेल के लिए प्रारंभिक रिलीज में अल्पकालिक लाभ का त्याग कर सकते हैं। शायद यही उनके लिए उचित संतुलन है। लेकिन यह सभी मामलों में उचित संतुलन नहीं है।

— RationalGeek

4

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

— क्रिस्टोफर जॉनसन

12

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

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

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

— एथेल इवांस
स्रोत

1

+1। तकनीकी ऋण वास्तव में इसका वर्णन करने का सबसे स्पष्ट तरीका है।

— दीवानी २

8

जब इसे स्वीकार किया जाता है और इसके परिणामों को स्वामी / ग्राहक / उपयोगकर्ता द्वारा समझा जाता है।

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

आप अब समय और बजट पर हो सकते हैं, लेकिन लंबे समय में बलिदान / जोखिम एक भी अधिक शुल्क लेते हैं। गैर-तकनीकी लोगों को समझना मुश्किल हो सकता है, लेकिन यह है कि बिक्री कर्मचारी क्या हैं।

— JeffO
स्रोत

5

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

फिर भी, दिन के अंत में एकमात्र सफल सॉफ़्टवेयर वह है जो जहाज है।

— जेरेमी
स्रोत

"फिर भी, दिन के अंत में एकमात्र सफल सॉफ़्टवेयर वह है जो जहाज है।" जब तक यह दुर्घटनाग्रस्त हो जाता है और सड़क से कुछ साल जलता है क्योंकि यह ठीक से नहीं लगाया गया था। क्रिया में अल्पदृष्टि।

— वेन मोलिना

1

यदि आप कभी जहाज नहीं करते हैं, तो आप इसे कई वर्षों तक नहीं बनाएंगे ...

— जेरेमी

यदि आप किसी ऐसी चीज को शिप नहीं कर सकते हैं, जो शॉर्ट-विजन प्रबंधन के कारण आपको लंबे समय तक खराब नहीं करेगी, तो आप पहले स्थान पर व्यवसाय के लायक नहीं हैं!

— वेन मोलिना

3

नरम समय सीमा बीत जाने के बाद। और फिर भी यह "ओके" की बहुत कम डिग्री है। कठिन समय सीमा बीतने के बाद, यह निश्चित रूप से, मूट है। क्योंकि वह कठिन समय सीमा की प्रकृति है।

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

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

— फिलिप
स्रोत

2

यहां पोस्ट किए गए अन्य सभी उत्तर अच्छे हैं। मैं यह जोड़ना चाहूंगा कि परियोजना में एक डेवलपर के रूप में, आप डिजाइन के स्टीवर्ड (रक्षक) हैं।

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

उम्मीद है कि यदि आप एक उचित संगठन में हैं, तो एक समझौता किया जाएगा जो समय सीमा को पूरा करने में मदद करता है और एक ही समय में डिजाइन से बहुत दूर नहीं भटका।

इसके साथ ही कहा जा रहा है कि यह मत मानिए कि अगर पीएम की समय सीमा पूरी नहीं हुई तो दुनिया खत्म हो जाएगी और परियोजना विफल हो जाएगी। यह आमतौर पर काला और सफेद नहीं होता है और ज्यादातर समय पीएम की समय सीमा नरम होती है और इसमें समायोजन के लिए जगह होती है।

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

सिर्फ इसलिए कि पीएम खराब दिख रहे हैं इसका मतलब यह नहीं है कि परियोजना विफल हो गई है। यदि आप यह समझते हैं तो आप आश्चर्यचकित होंगे कि आप कितना झुक सकते हैं।

— मेपल_शाफ्ट
स्रोत

1

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

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

— मॉर्गन हेरलॉकर
स्रोत

1

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

— वेन मोलिना
स्रोत

0

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

बेशक, आप बहुत दूर तक नीरसता ले सकते हैं, लेकिन आम तौर पर थोड़ी सी नीरसता आपको बाद में काम करने से बचाएगी।

— जो-हरमन हौलोल्ट
स्रोत

4

एक उत्पाद के रूप में ऐसी कोई चीज नहीं है जिसे रखरखाव की आवश्यकता नहीं है, कोई फर्क नहीं पड़ता कि ग्राहक आपको क्या बताता है।

— एडवर्ड स्ट्रेंज

@ पागल-एडी बहुत सुंदर नहीं। यह एक लोड किए गए प्रश्न के रूप में था; मैं वास्तव में कई मामलों के बारे में नहीं सोच सकता जहाँ आप उस प्रश्न का "नहीं" जवाब देंगे। यहां तक कि एक क्विक'डिहेल्ट स्क्रिप्ट का मतलब केवल एक चीज के लिए था और फिर कभी इस्तेमाल नहीं किया जा सकता था।

— जो-हरमन हौलॉल्ट