किसी भी प्रोग्रामिंग समस्या को कैसे हल करें

सभी को नमस्कार!

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



अच्छा पढ़ लो!

इसलिए यह दिन आ गया है। हो सकता है कि यह आपका पहला कार्य दिवस हो, या हो सकता है कि आप इस स्थान पर दस वर्षों से काम कर रहे हों - यह कोई मायने नहीं रखता। यह सभी के साथ होता है: आप अंत में एक ऐसे काम के लिए आते हैं जिसे आप आसानी से समझ नहीं पाते हैं।

क्या करें? बस शुरू करें और आशा करें कि सब कुछ अपने आप से काम करता है? या बॉस को स्वीकार करें कि आप ऐसा नहीं कर सकते, क्योंकि आप समझ नहीं रहे हैं?

मुझे लगता है कि आपने अनुमान लगाया है कि सही उत्तर न तो एक है और न ही दूसरा है!

मैंने देखा कि प्रोग्रामिंग में, किसी भी अन्य पेशे के रूप में, एक पूरी तरह से समझ से बाहर काम करने का सामना किए बिना एक कामकाजी सप्ताह (और कभी-कभी काम करने का दिन) जीना लगभग असंभव है।

लेकिन चिंता मत करो! बड़ी खुशखबरी है। न केवल आप इस समस्या को हल कर सकते हैं - इसके अलावा, यह आपको लाभ भी दे सकता है।

आखिरकार, ऐसा करने में, आपको अपने ज्ञान और कौशल का विस्तार करना होगा जो आपने किया था और पहले पता था।

आगे मैं आपको बताऊंगा कि आपके लिए निर्धारित आवश्यकताओं और कार्य को पूरा करने के लिए आवश्यक ज्ञान के बीच की खाई को कैसे पाटा जाए।

"आवश्यकताओं" के बारे में

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

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

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

चरणों के बारे में

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

यह संभव है कि कई सवालों के जवाब केवल आवाज की आवश्यकताओं के आधार पर या आपके व्यक्तिगत अनुभव की अपर्याप्तता के कारण नहीं दिए जा सकते हैं।

आपको अन्य डेवलपर्स, टीम लीड, उत्पाद स्वामी, व्यवसाय विश्लेषक या यहां तक ​​कि दादी के साथ परामर्श करने की आवश्यकता हो सकती है! और शायद उनमें से प्रत्येक के साथ, समस्या हल होने से पहले!

हालाँकि, यह सामान्य है। इसका मतलब है कि आप अलग-अलग ज्ञान एकत्र करेंगे और इसे एक पूरे में इकट्ठा करेंगे - और इसलिए आप सर्वोत्तम संभव परिणाम प्राप्त कर सकते हैं!

अंत में, अंतिम चेतावनी: औपचारिकता के साथ इसे ज़्यादा मत करो! यहां सबसे महत्वपूर्ण बात यह है कि कार्य को जल्दी से समझना है। कोई कृत्रिम बाधाओं और लाल रिबन की जरूरत नहीं है! एक समस्या को हल करने के लिए एक व्यवस्थित योजना की जरूरत है जिसे आप वर्तमान में नहीं समझते हैं।

स्टेज एक: समस्या का विश्लेषण करें

इस स्तर पर, हम यह समझने की कोशिश कर रहे हैं कि आपको क्या करने के लिए कहा गया था। जब तक हम यह तय करने की कोशिश नहीं करेंगे कि हम इसे कैसे करेंगे!

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

हम समस्या को वर्गीकृत करते हैं

किसी कार्य को वर्गीकृत करने का अर्थ है यह निर्धारित करना कि इसे हल करने के लिए क्या काम करना होगा। यहाँ कार्य प्रकारों के कुछ उदाहरण दिए गए हैं:

• बग ठीक करना
• नई सुविधा
• नया ऐप
• अनुसंधान कार्य
• प्रदर्शन अनुकूलन

याद रखें कि विकल्पों की यह सूची सीमित नहीं है।

इस मामले में, हमें यह तय करना चाहिए कि आपसे किस तरह का काम अपेक्षित है। यह महत्वपूर्ण है क्योंकि यह सीधे प्रभावित करेगा कि आप किस तरह का काम करेंगे।

यह चरण विशेष रूप से फ़ज़ी आवश्यकताओं के साथ महत्वपूर्ण है, उदाहरण के लिए: "हमें साइट को अपडेट करने के बाद अपने क्लाइंट कैश को किसी तरह से साफ़ करने का एक तरीका चाहिए।"

इस आवश्यकता की कुछ संभावित व्याख्याएँ यहाँ दी गई हैं।

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

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

एक या दो सरल कथनों के रूप में समस्या का सार तैयार करें।

जटिल आवश्यकता को सारांशित करें, जैसे कि प्रश्न का उत्तर "आप आज क्या काम कर रहे हैं?" यह इतना सरल नहीं हो सकता है, लेकिन आपको कोशिश करनी चाहिए और समस्या के सार को एक या दो वाक्यों को कम करना चाहिए।

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

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

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

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

आलोचनात्मक विवरण पर प्रकाश डालिए

अब आपको (स्वतंत्र रूप में, आपके लिए सबसे सुविधाजनक) मुख्य चीजों की एक सूची बनानी चाहिए, जिन्हें करने की आवश्यकता है।

यह, फिर से, मुख्य चरणों में से प्रत्येक का बहुत सरल निचोड़ होना चाहिए।

यह चरण-दर-चरण या विस्तृत समस्या निवारण मार्गदर्शिका नहीं है।

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

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

हमारा अगला काम एक नए अवसर का एहसास करना है: “प्रत्येक उपयोगकर्ता को हमारे आंतरिक उत्पाद का लक्षित विज्ञापन प्राप्त करना चाहिए। यह विज्ञापन हमारे द्वारा एकत्रित किए गए डेटा के आधार पर उपयोगकर्ता की आवश्यकताओं के अनुरूप होना चाहिए। "

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

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

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

• उपयोगकर्ता हमें यह बताने में सक्षम होना चाहिए कि वे अब कुछ विज्ञापन नहीं देखना चाहते हैं।

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

आगे बढ़ने से पहले, मैं आपकी संभावित आलोचना का जवाब देना चाहूंगा।

शायद आप सोचते हैं: "सामान्य रूप से वितरित व्यवसाय में, डेवलपर के लिए मेज पर आवश्यकताओं को रखने से पहले इस तरह का काम किया जाना चाहिए" - और मैं दृढ़ता से आपके साथ सहमत हूं!

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

उस समस्या को पहचानें जिसे आप हल करने का प्रयास कर रहे हैं।

प्रश्न का उत्तर दें: "किसी को इसका उपयोग क्यों करना होगा?" या "वास्तविक या कथित समस्या क्या है जिसे मैं इस मामले में ठीक करने की कोशिश कर रहा हूं?"

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

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

स्टेज दो: आवश्यकताओं की व्याख्या और मूल्यांकन करना

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

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

ये व्यावसायिक अवधारणाएं हो सकती हैं, जैसे उत्पाद के नाम, ग्राहक या प्रक्रियाएं। विकास से संबंधित शर्तें हो सकती हैं - उदाहरण के लिए, उपकरण, एप्लिकेशन, मॉडल, सेवाओं या पुस्तकालयों के नाम।

आपको यह सुनिश्चित करने की आवश्यकता है कि आप सभी महत्वपूर्ण शर्तों को पूरी तरह से स्पष्ट रूप से समझते हैं, इसलिए आप यह सुनिश्चित कर सकते हैं कि आप कार्य को सही तरीके से लागू कर रहे हैं।

शायद आप पहले से ही समझते हैं कि आपको एकत्रित उपयोगकर्ता जानकारी तक पहुंचने के लिए एक तरीके का आविष्कार करने की आवश्यकता है, लेकिन क्या आप समझते हैं कि इसका मतलब "इसे दाव में जोड़ें" है?
आप शायद समझते हैं कि आपको विज्ञापन डेटा को प्रारूपित करने की आवश्यकता है, लेकिन क्या आपको पता है कि "MADF" (विज्ञापन समाचार फ़ीड के लिए मार्कअप) क्या है?

मुझे एक या दूसरे की समझ नहीं है।

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

तय करें कि कार्य कैसे किया जाना चाहिए।

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

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

दूसरों में, आपके द्वारा उठाए जाने वाले प्रत्येक कदम विस्तृत होंगे।

सबसे अधिक संभावना है, आप किसी तरह की मध्यवर्ती स्थिति में होंगे।

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

यह कदम पूरी तरह से स्वाभाविक लगता है, लेकिन जिस क्रम में हम इसके लिए आगे बढ़ते हैं, उस पर ध्यान देना महत्वपूर्ण है।

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

हालाँकि, चूंकि आपने समस्या को समझने के लिए पहले ही समय ले लिया है, इसलिए अब आपको पूरी समस्या का एक स्पष्ट विचार होना चाहिए, इसे प्राप्त करने के लिए आवश्यक कदमों का मूल्यांकन करना चाहिए।

निर्धारित करें कि क्या कार्य संबोधित किए जा रहे हैं।

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

व्याख्या चरण में, विवरण पर ध्यान दें - हम इसे कैसे करते हैं।

दूसरे चरण को "व्याख्या और मूल्यांकन" कहा जाता है, क्योंकि अब आप "कैसे" और "क्या और क्यों।" आप समग्र चित्र के आधार पर विवरण की व्याख्या करते हैं। आप विवरणों का मूल्यांकन करते हैं और निर्धारित करते हैं कि मूल समस्या हल हुई थी या नहीं।

अपने आप से पूछें: क्या मुझे जिन चरणों के परिणाम के लिए नेतृत्व करने का निर्देश दिया गया था, उन्हें कार्य के अंतिम लक्ष्य के रूप में नामित किया गया था? क्या योजनाबद्ध परिणाम वास्तव में मूल समस्या को हल करता है?

यदि आप सुनिश्चित हैं कि सभी समस्याओं को हल किया जा सकता है, और विवरण सार्थक हैं, तो आप काम कर सकते हैं! अन्यथा, सभी प्रकार के संघर्षों को हल करने के लिए तीसरे चरण में जाना आवश्यक है।

स्टेज तीन: हम समस्या को गंभीर रूप से स्वीकार करते हैं

इस स्तर पर, आपको विश्वास करना चाहिए कि आप कार्य और समाधान दोनों को समझते हैं। सभी को यह देखना बाकी है कि क्या यह निर्णय सही है।

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

दूसरी ओर, हम अनुचित दावे नहीं करने जा रहे हैं। कोई यह नहीं कह सकता कि कुछ गलत है, क्योंकि "ऐसा लगता है" या बस "पसंद नहीं"। ठोस और अच्छी तरह से डिज़ाइन किए गए तर्क उन्नत होने चाहिए।

इसलिए, हम सक्षम असहमति के बुनियादी नियमों को रेखांकित करते हैं

जानिए कब करें असहमत

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

यदि आप ऐसा कोई समाधान नहीं दे सकते हैं, तो मुझे इसके बारे में शुरुआत से ही स्पष्ट रूप से बताएं।

दूसरों से असहमत होने पर सावधान रहें। सभी को सुनने और सब कुछ समझने में बहुत समय लगता है - और केवल तब ही आप सहमत नहीं हो सकते।

यदि इस बिंदु तक आप ध्यान से वर्णित सभी चरणों का पालन करते हैं, तो यह बहुत संभावना है कि आप हर चीज में अच्छी तरह से वाकिफ हैं। हालांकि, अपने आप को अपनी गणना में बंद न करने का प्रयास करें - आप कुछ याद कर सकते थे!

मुझे शब्दों के साथ चर्चा शुरू करना पसंद है: "ऐसा नहीं है कि मैं आपके साथ सहमत नहीं हूं, मैं अभी तक समझ नहीं पाया हूं।" बाद में, यदि आवश्यक हो, तो एक मजबूत असहमति व्यक्त की जा सकती है, लेकिन एक शुरुआत के लिए - यह पता लगाने के लिए।

जानिए कैसे सही तरीके से असहमत

यह सुनिश्चित करने के लिए कि हमारी असहमति वस्तुनिष्ठ होगी, हम कई उपाय करेंगे, जो हमें यह समझने में मदद करेंगे कि क्या हमारे तर्क वैध हैं।

उद्देश्य असहमति हमें निम्नलिखित तथ्यों में से कम से कम एक प्रदर्शित करने की अनुमति देती है:

• निर्णय अच्छी तरह से सूचित नहीं किया गया है
• निर्णय गलत है
• कार्य या समाधान अतार्किक है
• समाधान अधूरा है

जानकारी का अभाव आक्रोश का कारण नहीं है; इसका मतलब सिर्फ इतना है कि समाधान बनाते समय, आप अपूर्ण डेटा से आए थे। शायद टीके के ड्राफ्टर्स को पहले से मौजूद सिस्टम के बारे में पता नहीं था, जो आवश्यक कार्रवाई करने में सक्षम था।

गलत जानकारी होने का मतलब है गलत जानकारी के आधार पर समाधान बनाना।

यह एक ऐसा मामला है, जब TK के ड्राफ्टर्स की राय में, मौजूदा सिस्टम कुछ कर सकता है, लेकिन वास्तव में इसके लिए यह संभावना प्रदान नहीं की जाती है। उदाहरण के लिए, एसईओ टीम ने आपको अपने आवेदन में उपयोगकर्ता खाते के साथ Google इंडेक्स पेज देने के लिए कहा है। Google ऐसा नहीं कर सकता। इसका मतलब यह है कि आपकी seokhniki Google खोज रोबोट के कार्यों को गलत समझती है।

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

समाधान अधूरा है, और कभी-कभी यह उद्देश्य पर किया जाता है। सॉफ्टवेयर विकास में, हम अक्सर शुरुआत करने के लिए MVP (न्यूनतम व्यवहार्य उत्पाद) बनाने की कोशिश करते हैं। इसका मतलब यह है कि पहले ऑपरेशन में, आप जानबूझकर एक कार्यात्मक के कार्यान्वयन में देरी कर सकते हैं जो बिल्कुल आवश्यक नहीं है।

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