दूसरी स्लाइड से शुरू होने वाली प्रेज़ेंटेशन
(tidyfirst.substack.com)- टेक्निकल प्रेज़ेंटेशन में बैकग्राउंड समझाना ज़रूरी होता है, लेकिन शुरुआत में श्रोता आसानी से छूट सकते हैं, इसलिए पहले समस्या की स्थिति दिखाकर बाद में संदर्भ भरना अधिक प्रभावी होता है
- यह तकनीक Lawrence Block की writing advice की तरह है, जिसमें स्वाभाविक रूप से लिखे गए पहले हिस्से और दूसरे हिस्से की जगह बदलकर तनाव वाला दृश्य आगे रखा जाता है
- बैकग्राउंड पहले समझाने वाली प्रेज़ेंटेशन, जो लोग पहले से जानते हैं उनके लिए दोहराव बन जाती है, और जो नहीं जानते उनके लिए अभी सुनते रहने की पर्याप्त वजह नहीं बनती, इसलिए ध्यान कम हो सकता है
- JIT आधारित virtual machine optimization के उदाहरण में पहले performance profile, सुधार जैसा दिखने वाला code change, और वास्तव में और धीमा हो गया data दिखाया जाता है, उसके बाद JIT·optimization·architecture समझाए जाते हैं
- शुरुआत में हल करने के लिए समस्या रख दी जाए तो programmer स्वाभाविक रूप से समाधान खोजने लगते हैं, और उसके बाद की व्याख्या को follow करने की प्रेरणा बनती है
समस्या को पहले दिखाने वाली प्रेज़ेंटेशन संरचना
- टेक्निकल प्रेज़ेंटेशन में आम तौर पर context सेट करना और हल की जाने वाली समस्या बताना, दोनों ज़रूरी होते हैं
- लेकिन अगर शुरुआत बैकग्राउंड से हो, तो प्रेज़ेंटेशन के शुरुआती हिस्से की खींच कमज़ोर हो जाती है
- जिन श्रोताओं को बैकग्राउंड पहले से पता है, उनके लिए यह दोहराई गई जानकारी बन जाती है
- जिन श्रोताओं को बैकग्राउंड नहीं पता, उनके लिए अभी समझने की प्रेरणा पैदा नहीं होती
- Kent Beck का तरीका है कि प्रेज़ेंटेशन material को पहले मनचाहे क्रम में बनाया जाए, फिर पहली दो slides, paragraphs, या chapters की जगह आपस में बदल दी जाए
- यह Lawrence Block की Telling Lies for Fun and Profit से लिया गया तरीका है
- कहानी को स्वाभाविक रूप से लिखा जाए तो पहला chapter नायक का परिचय होता है, दूसरा chapter घटना को आगे बढ़ाता है
- दोनों chapters बदल देने पर शुरुआत नायक के ख़तरे में होने वाले दृश्य से होती है
- तनाव बनने के बाद जब पात्र का परिचय आता है, तो पाठक के पास उसे जानना चाहने की वजह होती है
JIT optimization प्रेज़ेंटेशन का उदाहरण और श्रोताओं की प्रतिक्रिया
- अगर विषय JIT compile करने वाली virtual machine optimization प्रेज़ेंटेशन हो, तो सामान्यतः पहले JITing, performance tuning की बुनियादी Pareto अवधारणा, और मौजूदा machine architecture का परिचय दिया जाता है
- लेकिन hotspot कम करने वाली सामान्य optimization पूरी performance को और धीमा बना सकती है, और देखने में मामूली लगने वाला बदलाव बड़ा सुधार भी ला सकता है
- दूसरी स्लाइड से शुरू होने वाली संरचना पहली स्लाइड पर ही निर्णय के लिए ज़रूरी सामग्री रख देती है
- hotspot दिखाने वाला performance profile
- ऐसा code change जो बेहतर लगता है
- ऐसा data जो दिखाता है कि optimization न सिर्फ़ विफल हुई, बल्कि system को और धीमा कर दिया
- उसके बाद JIT, optimization, और architecture की व्याख्या जोड़ दी जाए, तो बैकग्राउंड जानने वाले श्रोता भी रहस्य के उत्तर का इंतज़ार करते हुए साथ बने रहते हैं, और बैकग्राउंड न जानने वाले श्रोताओं के पास भी ध्यान देने की वजह बनती है
- programmer के सामने समस्या रखी जाए तो वे स्वाभाविक रूप से उसे हल करने वाली engineering प्रतिक्रिया दिखाते हैं, इसलिए प्रेज़ेंटेशन की शुरुआत में साथ मिलकर हल करने वाला प्रश्न रखना प्रभावी होता है
1 टिप्पणियां
Hacker News राय
कुछ हफ्ते पहले PyCon में प्रस्तुति देते समय समय सीमा में सामग्री फिट करने के लिए काफी जूझना पड़ा, और आखिर में शुरुआती कुछ मिनटों वाला introduction काट दिया
विषय तक धीरे-धीरे पहुंचने और यह पृष्ठभूमि बताने वाला हिस्सा हटा दिया कि मैं इस बारे में बोलने के योग्य क्यों हूं, और सीधे पहले मुख्य point पर चला गया; उसमें एक अच्छा मजाक था, इसलिए वह खूब चला
मैंने सीखा कि अगर विषय पर्याप्त दिलचस्प हो, तो introduction छोड़कर सीधे मुद्दे पर आया जा सकता है, और बीच में मजाक डालने से audience का ध्यान काफी हद तक पकड़ा जा सकता है
मुझे ऐसे sales pitch बहुत नापसंद हैं जो पहले कंपनी का इतिहास सुनाते हैं, और अजीब बात है कि जापान की बड़ी कंपनियां अक्सर इस मामले में खास तौर पर सबसे खराब होती हैं
हर slide के लिए यह सोचना चाहिए कि “अगर अगले slide को पढ़ने की वजह नहीं दी, तो audience उठकर चली जाएगी”
अगर उन्हें अभी यह पता ही नहीं है कि मैं क्या offer कर रहा हूं, तो presenter के अस्तित्व को justify करने की जरूरत नहीं है; आखिर में असली बात presenter नहीं, बल्कि सुनने वाले हैं
उन हिस्सों में बहुत अटकना मुश्किल होता है, और उसी दौरान शरीर खुल जाता है और आप असली presentation में जा सकते हैं
बेशक, जितना छोटा हो उतना अच्छा, इसलिए मैं शुरुआती वाक्यों को शब्द-दर-शब्द याद कर लेता हूं
जब सबसे ज्यादा घबराहट हो, तब भी शुरुआती हिस्सा पक्का हो जाता है, और उसके बाद अधिक स्वतंत्र रूप से बोल सकता हूं
करीब 30 सेकंड ठीक है, लेकिन कई मिनट बहुत लंबे हैं; चाहे presentation हो या YouTube video, बात वही है
मैं समझता हूं कि लोग ऐसा क्यों करते हैं
शायद वे “क्या यह व्यक्ति योग्य है?” या “मुझे context नहीं समझ आ रहा” जैसे risks घटाना चाहते हैं, लेकिन थोड़ी हिम्मत करके सीधे मुख्य बात पर आना अच्छा होगा
मैं पहले ही वह talk सुनने का चुनाव कर चुका हूं, इसलिए यह समझाना कि यह क्यों दिलचस्प है, पहले से विश्वास करने वालों को उपदेश देने जैसा है
hacker culture में आम तौर पर credentials से ज्यादा skill से लोगों का आकलन होता है, इसलिए “वैसे, यह मैंने बनाया है” जैसा कुछ जोड़ा जा सकता है, लेकिन अपना resume पढ़कर न सुनाएं; insights से मनाएं
यह हर context में सही नहीं है; कुछ audiences qualification को बहुत महत्व देती हैं
अगर लोगों ने खुद वह talk नहीं चुना है, तो पर्याप्त context भी चाहिए
फिर भी ज्यादातर मामलों में पहले interest पकड़ना, और interest मिल जाने के बाद introduction पर लौटना बेहतर होता है
graduate school में मुझे presentation की काफी training मिली, और मेरे advisor rehearsal के दौरान अक्सर quiz की तरह practice करवाते थे
पहला slide उस जगह की तरह समझना चाहिए जिसे तब थोड़ी देर दिखाया जाता है जब आप बोल नहीं रहे हों—किताब के cover जैसा
उदाहरण के लिए अगर moderator कहे, “अगले speaker BlahBlah पर बात करेंगे,” तो जवाब होता, “धन्यवाद SoAndSo. मैं Godelski हूं और अगला slide BlahBlah पर बात करूंगा”
उल्टा, अगर वह कहे, “अगले speaker Godelski हैं और वे BlahBlah पर अपना काम प्रस्तुत करेंगे,” तो “धन्यवाद SoAndSo. अगला slide” कहकर आगे बढ़ जाते
introduction न होने तक कई variants हैं, लेकिन मुख्य बात यह है कि परिचय कराने वाले ने जो जानकारी पहले ही दे दी है उसे repeat न करें और title slide से जल्दी निकल जाएं
वह slide सिर्फ यह दिखाने की जगह है कि कौन बोल रहा है और किस बारे में बोल रहा है; अगर audience को और जानकारी देनी है, तो उस slide पर रुके नहीं रहना चाहिए
slide structure और organization में और भी कई बातें हैं, लेकिन उन्हें generalize करना मुश्किल है; हालांकि मुझे लगता है कि outline slide काफी उपयोगी होता है, भले ही वह 1 सेकंड से कम दिखे
जब slides online डाले जाते हैं, तब यह और भी महत्वपूर्ण हो जाता है
presentation slides बोलने में सहायक के तौर पर बनाए जाते हैं, इसलिए online डालने पर वे अच्छी तरह fit नहीं होते, और अच्छा होगा अगर slide notes आसानी से शामिल किए जा सकें
Google Slides में यह ठीक है, लेकिन PDF में मुश्किल है, और beamer में यह शायद पहले से संभव है या संभव लगता है, इसलिए कोई नई practice आगे बढ़ा सकता है
मेरी technical presentations काफी लोकप्रिय हैं, और जिन non-technical लोगों को विषय में interest नहीं होता, वे भी कंपनी के अंदर slides share करके देखते हैं
story structure ही core है, और story न हो तो presentation रोचक नहीं हो सकती
presentation बनाते समय मैं slides को लगातार देखता रहता हूं कि story flow natural है या नहीं
presentation के दौरान मैं बहुत सारी जानकारी एक साथ screen पर नहीं आने देता, और PowerPoint timeline का इस्तेमाल करता हूं ताकि मेरे बोलते समय slide धीरे-धीरे बनता जाए
इसे लगभग whiteboard इस्तेमाल करने जैसा दिखाता हूं, और slide बदलते ही text की दीवार उछलकर आ जाए, यह किसी को पसंद नहीं होता
मैं केवल text वाले slides से बचता हूं ऐसा नहीं है, लेकिन वे मेरी story या concept समझाने का सबसे अच्छा तरीका शायद ही कभी होते हैं, इसलिए लगभग इस्तेमाल नहीं करता
presentation बनाते समय मैं यह भी लगातार पढ़कर देखता हूं कि वह बहुत technical होकर उबाऊ तो नहीं हो रहा, या बहुत non-technical होकर उबाऊ तो नहीं हो रहा
balance अहम है; अगर अचानक बहुत गहराई में technical जाना पड़े, तो अगले कुछ slides में फिर ऊपर लाना चाहिए, और इसका उल्टा भी उतना ही सही है
text कम होने पर भी मैं hand-drawn visualizations बहुत इस्तेमाल करता हूं ताकि concepts ठीक से समझा सकूं, इसलिए print करने पर भी वे समझ में आते हैं और जरूरी बातें convey करते हैं
अंत में, कौन-सा app इस्तेमाल करते हैं यह महत्वपूर्ण नहीं है
खराब artist अपने tools को दोष देता है, और मैं PowerPoint इस्तेमाल करता हूं, क्योंकि इसमें iPad Pencil support और पूरी animation timeline है, जिसे अच्छे से इस्तेमाल करें तो लगभग फिल्म बनाने जैसा हो जाता है
हालांकि मैं इसे मुख्यतः slides को छोटे-छोटे हिस्सों में बांटने के लिए इस्तेमाल करता हूं
तकनीकी प्रेज़ेंटेशन हमेशा स्पॉइलर से शुरू होते हैं
जो लोग व्यस्त हैं, या बस मेरी बात पर भरोसा कर सकते हैं, वे सबसे अहम जानकारी लेकर लगभग तुरंत जा सकते हैं
जो लोग सहमत नहीं हैं, या दावे के सबूत देखना चाहते हैं, वे आगे जुड़े रह सकते हैं
यह अभिव्यक्ति मेमो या ईमेल में ज़्यादा इस्तेमाल होती है, लेकिन concept वही है
अगर आप पहले बता दें कि अंत में क्या है, तो लोग समझते हैं कि background explanation किस दिशा में जा रही है
कहानी की रीढ़ इस्तेमाल करना भी ठीक है, लेकिन अगर आपको audience को यह विश्वास दिलाना है कि इंद्रधनुष के अंत में explosion scene है, तो पहले trailer दिखाना होगा
audience से reward “कमवाने” की ज़रूरत नहीं; सीधे अच्छे हिस्से पर जाएँ, और जो interested हों उनके लिए बाकी explain कर दें
कई demo reviews से निकली बात भी यहाँ है: https://web.archive.org/web/20220126051034/https://www.secon...
summary से शुरू करता हूँ, और जहाँ ठीक लगे वहाँ copy-paste किया जा सकने वाला पूरा reusable code भी पहले ही रख देता हूँ
मैं दूसरों से जिस तरह की चीज़ चाहता हूँ, इसलिए खुद भी वैसा ही करता हूँ
ego को एक तरफ रखकर usefulness को प्राथमिकता देनी चाहिए
इससे पहले ही बता दिया जाता है कि लोगों को परवाह क्यों करनी चाहिए, और कम दिलचस्प बातें पीछे चली जाती हैं, इसलिए समय खत्म हो जाए या कोई ध्यान खो दे तो भी बहुत कुछ miss नहीं होता
[1] https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism)
इसे प्रेज़ेंटेशन वाला “I’m okay, the bull is dead” माना जा सकता है
https://www.computerworld.com/article/1702433/i-m-ok-the-bul...
ऐसी situation में कोई व्यक्ति घबराहट में साफ़-साफ़ explain न कर पाए, यह समझ में आता है, लेकिन यहाँ वैसा मामला नहीं लगता
अगर आप शांत हैं, तो सामने वाले के लिए पहले 10–15 सेकंड की explanation दे देना बेहतर है कि क्या हुआ
conclusion और impact पहले बताइए, और उस घटना तक पहुँचाने वाला background बाद में भर दीजिए
तकनीकी प्रेज़ेंटेशन में अब भी कहानी चाहिए
standard storytelling technique की तरह, शुरुआत किसी ध्यान खींचने वाली घटना, यानी inciting incident से होनी चाहिए
The Matrix की शुरुआत Trinity के पकड़े जाने से ठीक पहले होती है, Bambi में माँ को गोली लगती है, और Star Wars में एक छोटा जहाज़ laser चलाते विशाल जहाज़ से पीछा छुड़ाता दिखता है
अच्छा technical presentation अच्छी story structure follow करता है
क्रम होता है: inciting incident, छोटे climax तक build-up, थोड़ी देर पीछे हटना, climax, conclusion
अगर आप बेहतरीन technical presenter बनना चाहते हैं, तो अच्छी कहानी कहने के तरीके पर किताबें पढ़ना अच्छा होगा
उदाहरण के लिए, “David किसी देहाती इलाके में तीन कमरों वाले घर में अपने कुत्तों boopy और bloppy के साथ रहता है...” से शुरू होने वाले बहुत लंबे articles मैं तुरंत बंद कर देता हूँ
पहले मैंने एक comedian द्वारा चलाया गया शानदार presentation class लिया था, और सबसे याद रहने वाली सलाह यह थी कि presentation को hero’s journey की तरह structure करो
यह structure सब जानते हैं: सब अच्छा है, tragedy आती है, problem overcome होती है, celebration होता है
आपको लग सकता है कि यह technical presentation में fit नहीं होता, और हर presentation में इसकी ज़रूरत भी नहीं, लेकिन यह उम्मीद से कहीं ज़्यादा बार लागू हो सकता है
मूल रूप से किसी problem को solve करने वाली लगभग हर चीज़ को इस तरह बताया जा सकता है
लेकिन बहुत सारे presentations “मैं X project के बारे में बात करूँगा। यह slide overview है। तो, X क्या है?” से शुरू होते हैं
इसके बजाय आप कह सकते हैं, “हमारे पास Y करने वाली बहुत-सी चीज़ें थीं। Z आने तक सब ठीक चल रहा था। फिर disaster आया। मौजूदा solution A इस case में बिल्कुल काम नहीं आया। इसलिए हमने X बनाया। लेकिन ... की वजह से यह नहीं चला, इसलिए हमें ... करना पड़ा, और आखिरकार सब काम करने लगा”
मैं पहली slide को बिना text वाली image से शुरू करने की सलाह देता हूँ
वह image बिना नंबर वाली title slide पर मौजूद presentation topic से देखने में बिल्कुल असंबंधित होनी चाहिए
तब लोग curious होते हैं कि आप क्या explanation देंगे, और ध्यान देते हैं
पहेली सुलझाने के बाद second slide पर जाएँ, problem definition या research question पेश करें, और उसके बाद सामान्य structure—overview, methods, data, experiments, evaluation results, discussion और limitations, summary, conclusion और future work—पर जा सकते हैं
लेकिन यह सिर्फ oral presentation में काम करता है
बड़ी global companies में mainstream एक और अहम slide deck type, PowerPoint presentation और Word document के मिश्रण जैसा होता है
slides text से भरी होती हैं ताकि सिर्फ deck देखकर भी समझ आ जाए, और वे केवल presentation के लिए नहीं, बल्कि मुख्यतः email से circulate होकर पढ़े जाने के लिए बनाई जाती हैं
executives presentation सुने बिना सिर्फ slides skim कर सकते हैं, इसलिए अच्छी presentation को support करने वाली अच्छी slides के कुछ rules जानबूझकर तोड़े जाते हैं
कम-से-कम मेरे field, यानी computer vision और machine learning, में पहले page पर एक बड़ा, शानदार और जहाँ हो सके self-explanatory figure रखा जाता है
यह PDF skim कर रहे व्यक्ति का ध्यान पकड़ने और उसे खींचने का काम करता है
computer vision में आम तौर पर 3D reconstruction या object detection highlight की हुई image जैसी visually appealing चीज़ मिल जाती है
या आप ऐसा graph इस्तेमाल कर सकते हैं जो दिखाए कि आपकी method baseline से कितनी बेहतर है, लेकिन जिसे numbers का meaning ठीक से न पता हो, उसके लिए यह कम interesting हो सकता है
डेमो में मैंने बहुत पहले अच्छे हिस्से से शुरू करना सीखा था
अगर आपके पास शानदार monitoring software है, तो installation process, metric collection setup, और frontend को time-series database से जोड़ने की प्रक्रिया से शुरू करके फिर वे शानदार graphs नहीं दिखाने चाहिए जो पहले मौजूद नहीं थे
इसके बजाय पहले वे शानदार graphs दिखाने चाहिए जो पहले मौजूद नहीं थे, और समझाना चाहिए कि वे graphs उपयोगी क्यों हैं
फिर, जब सबकी दिलचस्पी बन जाए, तभी समय लगाकर दिखा सकते हैं कि उस स्थिति तक कैसे पहुँचे
मैंने बहुत सारे ऐसे demos देखे हैं जो किसी शानदार चीज़ तक पहुँचने की लंबी और उबाऊ प्रक्रिया से शुरू होते हैं; अगर वे पहले ही शानदार चीज़ दिखा देते तो कहीं बेहतर होता
तकनीकी presentations के लिए यह एक genius तरीका है
लेकिन novels, TV shows जैसे entertainment media में ऐसा करने पर हमेशा दिलचस्पी कम हो जाती है
अगर किसी action scene को समझने के लिए background जानकारी ज़रूरी नहीं है, तो मेरे हिसाब से background जानकारी पूरी तरह skip की जा सकती है
मैं नहीं चाहूँगा कि pace अचानक बहुत तेज़ हो और फिर बहुत जल्दी वापस शून्य जैसी स्थिति में गिर जाए
फिर भी, कहानी के सबसे महत्वपूर्ण हिस्से को पहले रखने की वजह तो होती ही है
जैसे novel की गति बहुत धीमी है, test readers कोई दिलचस्प घटना होने से पहले ही छोड़ देते हैं, तो editor सुझाव देता है, “Chapter 10 वाला शानदार battle scene शुरू में डाल देते हैं ताकि दिखे कि यह किताब क्या कर रही है”
ऐसा तरीका शायद ही कभी ठीक से काम करता है
मैंने हर sentence और paragraph पढ़ा, लेकिन original post क्या कहना चाहता है यह अब भी मुझे पक्का नहीं है
क्या इसका मतलब “intro skip करो” है?
मैं presentation शुरू करते समय पहले यह छोटा overview देता हूँ कि presentation में क्या-क्या होगा
हमेशा audience के हिसाब से content adjust नहीं कर सकते, लेकिन कम से कम शुरुआत में index या summary दे दें तो पता चल जाता है कि कब ध्यान देना है और कब थोड़ी देर दिमाग़ भटका सकते हैं
बार-बार reinforce करने के लिए मुख्य points 2–3 होने चाहिए, उससे ज़्यादा नहीं
और मेरी नंबर 1 tip यह है कि आप presentation को जितना ज़्यादा natural सुनाना चाहते हैं, पहले से उतनी ही ज़्यादा practice करनी होगी
अनुभवी presenters यह भी जान लेते हैं कि इन rules को कब और कैसे तोड़ना है
बेशक, यह दोबारा आविष्कार है