कितनी अच्छी तरह से बड़ी बैठकों में एक अच्छा डिजाइन "बेच"

Question

कई बार मैंने एक दुखद घटना देखी है। यहाँ क्या होता है:

1. एक नई परियोजना के लिए एक टीम डिजाइन की समीक्षा।
2. मैं एक साधारण डिजाइन देखता हूं जिसमें काफी छेद हैं।
3. मैं लापरवाही से उनसे बचने के लिए छिद्रों और तरीकों का उल्लेख करता हूं।
4. चेतावनियों को "वास्तविक जीवन में कभी नहीं 'जैसी टिप्पणियों से अनदेखा किया जाता है"
5. अंततः चीजें जो "कभी नहीं होंगी" होती हैं
6. टूटी परियोजना के लिए एक आपातकालीन टीम डिजाइन की समीक्षा।

तो मैं क्या करूं? "मैंने तुमसे कहा था" को रोकते हुए रवैया दोस्तों को जीतने और लोगों को प्रभावित करने के लिए नहीं जा रहा है। कभी-कभी वर्षों बीत जाते हैं और चरण 3 से टिप्पणियां वैसे भी भूल जाती हैं। मैं निश्चित रूप से कष्टप्रद कीट को गोचरों की दुनिया की याद नहीं दिलाना चाहता। मैं अक्सर वापस बैठकर टाइटैनिक की यात्रा को यूरोप के लिए रवाना हो जाता हूं।

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

Answer 1

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

एक बैठक में लोगों को रक्षा मोड में न रखें, वे आपको विजेता बनने के लिए लड़ेंगे। आप उनसे सहमत नहीं होंगे कि पृथ्वी गोल है। यह सामान्य राजनीति है (जैसे फॉक्सन्यूज़ पर कोई भी)

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

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

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

Comments

+1 "उन्हें पृथ्वी के सहमत होने का अवसर नहीं मिलेगा" .. बहुत अच्छी तरह से कहा! मुझे पुरानी सामग्री को "हमारी नई समस्या को हल करने" के लिए "देखना..मुझे चेतावनी दी" के बजाय लाने का विचार भी पसंद है।

— User 1

Answer 2

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

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

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

Comments

"एक व्यक्ति के रूप में प्रतिष्ठा बनाने की कोशिश करें जो उस व्यक्ति की पहचान कर सकता है जो काम करेगा और न कि जो आप सोचते हैं कि कुछ दुर्लभ मामलों के मामले में समस्या होगी।" मुझे लगता है कि यह महत्वपूर्ण है। कई इंजीनियरों को डिजाइन में खामियां खोजने में मजा आता है। इसमें कुछ भी गलत नहीं है, यह एक मूल्यवान कौशल है। लेकिन खामियों को द्विआधारी के रूप में न मानना ​​महत्वपूर्ण है: यदि आप उन लोगों में से एक हैं जो "त्रुटिपूर्ण, और इसलिए अस्थिर" या "सही" के रूप में एक दृष्टिकोण देखते हैं, और इसलिए स्वीकार्य "शायद बीच में कुछ notches सीखने के लिए मूल्यवान होगा" दो चरम सीमाएं। इसके अलावा en.wikipedia.org/wiki/Worse_is_better

— माइक क्लार्क

Answer 3

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

Answer 4

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

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

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

जैसा कि कार्रवाई शब्दों से अधिक जोर से बोलते हैं, आप कर सकते हैं:

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

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

• अंतिम परियोजना को दोहराएं जिसे जहाज करने के लिए एक सप्ताह पहले जमीन को फिर से लिखना आवश्यक था।

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

Answer 5

यदि संभव हो, तो बैठक से पहले (या उसके बाद भी) डिजाइन की समीक्षा करें, और निजी में डिजाइनरों से बात करें। अपने सभी सहयोगियों के सामने एक बैठक में लोगों को गोली मारो। वे आपके सुझावों के बारे में तुरंत रक्षात्मक और बंद दिमाग बनाने की कोशिश करेंगे, और "मुसीबत निर्माता" के रूप में प्रतिष्ठा पा सकते हैं, भले ही आपको लगता है कि आप सहायक हो रहे हैं।

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

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

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

Answer 6

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

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

Comments

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

— जेएफओ 14

Answer 7

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

Answer 8

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

Answer 9

अपने विचार को कैसे लागू किया जाए

पहली बैठकों में समस्याओं को चुनौतियों के रूप में संदर्भित किया जाता है। आप समस्याओं को ठीक करते हैं, आप चुनौतियों को दूर करते हैं। चुनौतियां अच्छी चीजें हैं, समस्याएं नहीं हैं।

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

• तीन समान लेकिन अलग दृष्टिकोण विकसित करें
• अपने बॉस को बताएं कि आपको उसकी मदद की ज़रूरत है
• बताएं कि आप सुनिश्चित नहीं हैं कि समस्या को हल करने के लिए कार्रवाई के तीन तरीकों में से कौन सा सबसे अच्छा है
• उससे पूछें / उसकी मदद करने के लिए आप तीन में से एक का चयन करें

1. यह बेहद शक्तिशाली है। आप जो कर रहे हैं वह विकल्प प्रदान कर रहा है अल्टीमेटम नहीं। अधिक बार अल्टिमेटम को तब गोली नहीं मारी जाती है क्योंकि यह उनका विचार नहीं है और केवल एक विकल्प है।

2. आपके शब्दों का उपयोग यहां बहुत महत्वपूर्ण है। " मुझे आपकी मदद चाहिए "।

3. बॉस को "A", "B", या "C" चुनने दें। वास्तव में, बॉस को "ए", "बी" और "सी" से वर्गों को खींचकर "डी" विकल्प बनाने दें। आप जो कर रहे हैं वह आपके बॉस को चुनाव करने दे रहा है।

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

Answer 10

लो Proof of Conceptअपने विचार कार्यान्वित की। यदि आप अपनी टीम को काम करने और वर्तमान समस्या को हल करने के लिए कुछ दिखाते हैं तो वे इसे पसंद करेंगे।