क्या एक डेवलपर को अनावश्यक या हानिकारक सुविधाओं के खिलाफ बहस करनी चाहिए?


32

नए फीचर्स और गैर-महत्वपूर्ण / संदिग्ध फीचर्स पर चर्चा करते समय डेवलपर्स का अच्छा रवैया क्या है?

मान लें कि आप किसी प्रकार की जावा को भाषा के रूप में विकसित कर रहे हैं, और बॉस कहते हैं: "हमें पॉइंटर्स की आवश्यकता है ताकि डेवलपर्स ऑब्जेक्ट को सीधे ऑब्जेक्ट के साथ फील कर सकें!"

क्या डेवलपर को विचार को शूट करना चाहिए क्योंकि यह अकल्पनीय जटिलता और सुरक्षा कमजोरियों को जोड़ता है, या क्या उसे पूछा जाना चाहिए?

यह एक अच्छा उदाहरण नहीं हो सकता है, लेकिन उन चीजों के बारे में क्या है जो एक ग्रे क्षेत्र में अधिक हैं, जैसे कि वर्कफ़्लो को तोड़ने वाले बटन जोड़ना, या प्रोग्राम की आंतरिक संरचना के खिलाफ जाता है, आदि?

एक नियमित प्रोग्रामर के लिए वितरण "बनाम" नहीं कर सकता "इष्टतम क्या है?"

संपादित करें: सवाल एक बुरे मालिक के बारे में नहीं है: डी

मुझे अधिक दिलचस्पी थी कि लोग नई समस्याओं से कैसे निपटते हैं जो कि ध्यान देने योग्य राशि जोड़ते हैं जबकि शायद उपयोगी हो।

क्या सामान्य रवैया होना चाहिए:

  1. हाँ हम इसे करेंगे, जटिलता को पेंच करेंगे
  2. शायद
  3. नहीं, सामान्य पुनर्मूल्यांकन, और निहितार्थ परिवर्तन को सही नहीं ठहराते हैं

एक अच्छे डेवलपर की प्रतिक्रिया क्या होनी चाहिए?


1
"वास्तुकला का बहुत सिद्धांत" - वह कौन सा सिद्धांत है? यह उदाहरण बहुत बुरा है, मैं इसे आपके प्रश्न से बाहर ले जाऊंगा।
जेरेमी

@ जेरेमी: आप सही कह रहे हैं, मैं एक देशी वक्ता नहीं हूँ, ठीक है।
कोडर

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

जवाबों:


26

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

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

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

यह कार्य राजनीति से जुड़ी एक निविदा स्थिति है, लेकिन इसे सौहार्दपूर्ण ढंग से संभाला जा सकता है।


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

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

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

1
@ जेफ़ वेलिंग और मैं आपके पैरों के साथ मतदान के बारे में अधिक जानकारी नहीं दे सका। :) और मैं मूल रूप से इसके संपादित रूप में इस जवाब से अधिक सहमत हूं, लेकिन मुझे लगता है कि यह अब एक अलग जवाब है।
पीटरऑलेनवेब

1
@PeterAllenWebb मैं देख रहा हूँ कि आपका क्या कहना है (इसके लायक क्या है, मैंने इसका उत्तर संपादित किया है जो संभवतः इस चर्चा को विवादास्पद बना देता है), लेकिन मेरी राय में यदि आपके बॉस सहित एक समूह, आप पेशेवरों और विपक्षों को कवर करते हैं, और बॉस एक स्पष्ट रूप से हीन समाधान चुनता है , उसे इसके लिए बुलाया जाना चाहिए। मैं समझता हूं कि आम जरूरत के प्रबंधकों को असहमति की राय को दरकिनार करना पड़ता है, लेकिन मुझे ऐसा लगता है कि एक प्रबंधक का मामला यह नहीं मानना ​​चाहता कि वह गलत था - किसी भी प्रबंधक आईएमओ में एक दोष ।
जेफ वेलिंग

14

यदि आपका बॉस आपको बेवकूफ काम करने के लिए कहता है, तो आपको (कृपया) समझाना चाहिए कि यह बेवकूफ क्यों है।

यदि उसे बात नहीं मिलती है, तो आप बेवकूफ बातें करने के लिए बाध्य हैं। बस। वह मालिक है। ऐसे मामले में आप बस वही कर सकते हैं जो वह कहता है, या अपने बॉस से बात करता है या नौकरी बदलता है।


बॉस के साथ कोई समस्या नहीं है, यह हिमशैल के छिपे हुए हिस्से के साथ सुविधाओं के बारे में है।
कोडर

3
@ कोडर: उस मामले में आपको प्रबंधन को यह बताना होगा कि विकास शुरू करने से पहले आपको विश्लेषण की आवश्यकता होगी।
FrustratedWithFormsDesigner

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

9

आप बॉस को बता सकते हैं कि जब यह तकनीकी रूप से संभव है, तो मौजूदा कोड, परीक्षण, प्रतिगमन परीक्षण को फिर से लिखने के लिए, विश्लेषण, प्रयास पर खर्च किए गए समय और धन में एक्स राशि खर्च होगी ... और फिर पूछें कि क्या यह सुविधा के लायक है। । कभी-कभी उत्तर "हाँ! हमारे पास यह होना चाहिए!", कभी-कभी यह "नहीं, मुझे नहीं लगता" होगा।

यदि सुविधा के लिए कहा जा रहा है कि आप एप्लिकेशन के कुछ मुख्य सिद्धांत का उल्लंघन करते हैं (जैसे कि "एक नीला बटन जोड़ें!" UI के लिए जो कल्पना और डिज़ाइन केवल ग्राहक के अनुरोध के अनुसार लाल बटन है) तो मुझे लगता है कि यह ठीक है "क्यों?" और उल्लेख है कि यह पूर्व-स्थापित डिजाइन के खिलाफ जाता है।

अंत में, लगभग सब कुछ एक "कर सकता है" (यह एक नीले-केवल यूआई के लिए लाल बटन जोड़ने के लिए तकनीकी दृष्टिकोण से कठिन नहीं हो सकता है ), यह "क्या करना चाहिए?" का सवाल है।


आपके संपादित प्रश्न का उत्तर देने के लिए, मुझे लगता है कि उत्तर # 2 होना चाहिए, "हो सकता है", आगे की जांच और विश्लेषण लंबित हो।

आप # 1 "हां, बिना शर्त" जवाब नहीं देना चाहते क्योंकि आप किसी ऐसी चीज के लिए प्रतिबद्ध हो सकते हैं जिसे आप दिए गए समय सीमा में देने में सक्षम नहीं हैं।

आप # 3 का जवाब नहीं देना चाहते हैं "नहीं, यह बहुत अधिक काम है" क्योंकि तब ऐसा लगता है कि आप असहयोगी और अनावश्यक रूप से कठिन हो रहे हैं।


6

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

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

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

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

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


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

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

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

10
100 में से 99 बार, वहाँ हमेशा एक कहावत के पीछे व्यापार की जरूरत है। आपको हमेशा उस एनईईडी को ढूंढना और उससे मिलना चाहिए, भले ही वह WANT के सटीक रूप में न मिला हो। और, आप कभी भी उन्हें सपाट रूप से यह नहीं बता सकते हैं कि वे क्या नहीं कर सकते, क्योंकि वे सुनेंगे कि आप उन्हें वे नहीं दे सकते हैं जो वे चाहते थे। यही वह है जो वे आपको प्रदान करने के लिए अच्छा पैसा दे रहे हैं, और वे बहुत आसानी से आपको काट सकते हैं और किसी और को कोड दे सकते हैं, जो उन्हें बिलकुल वही देगा जो वे पत्र को चाहते हैं, और उस कार्यक्षमता के साथ किसी भी समस्या को दोष देते हैं। ।
कीथ्स

2
@KeithS: बिल्कुल! मुझे इससे बेहतर कहने के लिए धन्यवाद।
डेविड श्वार्ट्ज

5

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

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

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

बेशक यह भी संभव है कि आप सिर्फ गलत हों। सॉफ्टवेयर इंजीनियरिंग मज़ा नहीं है?


3

चूंकि सवाल बहुत अस्पष्ट है, मैं अपनी प्रतिक्रिया के साथ थोड़ा सामान्य करने वाला हूं।

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

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


2

सबसे पहले से ही कहा जाता है, लेकिन एक चीज है जिसे मैं अपने वर्तमान कार्य वातावरण में जोर दूंगा। मैं एक ऐसी कंपनी के लिए काम करता हूं जो अन्य कंपनियों के लिए एक ठेकेदार है और बाहर के अनुप्रयोग व्यवसायिक प्रक्रिया से संबंधित हैं (उचित मात्रा में वे बिक्री और ग्राहक संचार चलाते हैं)।

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

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

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


2

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

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

2

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

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

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

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

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

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


1

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

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

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

1

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

यह बहुत अनुरोध पर निर्भर करता है। एक पूरी परियोजना को प्रभावित करने के लिए सूचक कार्यान्वयन काफी बड़ा है, इसलिए यदि कोई विकल्प दिया जाता है, तो इसकी खूबियों को तौला जाना चाहिए।

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

यह संतुलन के बारे में है और यह जानना है कि आपकी लड़ाई कब होगी। कुछ चीजों को आसानी से लागू करना आसान होता है, साथ ही इसके सामाजिक पहलुओं से निपटना भी शामिल है।


1

मुझे जो समस्या दिखाई दे रही है वह तर्क शब्द का आपका उपयोग है।

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

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

यदि ऐसा नहीं होता है, तो शायद यह उन्हें संहिताबद्ध करने का अच्छा समय है!


1
  1. एहसास है कि आप सब कुछ नहीं जानते हैं और सब कुछ नहीं कर सकते।

  2. यदि आप सुनिश्चित हैं कि यह एक बुरा विचार है, तो कहें कि क्या बुरा है।

  3. यदि वे इसे आप पर धकेलने का प्रयास करते हैं, तो या तो कहें - विश्लेषण के लिए अधिक समय चाहिए, यदि आपको अधिक समय चाहिए या कहें कि हमें इस समस्या का अच्छा समाधान नहीं मिला है।

  4. यदि वे अभी भी बुरे विचार को लागू करने पर जोर देते हैं, तो उनसे एक स्वीकृति प्राप्त करें कि आपने अपने कारणों सहित इसके खिलाफ सलाह दी है। आप अपने प्रबंधक को प्रतिलिपि के साथ चर्चा का सारांश देते हुए एक ईमेल भी भेज सकते हैं। यह आपके ** बाद में बचा सकता है।


0

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

1) क्या? ग्राहक क्या चाहता है?

२) कैसे? हम इसे प्रौद्योगिकी के नजरिए से कैसे पूरा करते हैं।

ग्राहक जो चाहता है वह अंतिम निर्णय निर्माता होता है क्योंकि वे बिल का भुगतान करने वाले होते हैं


0

एक डेवलपर के रूप में, आपको वास्तव में परवाह नहीं करनी चाहिए कि किन आवश्यकताओं को लागू करने का अनुरोध किया गया है।

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


ठीक इसी तरह की डेवलपर मैं अपनी पिछली नौकरी में था (जो "वास्तव में परवाह नहीं करनी चाहिए")। मुझे लगता है कि यदि आप वास्तव में किसी परियोजना की परवाह करते हैं, तो आप बहुत बेहतर कर सकते हैं, जिस स्थिति में आप कुछ बुरा नहीं होने देंगे, क्योंकि परियोजना प्रबंधक एक प्रोग्रामर नहीं है।
अत्तिला ओ।

@Attila तुम गलत समझे। "एक परियोजना के बारे में नहीं ले जा रहा है" और "नहीं ले जा रहा है कि क्या परियोजना प्रबंधक इस या उस सुविधा का अनुरोध करता है" अलग-अलग चीजें हैं
BЈови11

0

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


0

यह मेरे लिए लगभग एक दिन का कार्य है, और वास्तव में मुझे खुशी है कि यह है।

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

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

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


0

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

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

और, यदि नई सुविधा बहुत बेवकूफ है या काम का माहौल बहुत भद्दा है, तो यह एक और काम खोजने का समय है।

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