लिखना शुरू करने का समय।

Amazon ने आंतरिक मीटिंग्स में PowerPoint पर प्रतिबंध लगा दिया, और इसके बदले मीटिंग आयोजित करने वालों से कहा कि वे कई पन्नों का सुव्यवस्थित विवरण लिखें, फिर उसे सभी प्रतिभागियों में बाँटें। और जब तक सभी उसे पढ़ न लें, मीटिंग शुरू न की जाए।

यह लेख बताता है कि मीटिंग करने के कई तरीकों में से लिखना ही क्यों होना चाहिए, और PowerPoint तथा इंजीनियरों के गोल घेरा बनाकर बैठकर बात करने वाला तरीका क्यों काम नहीं करता। नीचे एक संक्षिप्त सार है।

PowerPoint किसी विचार को सजाने-सँवारने की गुंजाइश देता है, अपेक्षाकृत महत्वपूर्ण बातों को फीका बना देता है, और विचार की निरंतरता को नज़रअंदाज़ करता है।

इंजीनियरों का बीच में pizza रखकर चर्चा करने का तरीका बहुत-सा ज्ञान हासिल करने में उपयोगी है, लेकिन बातचीत बिखर जाती है। इसलिए इस गतिरोध को तोड़ने के लिए उनमें से किसी एक को business requirements से लेकर implementation की व्यावहारिकता तक, एक व्यापक, प्रवाहपूर्ण और तार्किक तरीके से क्या और कैसे करना है, इसका विवरण देना पड़ता है.

इसे दूसरों तक पहुँचाने के लिए, लेखक ने शायद इन बातों को ध्यान में रखकर लिखा होगा।

• प्रस्तावना

  • तकनीकी बदलाव का कारण क्या है? यह क्यों मूल्यवान है, और इसके क्या लाभ हैं?

  • इस खास तकनीक को समाधान के रूप में क्यों खोजा गया? जाँचने योग्य अन्य विकल्प कौन-से हैं?

  • कितना काम निपटाना होगा? क्या इमारत की नींव रखनी है, या साइकिल शेड बनाना है? अगर समस्या हल न हो तो क्या बदलाव को वापस लेना आसान है?

• मुख्य भाग

  • प्रस्तावित तकनीक में कोई अनिवार्य बातें या guiding principles हैं? उनका हमारी समस्या और दर्शन से क्या संबंध है?

  • अगर हम इसे लागू करें, तो अंतिम लक्ष्य क्या है? implementation पूरा होने के बाद दुनिया कैसी बदलेगी?

  • न्यूनतम व्यवधान के साथ हम अपनी मौजूदा स्थिति से लक्ष्य तक कैसे जाएँगे? transition period कितना होगा? मोटे तौर पर कितना समय लगेगा?

  • क्या हमारे पास मौजूदा आंतरिक विशेषज्ञता है?

  • जोखिम क्या हैं? उन्हें कम करने के उपाय हैं? unknown unknowns क्या हैं?

  • यह solution विकल्पों की तुलना में किन मायनों में बेहतर है?

  • विकल्प इससे किन मायनों में बेहतर हैं?

• निष्कर्ष

  • मूल business requirement और recommendation का सार दें, और समझाएँ कि यही सबसे अच्छा विकल्प क्यों है।

यह TDD जैसा है, लेकिन TDD जहाँ अक्सर सिर्फ TDD तक ही सीमित रह जाता है, वहीं इस तरह के विवरण लिखने का एक दिलचस्प side effect होता है। यह वे विचार हैं जो लेखक के मन में बचे रहते हैं।

अगर इन विचारों को natural language में अनुवाद करने के बाद लेखक के साथ फिर मौखिक रूप से चर्चा की जाए, तो कोई समस्या नहीं होती। और अच्छी तरह लिखने के लिए ज़रूरी विश्लेषण के कई स्तरों पर समस्या पर विचार करने के बाद, आप श्रोताओं के हर स्तर के अनुसार व्याख्या को समायोजित कर सकते हैं।

अंत में, खास टूल्स के विपरीत, विवरण (narrative) सार्वभौमिक होता है। सबसे संकरे तकनीकी मुद्दे से लेकर पूरे company mission और उद्देश्य से जुड़े मूलभूत प्रश्नों तक। ऐसा कोई मुद्दा नहीं है जो स्पष्ट सोच का प्रतिरोध कर सके.

[sduck4]

यह सोचने पर मजबूर करता है कि visual elements किस हद तक पाठक (या श्रोता) से सोचने का अधिकार, कल्पना करने का अधिकार छीन रहे हैं.

[ffdd270]

बाहरी तौर पर सार्वजनिक करते समय वह एक ज़रूरी कौशल है, लेकिन अंदरूनी तौर पर हमें एक-दूसरे के साथ ईमानदार होना ही पड़ता है..

[xguru]

सारांश के लिए धन्यवाद!

वह 2004 के email में 4 पेज का था, लेकिन 2017 के shareholder newsletter में उसे 6-पेज narrative कहा गया था, तो मैंने कभी सोचा था, हम्म, क्या 10 साल के दौरान 2 पेज बढ़ गए?..

(एक Amazon कर्मचारी के अनुसार, उस narrative memo को लिखना सचमुच और भी मुश्किल होता है।)

[ffdd270]

दुनिया 10 साल के दौरान काफ़ी जटिल हो गई है (... ) इसलिए लगता है करीब 2 अध्याय ठीक रहेंगे, हा हा

मैं भी हर दिन व्यवस्थित करने के लिए लिखता हूँ, लेकिन भले ही वह लेख सिर्फ़ मैं ही देखता हूँ, फिर भी विचारों को व्यवस्थित करना और सबसे बढ़कर ईमानदार होना (अभी मुझमें क्या कमी है, अभी मुझे क्या करना चाहिए था लेकिन नहीं कर पाया.. कौन-से विकल्प थे लेकिन मैंने नज़रअंदाज़ कर दिए.. ) वाकई बहुत मुश्किल लगता है।