बहुत कम समय दिए गए महत्वपूर्ण तकनीकी निर्णय कैसे करें


36

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

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

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

फिर भी मुझे डर है कि एक गलत फैसले से कंपनी को महंगा पड़ेगा। तो आपको क्या लगता है कि इस तरह के निर्णय लेने के लिए एक "आदर्श" प्रक्रिया है?


4
कहीं लिखें कि निर्णय दो दिनों में लेना लगभग असंभव है। फिर एक बहुत बुरा निर्णय लेने का प्रयास करें, और यह दस्तावेज करें कि आपका निर्णय सबसे अच्छा नहीं है। दूसरे शब्दों में, अपने गधे को कवर करें। Qt5 पर विचार किया जा सकता है। या अपने उत्पाद को एचटीएमएल 5 वेब एप्लिकेशन बनाएं (संभवतः कुछ HTTP सर्वर लाइब्रेरी का उपयोग करें जैसे कि libonion या FastCGI)
बेसाइल स्ट्राइनेकेविच

2
@ जगत् मैं सहमत नहीं हूँ, कि यह एक व्यक्तिपरक प्रश्न है, भले ही एक से अधिक संभावित उत्तर हों फिर भी हम सभी दूसरों के अनुभव से लाभ उठा सकते हैं।
Flot2011

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

5
बहुत बुरा उदाहरण क्योंकि उदाहरण के मामले में एक तकनीक है जो इसके लिए एक स्पष्ट विकल्प है - ज़ामरीन। .NET बैकएंड कोड रखें, बस यूआई को किसी चीज़ से बदलें। सभी दिए गए मामलों को संभालता है। तो, यह "I .NET के लिए क्रॉस प्लेटफॉर्म सिस्टम के बारे में कुछ नहीं जानता" का मामला है।
टॉमटॉम

7
यह कहना कि 2 दिन पर्याप्त नहीं है, बहुत रचनात्मक नहीं है। क्या 3 दिन काफी होने वाले हैं? या क्या आप वास्तव में उस पर 2 महीने बिताना चाहते हैं? और आपका निर्णय कितना बेहतर है? ~~~~ यदि आप कहते हैं कि आपको एक सप्ताह की आवश्यकता है और विश्वास है कि यह आसानी से लाइन के नीचे विकास के समय के सैकड़ों घंटे बचाने के लिए जा रहा है तो यह उल्लेख करना सुनिश्चित करें। यह मदद नहीं कर सकता है, लेकिन हमेशा संभावना है कि आपके व्यवसाय के मामले में हितधारकों की तरह।
डेनिस जहरुद्दीन 16

जवाबों:


48

यदि आपके पास प्रोटोटाइप के लिए 2 दिन और कोई समय नहीं है या यहां तक ​​कि सभी विकल्पों पर पढ़ें तो वास्तव में केवल 2 विकल्प हैं:

  1. किसी ऐसे व्यक्ति से पूछें जो उनकी सलाह को जानता हो और उसका पालन करता हो। यह जरूरी नहीं कि एक व्यक्ति से पूछ सकता है, लेकिन ब्लॉग और लेख के माध्यम से खोज करने के लिए 2 दिन बिताएं ताकि थोड़ी जानकारी से बेहतर-अनजान निर्णय लेने के लिए पर्याप्त जानकारी प्राप्त कर सकें।

  2. सभी मुख्यधारा के विकल्पों में थोड़ा शोध करें और फिर एक चुनें। कभी-कभी नेतृत्व का मतलब गलत निर्णय लेने से डरना नहीं होता है, अक्सर यह एक महत्वपूर्ण निर्णय होता है कि टीकाकरण करने की तुलना में दृढ़ निर्णय लें।

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


10
+1 के लिए "गलत निर्णय लेने से डरो मत" कभी-कभी 'विश्लेषण पक्षाघात' में फंस जाना किसी भी निर्णय को लेने से बदतर है। हम सब इंसान हैं। अपना सर्वश्रेष्ठ करें और जीवन के साथ आगे बढ़ें।
सेमाज

1
टीका लगाना: विभिन्न मतों या कार्यों के बीच वैकल्पिक या डगमगाना; अभद्र होना।
टैंकरस्मैश

10
+1 के लिए "अपने आप को आर्किटेक्चर के साथ आकर कवर करें जो अधिक डिकॉउंडेड हैं और इसलिए बदलना आसान है"
डार्थ एलीगेंट

2
@emodendroket विंडोज वर्कफ़्लो फाउंडेशन।
मेटाफ़ाइट

2
यदि आपकी समस्या मुख्य धारा नहीं है, तो मुख्यधारा के समाधानों को अच्छी तरह से काम करने की अपेक्षा न करें। यह वह जगह है जहाँ decoupling और लचीलापन महत्वपूर्ण है । उन रूपरेखाओं / पुस्तकालयों की तलाश करें, जो आपको अपनी उम्मीदों पर कुछ करने के बजाय अपनी खुद की चीजों को करने में आसान बनाते हैं, जब उन्हें यह अनुमान नहीं लगता था कि आपको क्या करने की आवश्यकता है।
jpmc26

19

ऐसा लग सकता है कि मैं स्ट्रीम के खिलाफ जा रहा हूं, लेकिन मैंने हाल ही में एड कैट्मल द्वारा क्रिएटिविटी, इंक बुक पढ़ी है और इस स्थिति से निपटने के लिए एक बहुत अच्छा पैराग्राफ था:

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

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

जाहिर है कि आप दो दिनों में किसी भी प्लेटफ़ॉर्म पर काम नहीं करेंगे, लेकिन एक ASAP को चुनने पर यह निश्चित रूप से आपको बेहतर परिप्रेक्ष्य देगा कि यह कैसे काम करता है (इसके बारे में पढ़ने की तुलना में बहुत अधिक) और आपको बेहतर उत्तर की ओर ले जाएगा।


12
हालाँकि मैं वैश्विक स्तर पर आपसे सहमत हूँ, लेकिन कभी-कभी युद्ध के मैदान में आगे बढ़ना काफी आत्मघाती होता है।
फ्लोट २०११

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

6
@ Flot2011 हालांकि अगर आपके पास एमबीए है, तो आप वहीं रहें जहां आप हैं और अपने सभी सैनिकों को पहाड़ी पर लड़ने के लिए भेजें। यदि वे सभी मर जाते हैं, तो ठीक है, आप अधिक सैनिकों को प्राप्त करते हैं और जारी रखते हैं लेकिन इस बार यह कहते हुए कि आपका अनुभव एक सामान्य के रूप में आपको बहुत अधिक बनाता है ... राक्षसी रूप से अधिक वेतन का हकदार है।
gbjbaanb

1
"एक ASAP चुनना, फिर प्रोटोटाइप" मुझे इस स्थिति में बहुत बुरी सलाह के रूप में प्रभावित करता है। हाँ, प्रोटोटाइप महत्वपूर्ण है, लेकिन समय लेने वाला भी। गैर-तुच्छ समस्याओं में अक्सर 2 से अधिक संभावित समाधान होते हैं, और 2 दिन कई प्रौद्योगिकियों के प्रोटोटाइप के लिए पर्याप्त नहीं होते हैं।
मेरिटॉन -

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

10

gbjbaanb कुछ बहुत अच्छे अंक बनाता है। मुझे लगा कि मैं थोड़ा जोड़ दूंगा।

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

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

  2. एक बड़े और सक्रिय ऑनलाइन समुदाय के साथ एक ढांचा / मंच खोजें। आखिरी चीज जो आप चाहते हैं, वह है कि एक अस्पष्ट ढांचे को अकेले डीबग करना।

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

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

सौभाग्य :)


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

हाँ, मुझे एहसास हुआ कि यह थोड़ा कठिन था इसलिए मैंने इसे संशोधित किया।
मेटाफाइट

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

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

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

5

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

ऐसी तकनीकों का चयन करें जो:

  • एक बड़ा उपयोगकर्ता आधार हो
  • सक्रिय समर्थन (जो भी चैनल हो)
  • सक्रिय रूप से विकसित हो रहे हैं

परिभाषा के अनुसार, यह किसी भी रक्तस्रावी धार तकनीक को नियंत्रित करेगा, हालांकि यह अच्छा हो सकता है।

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


हालाँकि अगर टेक्नॉलॉजी एक्स काफी अच्छा है, और फ्रेड अन्य डेवलपर्स को शिक्षित करने के लिए तैयार है, तो ऐसा करना टीम को किक-स्टार्ट करने का एक अच्छा तरीका हो सकता है।
बजे एक CVn

सुनिश्चित करने के लिए - अगर यह अन्य बक्से पर टिक करता है ...
रोबी डी

4

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

  1. लक्ष्य प्लेटफ़ॉर्म क्या हैं
  2. वर्तमान एप्लिकेशन में उपयोग किए जाने वाले कस्टम / तृतीय पक्ष घटक क्या हैं जहां इसे पोर्ट करने के लिए काफी प्रयास की आवश्यकता हो सकती है। उदाहरण के लिए: चार्ट घटक, ग्रिड घटक, रिपोर्टिंग घटक, आदि।
  3. वर्तमान एप्लिकेशन को दुनिया से कैसे जोड़ा जा रहा है और सुरक्षा को कैसे नियंत्रित किया जाता है (डेटाबेस कनेक्शन / वेब सेवाएं / आदि ...)
  4. इसे कैसे वितरित किया जाता है और कैसे अपडेट प्रदान किया जाता है

अब आपको ऐसे विकल्प खोजने की आवश्यकता है जिनका उपयोग आप सभी लक्षित वातावरणों के लिए कर सकते हैं

प्रत्येक विकल्प के लिए मौजूदा ऐप का उपयोग कर रहे कनेक्टिविटी / सुरक्षा का उपयोग करने के लिए प्रत्येक के लिए समर्थन का पता लगाएं।

तब प्रत्येक कस्टम / तीसरे पक्ष के घटकों के लिए पता चलता है कि क्या प्रत्येक के लिए विकल्पों का उपयोग करना आसान है।

और फिर सोचें कि आपके द्वारा प्राप्त प्रत्येक विकल्प के लिए वितरण कैसे किया जा सकता है।

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


4

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

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


2

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

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

इंटरनेट खोज के आधार पर अपनी समस्या के लिए तीन या चार सामान्य समाधान चुनें।

फिर इस बारे में एक अच्छा अनुमान लगाने के लिए पर्याप्त पढ़ें कि प्रत्येक विकल्प उनकी शीर्ष 3-4 प्राथमिकताओं में कितनी अच्छी तरह फिट बैठता है। प्रत्येक पसंद के लिए एक संख्यात्मक मान असाइन करें। गणित को प्रत्येक प्राथमिकता समय की रेटिंग को उस प्राथमिकता पर निर्धारित मान के अनुसार गुणा करें (संख्या १ के लिए १०, संख्या के लिए ly के लिए, संख्या ४ के लिए संख्या ३ के लिए ६ के लिए या जो आपको कभी भी सांख्यिक है)। अब आपके पास प्रत्येक संभावना के लिए एक संख्यात्मक अंक है। आम तौर पर यह स्पष्ट होगा कि कौन सी सौंपी गई प्राथमिकताओं को पूरा करता है। इससे भी बेहतर कि अब आपके पास अपनी पसंद को साबित करने के लिए उन्हें लेने के लिए कुछ विश्लेषणात्मक है। वे आमतौर पर आपकी पसंद पर खरीदारी करेंगे क्योंकि आपके पास इसका समर्थन करने के लिए नंबर हैं। यदि संख्याएँ इसका समर्थन नहीं करती हैं, तो आपको अपने आप से यह पूछने की आवश्यकता है कि आप दूसरे को क्यों पसंद करते हैं और या तो सर्वश्रेष्ठ एक के साथ जाएं या निर्दिष्ट संख्याओं को फिर से देखें।

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


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

1
एक स्प्रेडशीट में संरचना को स्थापित करने में दस मिनट से भी कम समय लगता है (सबसे जटिल हिस्सा यह तय कर रहा है कि आप किन कारकों पर प्राथमिकताओं की तुलना करना चाहते हैं) और फिर भरने में आसान है।
HLGEM

यह सचमुच उतना आसान है। हम सर्वेक्षण भी करते हैं जहां हर कोई प्रत्येक श्रेणी के लिए एक मूल्य प्रदान करता है यह निर्धारित करने के लिए कि हर कोई क्या सोचता है सबसे महत्वपूर्ण है ताकि हम प्रत्येक श्रेणी के लिए भार लागू कर सकें। आखिरकार, सॉफ्टवेयर टीम को लगता है कि प्रोसेसर की गति और मेमोरी हमेशा सर्वोच्च प्राथमिकता है, लेकिन हार्डवेयर लोगों को विपरीत राय है क्योंकि बैटरी जीवन उनके लिए महत्वपूर्ण है। बेशक, ग्राहक आम तौर पर कम से कम आधी वज़न की गणना करता है और सॉफ़्टवेयर या हार्डवेयर चिंताओं के बारे में जानकारी नहीं देता है। ऑनलाइन विवरण वास्तव में जटिल लगते हैं जब यह नहीं है।
डुंक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.