- प्रोजेक्ट status report में लंबी पृष्ठभूमि की बजाय निष्कर्ष पहले बताने का तरीका मैनेजर तक ज़रूरी निर्णय-सूचना जल्दी पहुँचाता है
- सुझाया गया क्रम है punchline → वर्तमान स्थिति → अगला चरण → व्याख्या, और पहले वाक्य में बिना किसी विशेषण के सिर्फ तथ्य होने चाहिए
- यह तरीका शुरुआत में अटपटा लग सकता है, लेकिन देर से मुद्दे पर आने वाली अस्पष्ट व्याख्याओं को कम करता है और रिपोर्टिंग का समय बचाता है
- 17 वर्षीय बेटे Raj ने दुर्घटना के तुरंत बाद “Dad, I’m OK; the bull is dead” कहकर पहले अपनी सुरक्षा और स्थिति का मुख्य बिंदु तुरंत बता दिया
- प्रोजेक्ट रिपोर्ट भी पत्रकारिता की inverted pyramid संरचना की तरह महत्वपूर्ण तथ्यों को आगे रखे तो अधिक स्पष्ट होती है
निष्कर्ष से शुरू होने वाली status report
- इंजीनियरिंग टीम की प्रोजेक्ट status report को चार चरणों में व्यवस्थित किया गया है
- Punchline: पहले सिर्फ तथ्य बताएं। उदाहरण: “Milestone 4 समय पर पूरा नहीं हुआ और Task 8 योजना के अनुसार शुरू नहीं हो सका” या “charter approval योजना के मुताबिक मिल गया”
- वर्तमान स्थिति: बताएं कि उस तथ्य का प्रोजेक्ट पर क्या असर है। उदाहरण: “छूटा हुआ milestone होने के कारण critical path में 5 दिन की देरी हुई”
- अगला चरण: संभव समाधान और recovery की संभावना बताएं। उदाहरण: “अगले 2 हफ्तों में 3 दिन की भरपाई हो सकती है, लेकिन फिर भी 2 दिन की देरी रहेगी”
- व्याख्या: punchline के कारण को जोड़ें। उदाहरण: “5 दिन की देरी में 2 दिन इसलिए हुए क्योंकि hardware interface की समस्या देर से पता चली, और 3 दिन production issue के कारण customer support टीम की मदद करनी पड़ी”
- आम रिपोर्टिंग शैली में पहले यह लंबा बताया जाता है कि चीज़ें क्यों गलत हुईं और फिर मुख्य बात आती है, लेकिन यह तरीका सबसे महत्वपूर्ण जानकारी को सबसे आगे रखता है
- शुरुआत में यह असहज लगा, लेकिन बाद में टीम के लोगों ने पाया कि संदेश अधिक स्पष्ट हो गया और मुख्य बात पहुँचाने में लगने वाला समय कम हो गया, इसलिए उन्होंने इसे पसंद किया
“मैं ठीक हूँ, बैल मर चुका है” उदाहरण
- देर रात, हाल ही में गाड़ी चलाना शुरू करने वाला 17 वर्षीय बेटा Raj तूफ़ान के बीच घर नहीं पहुँचा था, इसलिए माता-पिता चिंतित थे, तभी फोन आया
- पहला वाक्य “Dad, I’m OK; the bull is dead” एक punchline था, जिसने पहले सुरक्षा की स्थिति और दुर्घटना का सार बता दिया
- इसके बाद उसने कहा, “कार क्षतिग्रस्त है, लेकिन चलाने लायक है”, जिससे पता चला कि दुर्घटना हुई थी पर कार पूरी तरह नष्ट नहीं हुई थी
- फिर उसने क्रम से दुर्घटना-स्थल, पास के किसी व्यक्ति द्वारा पुलिस को बुलाए जाने, और घटना-स्थल की कुछ तस्वीरें लेने की बात बताई
- यह क्रम पत्रकारिता के inverted pyramid style जैसा है, जिसमें निष्कर्ष, महत्वपूर्ण तथ्य और फिर विवरण आते हैं
- इसके उलट, अगर अकादमिक लेखन की तरह समस्या प्रस्तुति, पृष्ठभूमि, प्रभावकारी कारण और निष्कर्ष के क्रम में प्रोजेक्ट status बताया जाए, तो सुनने वाला मुख्य बिंदु तक पहुँचने से पहले थक सकता है
- प्रोजेक्ट रिपोर्टिंग में पहले punchline कहना चाहिए, ताकि अनावश्यक व्याख्या कम हो और ज़रूरी जानकारी जल्दी पहुँचे
1 टिप्पणियां
Hacker News की रायें
बचपन से ही मैंने इस तरह बोलना सीख लिया था। आम तौर पर मेरे पिता अच्छे थे, लेकिन अगर मेरी बात के बीच में ही वे बहुत जल्दी निष्कर्ष निकाल लेते, तो तुरंत गुस्सा हो जाते थे
उदाहरण के लिए, अगर मैं कहता “मैं दोस्तों के पास गया था और वे सब सिगरेट पी रहे थे”, तो वे निष्कर्ष निकाल लेते कि मैंने भी सिगरेट पी, और जब तक वे शांत नहीं हो जाते, उन्हें उल्टा समझाना मुमकिन नहीं था। इसलिए मेरी आदत बन गई कि पहले ही कहूं, “मैंने सिगरेट नहीं पी। लेकिन दोस्तों ने पी।” और तब ठीक रहता था
लेख की तरह, अपनी स्थिति बताने पर भी मैं कुछ वैसा ही कहता हूं, लेकिन मुझे नहीं पता कि यह सकारात्मक व्यक्तित्व गुण है या नहीं। बल्कि यह anxiety issue के ज्यादा करीब लगता है। लेख के उदाहरण में “मैंने बैल को टक्कर मारी, मैं ठीक हूं, बैल नहीं है” कहना कहीं ज्यादा स्वाभाविक और उपयोगी लगता है
Contact में मुझे जो चीज अच्छी लगी, उनमें से एक यह थी कि Ellie की रेडियो आवाज लगभग noise में बदलने लगती है, तो वह असली launch तक लगातार दोहराती रहती है कि launch की तैयारी हो गई है
किसी आम सस्ती फिल्म में होता, “क्र्र्र…ही कातिल है! Sarah की लाश मिल गई। उस पर भरोसा मत करना!” और फिर बात “क्या उसने मेरी बात सुनी होगी? अब उम्मीद करनी चाहिए कि वह अभी लोगों को मार नहीं रहा होगा” जैसी दिशा में चली जाती
अक्सर सिर्फ किसी idea को एक obvious लेकिन गलत आलोचनात्मक angle से defend करना काफी नहीं होता; sentences का क्रम सही रखना पड़ता है और यह भी सोचना पड़ता है कि reviewer के कौन से psychological switch को छूने पर वह तुरंत आसान rejection logic में फिसल सकता है। इसमें अच्छा होना सचमुच एक skill है, और contribution बनाने वाली hard science ability भर से काम पूरा नहीं होता। आपको उसे सही तरीके से बेचना और frame करना भी आना चाहिए
इस तरह का communication मुझे पसंद है, क्योंकि यह असली emergency हो या बस कंपनी app न चलने जैसी स्थिति, बहुत उपयोगी होता है। बुरी खबर से शुरुआत करने पर सामने वाला तुरंत सबसे बुरा imagine करना शुरू कर सकता है, इसलिए कुल मिलाकर यह anxiety भी कम करता है
जैसे “डेटा सुरक्षित है, breach नहीं है, और हम पर DDoS हो रहा है” कहना “X, Y, Z services को प्रभावित करने वाला बड़ा DDoS हुआ है, लेकिन हम data breach या loss का संदेह नहीं कर रहे” से बेहतर है
फिर भी मूल idea सही और उपयोगी है। सबसे अहम तथ्य पहले रखने से सुनने वाला बाद का context और explanation कहीं आसानी से समझता है, और अगर मैं भटक जाऊं तो मुझे रोक सकता है
communication में अक्सर दिखने वाली समस्या यह है कि लोग लंबे-चौड़े context से शुरुआत करते हैं। तब मन में आता है, “यह मुझे क्यों बता रहे हैं?”, और यह तय करना मुश्किल हो जाता है कि क्या अहम है और मुझसे कैसे जुड़ा है
कुछ साल पहले मैंने message भेजा था, “मैं ठीक हूं, लेकिन लगता है कार पूरी तरह खराब हो गई है। क्या आप [accident location] आ सकती हैं? घर जाने के लिए मुझे ride चाहिए”
मां ने हमेशा की तरह आखिरकार बहुत घबरा गईं, लेकिन सच में मुझे बस थोड़ी चोट के निशान आए थे और कार वाकई total loss घोषित हुई
लेख में background से शुरुआत करने के तरीके की तुलना “academic approach” से की गई है, लेकिन असली academic papers ऐसे शुरू नहीं होते। Papers पूरी सामग्री को बहुत संक्षेप में बिछाने वाले abstract से शुरू होते हैं
Graduate students को अक्सर दी जाने वाली practical advice भी है: abstract पढ़ो, conclusion पढ़ो, introduction पढ़ो, फिर बाकी पढ़ो
सच में ऐसा था क्या, यह लगता है। “मैं ठीक हूँ” से शुरू करना अच्छा है, लेकिन उसके बाद “एक accident हो गया” होना चाहिए था, और फिर “कार ठीक है” या “सांड से टक्कर हुई/सांड ने टक्कर मारी, और सांड मर गया” जैसा कुछ होना चाहिए था।
“मैं ठीक और सुरक्षित हूँ, road accident हुआ है, location यहाँ है, urgent नहीं है” — माता-पिता के लिए यही सबसे ज़रूरी और actionable जानकारी है। सांड और वह जिंदा है या नहीं, यह relevant नहीं है। यह ऐसा पढ़ता है जैसे दो robots संक्षेप में बोलने की कोशिश में communication fail कर रहे हों। फिर कहूँगा, यह सांस्कृतिक फर्क भी हो सकता है।
शायद यह perspective का मामला है। वह 17 साल का था, देर रात थी, और अभी-अभी ऐसी सड़क दुर्घटना से गुज़रा था जिसमें सांड मर गया था, इसलिए माता-पिता के नज़रिए को ध्यान में रखने की उसकी क्षमता कुछ हद तक सीमित रही होगी।
फिर भी उसने अच्छा किया और कहानी अच्छी है, ऐसा मानता हूँ। वह सुरक्षित रहा, यह अच्छी बात है और किस्मत अच्छी थी। सांड के लिए अफसोस है, RIP।
जब project status report को इस तरह structure किया जाता है, तो context पर्याप्त होता है, और audience अतिरिक्त context से ज़्यादा नई जानकारी चाहती है। बेशक balance बदले तो बात बदल जाती है।
“मैं ठीक हूँ” से शुरू करना context में सही था। अशुभ-से समय पर बच्चे का unexpected call आना context है, इसलिए safety सबसे पहले है। लेकिन उसके बाद सांड से जुड़ी पहेली छोड़ना उसी context में बेकार की बात है।
इसके अलावा “थोड़ा गुस्सा आया” वाला हिस्सा भी अच्छा नहीं था। बेटे का accident हुआ और गुस्सा आया? accident की वजह जानने से पहले या बाद में? वह context कहाँ है, और उसे कुछ paragraphs पहले बताई गई structure में क्यों नहीं दिया गया?
सांड के साथ आखिर हुआ क्या था? पाठक को अधर में छोड़कर खत्म करने से लेख का तर्क कमजोर हो जाता है। दिलचस्प हिस्से सब गायब हैं। “James Bond बच गया, villain की योजना रोक दी, और लड़की भी मिल गई” कोई फिल्म नहीं है। ऐसे communicate करने वाले व्यक्ति के साथ काम करना या घुलना-मिलना पड़े तो मुझे पसंद नहीं आएगा।
मुझे नहीं लगता कि लेखक हर communication इसी तरीके से करने का सुझाव दे रहा है। कहानी सुनाते समय suspense बनाए रखना ठीक है। लेकिन जब accident हो जाए, तो अपने प्रियजन को सूचना देते समय suspense को tool की तरह इस्तेमाल करना चाहिए क्या?
work communication में कुछ चीज़ें पहले वाली तरह होती हैं और कुछ बाद वाली तरह। लेकिन ज़्यादातर में default 95% समय narrative और suspenseful तरीके पर सेट होता है।
हमें ज़्यादा intentional choice करनी चाहिए, और कुछ स्थितियों में inverted pyramid structure का उपयोग करके communication से suspense हटाना चाहिए।
मूल सलाह की value हर step की relative importance से ज़्यादा इस बात में है कि वह order, असल में जो हुआ उसे सजाने-संवारने या धुंधला करने नहीं देता। यह team को facts को bias के बिना साफ़-साफ़ मानने पर मजबूर करता है।
लेकिन explanation के बिना कहानी खत्म कर देने से यह समझने के लिए ज़रूरी बड़ा हिस्सा गायब रह जाता है कि हुआ क्या था।
यह सवाल मुझे इतना खटका कि मैंने 2004 में असली कागज़ी चिट्ठी—या शायद email रहा होगा, लेकिन dramatic effect के लिए कहूँगा कि मैंने कागज़ी चिट्ठी पर stamp लगाया और post office तक 20 mile चढ़ाई पैदल गया—के ज़रिए सवाल भेजा।
वह सवाल magazine में छपा और Mr. Kapur का जवाब भी magazine में छपा। लेकिन मेरी search skills से मुझे उस समय का जवाब नहीं मिल पा रहा।
दुर्भाग्य से मुझे जवाब याद नहीं, इसलिए cliffhanger ending जारी है।
https://www.computerworld.com/article/2567061/no-bull-approa...
यह James Bond movie का plot नहीं है, लेकिन शायद यही point है। हर घटना को action-packed narrative की ज़रूरत नहीं होती। कुछ चीज़ें बस हो जाती हैं, और हमें status इस तरह बताना चाहिए कि तीखी emotional reaction न पैदा हो। क्योंकि ऐसी reaction स्थिति को handle करने में बाधा बनती है।
यह आम तौर पर emotional reaction जगाने का लक्ष्य रखने वाली फिल्मों के लगभग उलट है।
मुख्य निष्कर्ष पहले बताने का तरीका तभी काम करता है जब सामने वाले को पता हो कि मैं किस बारे में बात कर रहा हूँ। इस case में “उस सांड” का कोई prior context नहीं था, इसलिए सुनने वाला नहीं समझ सकता कि “सांड मर गया” का असल मतलब क्या है। क्या सच में कोई सांड मर गया, या यह किसी और चीज़ का metaphor है?
सही report कुछ ऐसी होगी: “मैं ठीक हूँ, लेकिन accident हो गया। मैंने सांड को टक्कर मार दी और वह मर गया।” हालांकि title के तौर पर यह कहीं कम आकर्षक है।
यह कहना आसान है कि उसने गलत बोला, लेकिन panic में किए गए phone call से तुलना करें तो यह काफी ठीक है।
ऐसे procedures स्थिति पर natural reaction को overwrite करने में मदद करते हैं। लोग अक्सर सोचते हैं कि crisis में वे calm रहेंगे, लेकिन panic अजीब व्यवहार करवाता है।
पढ़ने में मज़ेदार तो है, लेकिन “सांड मर गया” जोड़ना सच में clutter हटाकर effective communication का अच्छा example है या नहीं, मुझे नहीं पता। “कार damage हुई है लेकिन चल सकती है” अच्छा example है, पर अभी तक explain न किया गया सांड के मरने वाला information अब relevant नहीं है, इसलिए उल्टा clutter है।
explanation भी नहीं है, इसलिए receiver confuse हो जाता है और technically irrelevant इस information पर focus करने लगता है। आगे कोई detail भी नहीं दी जाती।
फिर भी लेख अच्छा है और point अब भी valid है। बस मुझे लगता है example perfect नहीं है।
http://www.sixwordstories.net
क्या सिर्फ मुझे लग रहा है कि इस लेख ने आख़िरी हिस्सा छोड़ दिया? उस बैल की मौत कैसे हुई, इसकी व्याख्या चाहिए
वह सवाल पत्रिका में छपा था और Mr. Kapur का जवाब भी पत्रिका में छपा था। लेकिन मेरी search skills से उस समय का जवाब नहीं मिल पा रहा
दुर्भाग्य से मुझे जवाब याद नहीं है, इसलिए cliffhanger अब भी जारी है
https://www.computerworld.com/article/2567061/no-bull-approa...
नहीं, “मैं ठीक हूँ, और बैल मर गया” के बाद “कार को नुकसान हुआ है लेकिन चल सकती है” कहना, क्या हुआ था यह प्रभावी ढंग से बताने का तरीका नहीं है। communication का लक्ष्य यह नहीं है कि सामने वाला ढेर सारे खाली स्थान भरे और puzzle हल करे
आज पहले मैंने यह लेख पढ़ा और मुझे पसंद आया, और बाद में उस पर सोचते हुए कुछ अजीब बातें भी ध्यान में आईं। शुरुआत में data का ऐसा टुकड़ा फेंक देना जिसे आप फिर कभी address नहीं करेंगे, और कहना “details बाद में”, स्वाभाविक रूप से मूर्खता है। फिर भी “बैल मर गया” वाक्य इतना तीखा है कि अब भी दिमाग़ में अटका हुआ है
ईमेल लिखते समय मुझे BLUF, यानी निष्कर्ष को सबसे पहले रखने का तरीका, बहुत पसंद है; इसे उसका विस्तार भी माना जा सकता है
project status report जैसी चीज़ों के लिए यह ठीक लगता है। सीधे मुद्दे पर आना अच्छा है
लेकिन जीवन में, मुझे नहीं पता। क्या लोग दूसरों से बात करते समय अपनी चोटों को कम करके बताने की प्रवृत्ति नहीं रखते? “मैं ठीक हूँ, और मेरा accident हो गया” में “ठीक हूँ” का मतलब “बिल्कुल सही-सलामत” से लेकर “ज़िंदगी भर कमर की समस्या और legal issues रहेंगे, लेकिन ज़िंदा हूँ” तक हो सकता है
इसके उलट “मैं ठीक हूँ, और मेरी girlfriend ने मुझे छोड़ दिया। beer पीने चलोगे?” हो तो संभावनाओं का दायरा काफ़ी छोटा है
अगर किसी ने पहली ही बात में यह कहने का फैसला किया कि वह ठीक है, तो निश्चित रूप से कुछ काफ़ी बुरा हुआ है। इसलिए “हल्का-सा fender bender हुआ है, किसी को चोट नहीं लगी, और शायद थोड़ी देर हो जाएगी” कहना बेहतर होगा
यह याद आता है। काल्पनिक crime investigation stories में Mrs Marple सभी clues इकट्ठा करने के बाद आख़िरी grand summary वाली बैठक में सबको बुलाकर murderer का खुलासा करती हैं
Inspector Columbo के episode murder scene से ही शुरू होते हैं, और अपराधी भी साफ़ दिखाई देता है। उसके बाद हम Columbo को clues इकट्ठा करते और motive खोजते हुए देखते हैं
जब हमें Columbo की तरह करना चाहिए, तब भी हमारा रुझान Mrs Marple की तरह व्यवहार करने का होता है