समूह निर्णय एक विशेष तरीके से विफल होते हैं: सबसे ऊँची आवाज़ ढाँचा तय करती है, वरिष्ठ लोग शर्तें तय करते हैं, और शांत सदस्य पीछे रह जाते हैं — न कि विनम्रता से, बल्कि इसलिए कि ढाँचा तय होने के बाद असहमति जताना उससे पहले जताने से अधिक महँगा पड़ता है।
परिणाम यह होता है कि टीम उस निर्णय को अपना नहीं मानती। लोग प्रतिबद्ध होने के बजाय बस पालन करते हैं, और निष्पादन चुपचाप महीनों तक पीड़ित रहता है।
प्रक्रिया के कुछ हिस्से को यादृच्छिक बनाना इसका एक हिस्सा ठीक करता है। कौन-सा हिस्सा, और कौन-सा इसे बदतर बनाता है, इस पर स्पष्ट होना उचित है।
जिन क्रियाविधियों को यह ठीक करता है
बोलने का क्रम। जिस क्रम में लोग योगदान देंगे उसे ड्रॉ करना सबसे पहले बोलने वाले के एंकरिंग प्रभाव को हटा देता है। यह सबसे मज़बूत एकल उपयोग है, और सबसे सस्ता।
चर्चा जोड़े। समूह बातचीत से पहले जोड़े ड्रॉ कीजिए। दो लोगों की बातचीत वे बातें सामने लाती है जो पूर्ण बैठक नहीं लाती — लोग एक सहकर्मी से कमरे से अधिक कहते हैं, और शांत व्यक्ति जोड़े में स्पष्ट रूप से अधिक खुलता है।
कौन रिपोर्ट करेगा। परिणाम प्रस्तुत करने वाले व्यक्ति को ड्रॉ करना सबको दृश्यमान होने का समान अवसर देता है, और यह सवाल हटा देता है कि प्रस्तुत करने के लिए किसे चुना गया।
सुविधा या नोट-टेकिंग। छोटी भूमिकाएँ, बारी-बारी। जो व्यक्ति सुविधा दे रहा है वह वह भी नहीं हो सकता जिसकी सबसे मज़बूत राय हो, जो पक्षपाती चर्चा का सबसे आम स्रोत हटा देता है।
वास्तव में मनमाने चुनाव। कौन-सा मीटिंग स्लॉट, दो समान रूप से अच्छे विकल्पों में से कौन-सा, तीन उम्मीदवारों में से पहले किसे आगे बढ़ाएँ। ये असली हैं और लगातार आते रहते हैं।
विफलता के प्रकार
यह उस निर्णय के लिए सहभागिता नहीं बनाता जिसे लोगों को प्रभावित करना चाहिए था।
यह महत्वपूर्ण बात है। यदि निर्णय के लिए वास्तविक इनपुट चाहिए था और आपने उसे बनाने के लिए एक व्यक्ति को ड्रॉ किया, तो आपने इनपुट हटा दिया और असहमति रख ली। अब टीम ऐसे निर्णय का पालन कर रही है जिसे उसने आकार नहीं दिया, और उसका निष्पादन ठीक वैसा ही होगा जैसी आप अपेक्षा करेंगे — यानी न्यूनतम।
यादृच्छिक चयन यह ठीक करता है कि बारी किसकी है। यह यह ठीक नहीं करता कि क्या तय होगा।
यह लग सकता है कि निर्णय पहले ही लिया जा चुका है।
यह बात सुविधा-संचालन में अच्छी तरह दर्ज है। यदि कोई नेता उस प्रश्न पर बोलने वाले को ड्रॉ करता है जिसका उत्तर वह पहले ही तय कर चुका है, तो ड्रॉ नाटक जैसा लगता है, और टीम का वैसा समझना सही है। जिस निर्णय को आप पहले ही ले चुके हैं, उसमें भागीदारी को यादृच्छिक बनाना उससे बदतर है कि आप कोशिश ही न करें।
जाँच सरल है: यदि परिणाम बदल नहीं सकता, तो उस पर ड्रॉ न चलाएँ। आपने जो तय किया और क्यों, वह कह दें, या सच में पूछें।
यह आरोप जैसा लग सकता है।
किसी शांत व्यक्ति को वरिष्ठ सहकर्मियों के सामने बोलने के लिए ड्रॉ करना भागीदारी नहीं, बल्कि सामने लाना है। अधिकांश लोग इसे ऐसी स्पॉटलाइट की तरह अनुभव करते हैं जिसके लिए उन्होंने सहमति नहीं दी। हर हफ्ते करने पर यह अधिक आत्मविश्वासी योगदानकर्ता नहीं, बल्कि अधिक अनुपस्थिति पैदा करेगा।
जहाँ यह मायने रखता है — एक नया टीम सदस्य, हकलाने वाला कोई, कोई जो पिछली मीटिंग में जला है — उन्हें पहले कुछ राउंड के लिए बाहर रखें।
बिना नुकसान पहुँचाए इसे कैसे करें
बोलने के क्रम को निर्णय के अधिकारों से अलग रखें। ड्रॉ कीजिए कि कौन बोलेगा; तय कीजिए कि कौन निर्णय लेगा। इन्हें मिलाना ही आरोप की समस्या पैदा करता है।
ड्रॉ से पहले दाँव स्पष्ट रखें। “प्रतिबद्ध होने से पहले मुझे इस पर सबकी राय चाहिए” ड्रॉ को एक ईमानदार प्रक्रिया बनाता है। “चलिए निर्णय के लिए किसी यादृच्छिक व्यक्ति को चुनते हैं” यह स्पष्ट कर देता है कि आप इसे सुलझाना चाहते हैं, चर्चा नहीं।
ड्रॉ किए गए व्यक्ति को निकलने का रास्ता दें। “अगर आप न चाहें तो पास कर दें” — सबको दिया जाए, किसी नामित व्यक्ति को नहीं। यह क्रियाविधि बनाए रखते हुए सामने आने का जोखिम हटा देता है।
छोटी-छोटी बातों के लिए बार-बार ड्रॉ न करें। यह एक नौटंकी बन जाता है और फिर झुंझलाहट। इसका उपयोग वहाँ करें जहाँ निष्पक्षता का तर्क असली हो: प्रस्तुति क्रम, रिपोर्टिंग, नोट-टेकिंग।
परिणाम असुविधाजनक होने पर कभी दोबारा न चलाएँ। जिस क्षण टीम ड्रॉ दोबारा चलते हुए देखती है, हर भावी ड्रॉ को परक्राम्य माना जाता है। यह इस साइट पर हर जगह वही नियम है, और समूह में यह अधिक मायने रखता है क्योंकि पूरी टीम देख रही होती है।
यह कहाँ लाभदायक नहीं है
हर वह चीज़ जिसके लिए विषय-ज्ञान चाहिए। यह यादृच्छिक बनाना कि कौन-सा इंजीनियर डेटाबेस माइग्रेशन का आकलन करेगा, गारंटी देता है कि कभी-कभी आप गलत व्यक्ति चुनेंगे।
वे निर्णय जिनके साथ लोग महीनों तक जिएँगे। ड्रॉ किया गया निर्णय पालन पाता है। जिस निर्णय को लोगों ने बनाने में मदद की, वह प्रतिबद्धता पाता है। यदि परिणाम एक साल तक मायने रखता है, तो उसे संयोग पर न छोड़ें।
संस्कृति-अनुकूलता और भर्ती। यादृच्छिक चयन यह आँक नहीं सकता कि कोई टीम में फिट बैठेगा या नहीं, और ऐसा मानना निष्पक्षता का तर्क नहीं है — यह दावा है कि एक मूल्यवान निर्णय महत्वहीन है।
हर वह चीज़ जिसका श्रेय आप चाहते हैं। यदि आप वह व्यक्ति दिखना चाहते हैं जिसने अच्छा निर्णय लिया, तो ड्रॉ वह अवसर छीन लेता है।
व्यवहार में यह कैसा दिखता है
एक स्टैंडअप जहाँ बोलने का क्रम ड्रॉ करना वास्तव में मदद करता है: पहला व्यक्ति बाधाएँ बताता है, और बाकी सब प्रतीक्षा करते हैं बजाय यह मान लेने के कि उनकी अपनी ठीक हैं।
एक योजना सत्र जहाँ यह मदद नहीं करता: “कौन इसे क्लाइंट के सामने प्रस्तुत करना चाहता है?” और फिर एक ड्रॉ, जब कई लोगों की राय है कि किसे करना चाहिए।
अंतर यह है कि निष्पक्षता का तर्क असली है या आप एक निर्णय टालने के लिए किसी क्रियाविधि का उपयोग कर रहे हैं।
इसके पीछे क्या है
ड्रॉ Math.random() के बजाय ब्राउज़र के क्रिप्टोग्राफ़िक रैंडम स्रोत का उपयोग करते हैं, जो नियतात्मक है और सिद्धांत रूप में परिणामों का अनुमान लगाने के लिए पुनर्निर्मित किया जा सकता है। क्रम के ड्रॉ बस ड्रॉ हैं — समूह वे लोग हैं जो मीटिंग में हैं।
यहाँ कुछ भी खाते की माँग नहीं करता, और कोई दैनिक सीमा नहीं है।
बोलने के क्रम से शुरू करें
अपनी अगली मीटिंग लीजिए और उस क्रम को ड्रॉ कीजिए जिसमें लोग अपना अपडेट साझा करेंगे। पहले घोषित कीजिए, ताकि क्रियाविधि दिखाई दे।
फिर अगली कुछ मीटिंग्स में कुछ नोटिस कीजिए: बाधाएँ आखिरी दो मिनट के बजाय पहले तीस सेकंड में सामने आने लगती हैं। यही पूरा लाभ है, और यह सुनने से बड़ा है।