जब एक अच्छे प्रोजेक्ट लीडर या बॉस का सामना करना है

31

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

कब और कैसे (यदि कभी) हमें राय में अंतर व्यक्त करना चाहिए?

teamwork

— treecoder
स्रोत

12

कोई भी पूर्ण नहीं है। संभावित मुद्दों को स्पष्ट करने वाली बैठक के बारे में क्या?

2

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

— एसएफ।

1

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

— Xeoncross

4

"सामना" एक बहुत मजबूत और नकारात्मक शब्द है

— विंको द साने

1

यहां तक कि जीनियस के भी अपने दोष हैं।

— atद्रालो जूल

76

मान लीजिए कि आपको लगता है कि आपका बॉस गलत है। आपके पास तीन विकल्प हैं

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

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

— sharptooth
स्रोत

1

"विशिष्ट चिंताओं" के लिए +1 - यह सही पाने के लिए आमतौर पर सबसे कठिन हिस्सा है, लेकिन यह किसी भी रचनात्मक चर्चा के लिए सबसे महत्वपूर्ण है।

— जॉरिस टिम्मरमन्स

9

विचारों के बारे में विशिष्ट चिंताओं के लिए +1 और परिणाम के बारे में हमेशा सोचें - मैं सहमत हूँ

— treecoder

2

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

— डीजेकवर्थ जूल 22'11

1

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

— पैट्रिक ह्यूजेस

1

@SnOrfus - कि phrasing उसे 'आपके डिजाइन' बनाम 'मेरे विचार' शब्द के साथ रक्षात्मक पर रख सकता है। सुरक्षित हो सकता है "वर्तमान डिज़ाइन में, क्या यह <> एक समस्या होगी? मैं सोच रहा था कि क्या ऐसा करने से <> समस्या दूर होगी?"

— क्रिश सी

49

उसके साथ उसी तरह से व्यवहार करें - विरोध करते समय धीरे और सम्मानपूर्वक।

— जस
स्रोत

17

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

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

मैं इसे शिक्षा के लिए एक अवसर के रूप में देखता हूं - यह काम करने की तुलना में आसान है :)

— treecoder

14

क्या यह पुराने या तो आक्रामक-या-निष्क्रिय पतन का उदाहरण नहीं है?

क्लासिक तीसरा विकल्प मुखरता है, जो रचनात्मक आलोचना और विनम्र असहमति की अनुमति देता है ।

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

http://en.wikipedia.org/wiki/Assertiveness

और दिन के अंत में, एक प्रकार की निष्क्रियता - अपने श्रेष्ठ के प्रति अवमानना - हमेशा आवश्यक होने वाली है। उन्होंने कहा कि निर्णय के लिए अंतिम जिम्मेदारी के साथ एक है - कर रहे हैं की क्षमता है, अधिकार और जिम्मेदारी नहीं एक ही बात है, लेकिन वे कम से कम करना चाहिए एक साथ चलते हैं।

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

http://www.amazon.com/People-Skills-Yourself-Resolve-Conflicts/dp/067162248X

— steve314
स्रोत

5

चूँकि आप उसका सम्मान करते हैं और वह एक चतुर व्यक्ति की तरह लगता है, तो क्यों न उससे निम्नलिखित तरीके से पूछें:

"आपकी पद्धति / तरीका / वास्तुकला एक्स समस्या को कैसे संभालती है?" यदि ऐसा नहीं है, तो कुछ ऐसा कहो: "अच्छा है कि इसे कैसे करना है, इस तरह से x समस्या को कैसे हैंडल किया जाता है?"

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

काश मैं एक और अधिक ठोस उदाहरण के साथ आ सकता, लेकिन मुझे लगता है कि आपको विचार प्राप्त करने में सक्षम होना चाहिए।

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

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

आशा है कि ये आपकी मदद करेगा।

— होल्गर
स्रोत

4

CONFRONT शब्द का उपयोग करके, आप दिखा रहे हैं कि आप समस्या को सही मानसिकता के साथ नहीं ले रहे हैं।

यह टकराव नहीं है। यह शत्रुतापूर्ण नहीं है। यह जुझारू या क्रोधित नहीं है। यह विभिन्न दृष्टिकोणों और लागतों और लाभों की चर्चा है।

धधकती हुई छह बंदूकों के साथ मत जाओ। बस उसे कुछ ऐसा बताएं जिसके बारे में आपने सोचा है। "क्या होगा अगर हम इसे इस तरह से करना चाहते थे?" कौन जानता है, आप उसे मना सकते हैं।

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

— स्कॉट सी विल्सन
स्रोत

धधकती हुई छह बंदूकों के साथ मत जाओ। बस उसे कुछ बताएं जो आपने सोचा है - हम हमेशा ऐसा करते हैं - लेकिन स्थिति अजीब होती है - और यह टकराव की तरह दिखता है

— treecoder

3

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

— स्कॉट सी विल्सन

2

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

जब आप (और / या टीम) राय में भिन्न होते हैं, तो परियोजना के नेता से पूछें कि क्या उसके पास इस पर चर्चा करने के लिए कुछ समय है, या शायद एक छोटी बैठक (15-30 मिनट) की भी योजना है। एक सम्मानजनक तरीके से अपनी राय दें और सुनें कि उसने अपना निर्णय अन्यथा क्यों किया। अगर मैं देखूं कि आपने उसे कैसे वर्णित किया है, तो वह समस्या पर चर्चा करने और अपनी अंतर्दृष्टि साझा करने में प्रसन्न होगा। वह नहीं कहेगा "क्योंकि मैंने ऐसा कहा था" (ऐसे लोग दुखी होते हैं)। यदि आप अपनी नौकरी को बनाए रखना चाहते हैं, तो इस मामले में अपनी खुद की राय को नजरअंदाज कर दें या इसे छोड़ दें और दूसरी नौकरी छोड़ दें क्योंकि आप दुखी हो जाएंगे।

एक अच्छी चर्चा कई मायनों में खत्म हो सकती है:

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

वैसे भी, आपको इसे सीखने के अवसर के रूप में देखना चाहिए और जब तक आप इसे सभ्य और सम्मानजनक रखते हैं, आपको इन चर्चाओं के साथ बहुत अच्छे अनुभव होंगे।

— बार्ट
स्रोत

1

यहां तक कि अगर आप 99% गलत हैं, तब भी अपनी शंका को आवाज देना अच्छा है, ताकि आप जान सकें कि आप गलत क्यों हैं। बेशक, अगर आधे साल के बाद भी आप 99% गलत हैं, तो कुछ और हो सकता है :)

— जोरिस टिम्मरमन्स

... सबसे अधिक संभावना है कि अधिक अनुभव है - यह सच है, लेकिन कई बार मैं (और हम) बहस करने के लिए आग्रह का विरोध नहीं कर सकते हैं

— treecoder

क्यों नहीं, जब तक आप इसे सम्मानपूर्वक रखते हैं। यह हर किसी के लिए सीखने का अवसर होगा।

— बार्ट

@MadKeithV - यह ठीक है, जब तक आप दूसरों के उत्पादक समय को बर्बाद नहीं कर रहे हैं, जब देखना और सुनना लगभग उतना ही प्रभावी होगा। बेवकूफ सवाल नहीं हैं, लेकिन दिन में केवल इतने ही घंटे हैं।

— mwigdahl

2

बस लाओ!

सबसे सिविल और क्लीवर तरीके से, मैं आमतौर पर कहूंगा कि "मैं इस पहलू से चिंतित हूं, इस समस्या पर आपके विचार क्या हैं?"

मुझे शिक्षित करने के लिए मैं उनके दरबार में गेंद डालूंगा।

— ब्रायन हैरिंगटन
स्रोत

1

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

यदि आपके पास एक अच्छा बॉस है (और आप कहते हैं कि आप ऐसा करते हैं) तो आमतौर पर यह समस्या नहीं होगी! आप देखेंगे कि आप रचनात्मक चर्चा कर सकते हैं और आप सभी के लिए सर्वोत्तम समाधान कर सकते हैं।

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

इसलिए आपका बॉस बॉस है - निर्णय लेने के लिए जिसे डेवलपर्स को बनाने में मुश्किल हो सकती है।

— जोरिस टिम्मरमन्स
स्रोत

1

मेरी राय में और मैं आमतौर पर अपने बॉस के साथ कैसा व्यवहार करता हूं:

हमेशा अपनी राय दें और विषय गर्म होने पर ASAP करें। आदर्श रूप से जब आप एक नए मुद्दे या परियोजना पर बाद में करने के बजाय एक ऐसा घोटाला कर रहे होते हैं जब आप अपनी हिम्मत जुटा चुके होते हैं और निर्णय पहले ही सेट हो चुके होते हैं।

आपको अपनी राय, चिंताओं, मुद्दों पर खुलकर सुझाव देना चाहिए और यह सुनिश्चित करना चाहिए कि वे यह सुझाव देने के बजाय सुझाव या चिंताओं के रूप में सामने आएं कि इसे इस तरह से किया जाना चाहिए।

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

सौभाग्य।

— पूछ-ताछ करनेवाला
स्रोत

1

यदि वह उतना ही अच्छा वास्तुकार है जितना कि आप उसका वर्णन करते हैं तो अपनी चिंताओं के तार्किक और विशिष्ट कारणों के साथ एक शिक्षित तरीके से उससे संपर्क करें।

यदि आपके पास समय / संसाधन परिदृश्यों के कुछ परीक्षण करने का प्रयास करते हैं जो यह साबित करते हैं कि आप सही हैं, तो आपके पक्ष में कुछ डेटा होना एक बहुत बड़ा प्लस है।

एक बार जब आप उसके साथ बात करते हैं तो वह केवल:

a) आपसे सहमत: समस्या हल!

बी) उन्हें अस्वीकार करें और आपको समझाएं कि क्यों: हो सकता है कि आखिरकार आप वही हैं जो गलत है।

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

— jasalguero
स्रोत

1

मेरा प्रश्न है: विचारों में भिन्नता व्यक्त करने के लिए कब और कैसे (क्या?)।

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

असली कुंजी यहां कब और कैसे है।

1 'जब': प्रत्येक वातावरण अलग है लेकिन कुछ स्थानों पर साप्ताहिक बैठक या खुली / गोल मेज चर्चाएँ होती हैं जहाँ कुछ विषयों को लाना उचित होता है। मुख्य बात यह है कि आप ऐसा नहीं करना चाहते हैं, जैसे कि आप कुछ व्यक्तिगत डिज़ाइन तर्क सार्वजनिक कर रहे हैं या कर रहे हैं, जो आपके और केवल 1 या 2 अन्य लोगों के बीच है। जिन लोगों को आप चुनौती दे रहे हैं, उन्हें चुनौती नहीं दी जाएगी और शायद वह सार्वजनिक रूप से शर्मिंदा भी हों। इन स्थितियों के लिए, अपने विचारों को विस्तृत करने के लिए प्रश्न में व्यक्ति (नों) के साथ 1 पर 1 बैठक का समय निर्धारित करने का प्रयास करें।

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

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

शुभ लाभ!

— atconway
स्रोत

असली कुंजी यहां कब और कैसे है। - असली ही नहीं - मुश्किल और नाजुक भी

— treecoder

1

मुझे यकीन नहीं है कि आप कैसे गलती किए बिना एक शानदार सॉफ्टवेयर आर्किटेक्ट बन सकते हैं और उनके बारे में पूछताछ की जा सकती है। मुझे लगता है कि यह मान लेना सुरक्षित है कि वह पहले भी इस स्थिति में रहा है।

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

— थॉमस डार्लिंगटन
स्रोत

1

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

एक दृष्टिकोण / डिजाइन केवल सही या गलत हो सकता है, जैसे गणित में 2 + 2 = 4 और पांच नहीं। यदि यह गलत है तो आपको तथ्यात्मक आपत्तियों के आधार पर सही समाधान के साथ आने की आवश्यकता है।
अब तक सिस्टम डिज़ाइन में अधिकांश विषय संभव दृष्टिकोण हैं जो अनन्य नहीं हैं। अन्य विकल्प भी काम कर रहे हैं, जो चुनने के लिए अनुभव, स्वाद, पूर्वाग्रह, समग्र चित्र आदि पर निर्भर करता है। संभवतः बेहतर दृष्टिकोण की देखरेख नहीं करने के लिए आमतौर पर प्रस्तुतियां और चर्चाएं होती हैं, जब डेवलपर्स को अपनी राय साझा करने और साझा करने के लिए प्रोत्साहित किया जाता है। लेकिन यह भी ध्यान रखें, चर्चा करने और लागू करने की अवधि के लिए, फुर्तीली प्रोग्रामिंग में इन चरणों को अच्छी तरह से परिभाषित किया गया है।

— होर्स्ट वाल्टर
स्रोत