- सिस्टम या प्रोडक्ट को समझने वाले मेंटल मॉडल को दूसरे लोगों तक पहुँचाने और मिलकर विकसित करने में कौन-से टूल और तकनीकें प्रभावी हैं, यह पूछने वाला प्रश्न है
- मेंटल मॉडल विकसित करने के एक तरीके के रूप में सिस्टम को सीधे बनाना और उसका मेंटेनेंस करना जैसी अनुभवजन्य प्रक्रिया का उल्लेख है
- इसे साझा करने का तरीका नैपकिन पर स्केच बनाना, बगल में खड़े होकर इशारों से समझाना, साथ में सोचते हुए बोलकर समझाना जैसी अनौपचारिक व्याख्या के अधिक करीब है
- फीचर लिस्ट या सतही दायरे को बिना छोड़े व्यवस्थित करने वाले दस्तावेज़ व्यापक हो सकते हैं, लेकिन विषय का मेंटल मॉडल बनाने या साझा करने के लिए वे पर्याप्त नहीं भी हो सकते
- अच्छी तरह डिज़ाइन किए गए टूल या प्रोडक्ट को सीधे इस्तेमाल करने का अनुभव, मेंटल मॉडल को विकसित करने और साझा करने की प्रक्रिया दोनों में एक साथ मदद कर सकता है
प्रश्न का फोकस
- कौन-से टूल या तकनीकें मेंटल मॉडल को साझा करने और विकसित करने में प्रभावी हैं, यही मुख्य बात है
- प्रश्न दो दिशाओं को साथ में देखता है
- मेंटल मॉडल को विकसित करने के तरीके
- मेंटल मॉडल को दूसरे लोगों तक पहुंचाने के तरीके
उदाहरण और समस्या-बोध
- मेंटल मॉडल विकसित करने के उदाहरण के रूप में सिस्टम बनाना और उसका मेंटेनेंस करना सामने आता है
- मेंटल मॉडल साझा करने का तरीका नीचे की तरह काम के दौरान साथ में समझ बनाने वाला है
- नैपकिन पर स्केच बनाना
- बगल में खड़े होकर इशारों से समझाना
- साथ में सोचने की स्थिति में समझाना
- फीचर्स को सूचीबद्ध करने या सतही स्कोप को कैटलॉग करने वाले दस्तावेज़ व्यापक हो सकते हैं
- लेकिन ऐसे दस्तावेज़ उस विषय का मेंटल मॉडल बनाने या साझा करने तक ज़रूरी नहीं कि पहुँचें
- अच्छी तरह डिज़ाइन किए गए टूल या प्रोडक्ट को सीधे इस्तेमाल करने का अनुभव मेंटल मॉडल की वृद्धि और उसके साझा होने, दोनों को हासिल करने का एक तरीका माना गया है
- आख़िरी सवाल यह है कि लोगों को कौन-से टूल और तकनीकें प्रभावी लगीं, और वे क्यों प्रभावी रहीं
1 टिप्पणियां
Lobste.rs की राय
ओन्टोलॉजी लॉग, ओन्टोलॉजी को संप्रेषित करने के लिए एक अच्छा formalism है
अगर कोई long-running process है जिसमें बहुत सारी internal state होती है, तो state diagrams और state charts सिस्टम documentation के लिए उपयोगी होते हैं
सिस्टम users आम तौर पर वास्तविक सिस्टम संरचना को नहीं समझ पाते। एक वजह यह है कि Nakatomi space केवल उन users को दिखता है जो सिस्टम का दुरुपयोग करते हैं, और weird machines जैसे अनपेक्षित व्यवहारों के लिए state space के अलग क्षेत्र होते हैं
एक और वजह यह है कि the purpose of a system is what it does वाले दृष्टिकोण की तरह, user केवल यह देखकर कि सिस्टम उसके लिए क्या करता है, उसका अपना निजी कारण-ए-वजूद बना सकता है, लेकिन designers और maintainers द्वारा सोचा गया पूरा उद्देश्य शायद न समझ पाए
किताब लिखिए, और एक editor hire कर लीजिए
मुझे लगता है यह शिक्षा की मुख्य समस्या के काफी करीब है। दो categories बताई गईं: करके सीखना और expert guidance; तीसरी है सिखाना
ज्यादा अहम सवाल यह है कि क्या हम ऐसे models बना सकते हैं जिन्हें समान principles और designs reuse करते हुए आसानी से सीखा जा सके, या abstraction के जरिए उन्हें पूरी तरह सीखने की जरूरत कम की जा सके। हालांकि abstraction कहां leak करता है, यह अच्छी तरह defined होना चाहिए
इस संदर्भ में Felienne Hermans की The Programmer's Brain दिलचस्प है। छोटे बच्चों को गणित आदि सिखाते समय “मैं कई examples हल करके दिखाऊंगा, तुम देखो” वाला तरीका programming education में भी काफी अच्छा काम करता है—यह बात प्रभावशाली लगी
काम के माहौल में onboarding हो तो यह “देखो मैं इस bug की जांच कैसे करता हूं” या “देखो मैं इस subsystem को, जिसे लंबे समय से नहीं छुआ, फिर से कैसे समझता हूं” जैसा हो सकता है
software engineering में mental model को user stories और technical implementation में बांटकर देखना मददगार होता है
आम तौर पर user story primary requirement होती है, यानी वह value जिसे हासिल करना है, और technical implementation उस लक्ष्य को पाने के लिए जरूरी secondary elements होते हैं
user story customer को दी जाने वाली value समझाती है, और technical implementation यह बताता है कि बने हुए system की constraints user story को कैसे सीमित करती हैं
कभी-कभी दोनों overlap करते हैं, जिससे user story technical implementation से constrained हो जाती है, या उलटे user story हासिल करने के लिए technical implementation चुना जाता है। लेकिन system के बहुत सारे behavior को इनमें से किसी एक frame में रखा जा सकता है
इसके बाद सबसे उपयुक्त tool चुनना होता है। UML objects का map बनाने के लिए अच्छा है, और flowchart flows समझाने के लिए। state diagrams allowed/disallowed states और transitions समझाने के लिए अच्छे हैं, और variables व state tables सभी possible values enumerate करने के लिए अच्छे हैं
सिस्टम को चित्रित करना सीखने का सबसे अच्छा तरीका है कि तीन अलग-अलग लोगों से कहें कि वे अपनी-अपनी सोच के हिसाब से diagram बनाएं। एक ही विचार को व्यक्त करने के तरीके हैरान करने वाली हद तक विविध होते हैं, और ज्यादातर उतने ही valid होते हैं, लेकिन विषय के अलग-अलग पहलू दिखाते हैं। यह कला जैसा है
मैं मुख्यतः ज्यादा formal diagramming इस्तेमाल करता हूं। फिर भी screen sharing के दौरान real-time में scribble करना हो तो कभी-कभी jspaint खोल लेता हूं, और अगर बाद में दूसरों के देखने लायक चीज हो तो Figjam जैसी चीजें भी इस्तेमाल करता हूं
diagramming और pointing इसलिए अच्छी तरह काम करते हैं क्योंकि ये हमारे सबसे पुराने और अभी भी उपयोगी attention-directing tools हैं। बोलने से पहले ही हम इशारा करते और रोते हैं, और location व navigation में pointing, भाषा से कहीं ज्यादा immediate है, इसलिए laser pointer market अब भी बना हुआ है
Peter Gårdenfors की The Geometry of Meaning: Semantics of Conceptual Spaces इस विषय को काफी विस्तार से कवर करती है। Barbara Tversky ने भी diagramming और cognitive space structuring पर काफी research की है, और Peter Cheng का “What Constitutes an Effective Representation?” effective representation के criteria को काफी quantitative रूप में पेश करता है
shadowing, pairing, और whiteboard sessions अच्छे हैं। इसमें दोनों पक्षों को draw भी करना चाहिए और सवाल भी पूछने चाहिए
model को expand या change करने वाला project साथ में चुनना और execute करना, quizzes, learner से फिर से सिखवाना, memorization और हाथ से लिखकर देखना जैसे तरीके भी हैं
simple memorization को हमेशा दूसरे तरीकों के साथ इस्तेमाल करना चाहिए, और उसे अकेला तरीका नहीं बनने देना चाहिए। whiteboard के बाहर diagramming या scribbling, दूसरे models/solutions से तुलना करने वाला gap analysis, और hammock time जैसी contemplative, आधी-अचेतन reflection भी मदद करती है
मुझे लगता है कि communication के लिए representation और असली task execution के लिए representation में फर्क करना चाहिए। बाद वाला यहां mention नहीं हुआ, लेकिन “execution” के ज्यादा करीब है
executable models में अक्सर communication power कम होती है, और आम तौर पर वजह खराब abstraction boundaries होती हैं। computing में यह लगभग हमेशा leaking abstraction होता है
कोई चीज क्या करती है यह समझना, उसे efficient बनाने के लिए लगे प्रयासों के पहाड़ के पीछे छिप सकता है। इसलिए napkin पर scribble करते हुए यह समझाने की जरूरत पड़ती है कि “तुम्हारे मौजूदा mental model के हिसाब से abstraction के इस level पर यह system ऐसे काम करता है”
documentation एक अलग deliverable है, इसलिए वह execution model से पीछे रह जाने की प्रवृत्ति रखती है, और इसे रोकने के लिए उसे बहुत मेहनत से maintain करना पड़ता है। और मुश्किल तरीका है documentation को सीधे code से जोड़ना, या literate programming की तरह documentation को code से पहले रखना
इसलिए mental model communicate करते समय आम तौर पर वही तरीका सही होता है जिसमें effort और maintenance कम से कम लगे: यानी napkin scribbles और समय के साथ actual system पर साथ काम करना
नए लोग design document लिखने के बजाय आसान bug fixes से शुरू करते हैं, इसकी वजह होती है
नए लोगों को करके सीखना होता है, इसलिए tutorial सबसे उपयुक्त हो सकता है। लेकिन कुछ समय हाथ लगाने के बाद उनमें कुछ गलतफहमियां मिली होने की संभावना ज्यादा होती है, और napkin scribble पर explanation से उन्हें सुलझाया जा सकता है
इसलिए अगर tutorial लिखने का फैसला किया है, तो “सब कुछ” वाला document बनाने की कोशिश न करें; साफ focus वाला अच्छा tutorial लिखें
लेखन ही जवाब है
software निजी dynamic medium है, इसलिए यह काफी दिलचस्प है
मुझे लगता है interactive systems मदद करते हैं। उदाहरण के लिए Python और boxed variables सिखाने वाला visual debugger जैसा कुछ