मैं 1999 से किसी न किसी प्रकार का तकनीकी लेखन कर रहा हूं, जब मैं केफ़र सबा, इज़राइल में अल्टेक लांसिंग की आर एंड डी शाखा के लिए क्यूए कर रहा था। उस समय हम विंडोज़ एमई और 2000 पर काम करने वाले (गैस्प) यूएसबी ऑडियो डिवाइस जैसे नवोन्मेषी, ऑडियो-संबंधित डिवाइस पेश करते थे। वे खराब थे और उन्हें स्थापित करना आज की तरह सीधी बात नहीं थी।
हमें दस्तावेज़ों की ज़रूरत थी.
हमारे पास कुछ उलझनें थीं जिनसे उपयोगकर्ताओं को पार पाना था, और हमें दस्तावेजीकरण करने का एक तरीका चाहिए था कि वे क्या थे, किनारे के मामले क्या थे, और इन सभी चीज़ों का निदान और समाधान कैसे किया जाए। इसे अच्छी तरह से पैक किया जाना चाहिए, साफ-सुथरा स्वरूपित किया जाना चाहिए और हमारे सहायक एप्लिकेशन को इंस्टॉल करने वाले उपयोगकर्ताओं के लिए सुलभ होना चाहिए। मुझे रोबोहेल्प एप्लिकेशन मिला, जिसका उपयोग विंडोज़ पर मानक सहायता एप्लिकेशन बनाने के लिए किया जाता है, और हमारे इंस्टॉल में एक सहायता फ़ाइल जोड़ी गई।
हमारी क्यूए प्रक्रिया के दौरान, हम मुद्दों की पहचान करेंगे, जो हमने सोचा था उसे दस्तावेजित करेंगे, और इसे डिवाइस के साथ बंडल की गई सहायता फ़ाइल में व्यवस्थित करेंगे। मैं उस समय 19 साल का था, और मुझे इस चीज़ का कोई अनुभव नहीं था, और यह एक बेहद अनुभवहीन प्रक्रिया थी। फिर भी, ऐसा लगा कि हमारे उपयोगकर्ताओं के लिए यह सही काम है, और मेरे प्रबंधक ने मुझे स्पष्ट रूप से ऐसा न करने के लिए नहीं कहा।
24 साल हो गए हैं, और तब से मैंने कई परियोजनाओं के लिए दस्तावेज़ीकरण किया है। पैमाना बढ़ गया है, और जिस तरह से मैं उन प्रकार की परियोजनाओं को देखता हूं वह काफी हद तक बदल गया है।
मेरे पास इस बारे में कुछ विचार हैं कि अच्छे दस्तावेज़ क्या बनाते हैं और यदि आपकी रुचि हो तो मुझे उन्हें आपके साथ साझा करना अच्छा लगेगा।
मैं अधिक ठोस नियमों के एक सेट के साथ शुरुआत करना चाहूंगा जो मेरा मानना है कि दस्तावेज़ीकरण उत्पाद की सफलता के लिए महत्वपूर्ण हैं।
दस्तावेज़ों का परीक्षण किया जाना चाहिए - क्योंकि आप आश्वस्त हो सकते हैं कि सब कुछ सही है, लेकिन वास्तविक उपयोगकर्ताओं के बिना, किसी भी अन्य उत्पाद की तरह, आप निश्चित रूप से नहीं जान पाएंगे। इसका परीक्षण करें और दोबारा परीक्षण करें.
जब आप एक नई प्रोग्रामिंग भाषा सीखते हैं, तो उस भाषा की अवधारणाएं और विचार आपकी समस्या-समाधान युक्तियों के बैग में प्रवाहित होते हैं। यह आपको एक बेहतर सॉफ़्टवेयर डेवलपर बनाता है और अंततः, आप बेहतर सॉफ़्टवेयर बनाते हैं क्योंकि आप अधिक जागरूक और सक्षम होते हैं।
मेरा करियर एक जटिल रहा है और इसमें बहुत सारे सॉफ़्टवेयर उत्पाद डिज़ाइन, सॉफ़्टवेयर विकास, तकनीकी सहायता और डेवलपर वकालत शामिल हैं। प्रत्येक अनुशासन ने मेरे सोचने और दूसरों से संपर्क करने के तरीके को प्रभावित किया है।
जब मैं किसी तकनीकी लेखन परियोजना पर विचार करता हूं, तो यह इस व्यापक दृष्टिकोण के साथ होता है कि उपयोगकर्ता को क्या चाहिए। मुझे लगता है कि दस्तावेज़ों के बारे में समग्र रूप से सोचने का यह सही तरीका है। दस्तावेज़ कोई सुपरिभाषित चीज़ नहीं हैं और अच्छे दस्तावेज़ बनाने के लिए आपको लचीला होना होगा।
मेरे लिए, इसका मतलब है कि आपको अपने उपयोगकर्ताओं के बारे में यथासंभव कई कोणों से सोचना होगा। आप किसी भी चीज़ को हल्के में नहीं ले सकते हैं या आप उपयोगकर्ताओं के कुछ समूह को इस तरह से निराश करने जा रहे हैं जो आपके ब्रांड, आपके उत्पाद या आपके व्यवसाय पर इस तरह से नकारात्मक प्रभाव डालेगा कि उससे वापस आना मुश्किल होगा।
आपके दस्तावेज़ अक्सर आपके उपयोगकर्ताओं के लिए इसे बनाओ या बिगाड़ो का अनुभव होते हैं।
यदि आप अच्छा काम करते हैं, तो आपके उपयोगकर्ता आपके उत्पाद का सफलतापूर्वक उपयोग करेंगे, और आपके ब्रांड के चैंपियन बनेंगे। यदि आप ऐसा नहीं करते हैं, तो संभवतः वे कभी भी आपके उत्पाद का दोबारा उपयोग नहीं करेंगे क्योंकि आपके दस्तावेज़ों ने उनके मन में एक ख़राब धारणा छोड़ दी है। वे दूसरों को भी बताएंगे. अच्छी मार्केटिंग यहीं से शुरू होती है, इसलिए इसे ध्यान में रखें।
अच्छे दस्तावेज़ बनाने का सीधा सा मतलब यह है कि आपको अपने दस्तावेज़ निर्माण को उसी तरह अपनाना चाहिए जैसे आप किसी अन्य उत्पाद प्रक्रिया को अपनाते हैं।
आपको:
आइए इनमें से प्रत्येक पर करीब से नज़र डालें।
आपके दस्तावेज़ों का कारण जानना अक्सर उसकी सतह पर एक बहुत ही सीधा प्रश्न और उत्तर सेट होता है। आप दस्तावेज़ इसलिए बना रहे हैं क्योंकि यदि आप ऐसा नहीं करते हैं, तो उपयोगकर्ता परेशानी में पड़ जाएंगे और आपके उत्पाद का उपयोग करने में विफल हो जाएंगे। गहरे स्तर पर, आपके उपयोग-मामले के लिए एक विशिष्ट उत्तर है। क्या आपके पास कोई डेवलपर टूल है? वह एक उत्तर सेट है. क्या आपके पास कोई खुदरा डिज़ाइन उपकरण है? क्या आपके पास अकाउंटिंग SaaS उत्पाद है? क्या आपके पास स्वचालित कॉफ़ी मेकर है? ये सभी अलग-अलग उत्तर सेट हैं।
आपके दस्तावेज़ों के स्वरूप का वर्णन इस आधार पर किया जाता है कि इसका उपयोग कौन करेगा। क्या यह ऑनलाइन है? क्या यह किसी ऐप के साथ बंडल है? क्या यह मुद्रित है? प्रत्येक उपयोगकर्ता आधार को कुछ और की आवश्यकता होगी और आपको शुरू से ही स्पष्ट होना होगा कि वे कौन हैं।
आपका काम यह पता लगाना है कि आपके प्रत्येक उपयोगकर्ता के लिए क्या कठिन है और उन्हें सूचनात्मक सामग्री के माध्यम से फ़नल करने के लिए अपने दस्तावेज़ तैयार करना है जो उनकी विशिष्ट समस्या का समाधान करता है।
सबसे महत्वपूर्ण बात यह है कि आपको यह जानना होगा कि संभवत: पहली बार में आपको यह सही नहीं लगेगा। इसका मतलब है कि जैसे-जैसे आपके उत्पाद बढ़ते हैं और समय के साथ बदलते हैं, आपके दस्तावेज़ों को बनाए रखने और अद्यतन करने की आवश्यकता होती है। उम्मीद है, यह कुछ ढांचे के भीतर किया जाता है जो उन उपयोगकर्ताओं के साथ आसान संचार की अनुमति देता है जिनकी आप मदद करने की कोशिश कर रहे हैं। आपको अपने उपयोगकर्ताओं से बात करनी होगी, उनकी ज़रूरतों को सुनना होगा, और अपने उत्पाद का उपयोग करने के उनके अनुभव को बेहतर बनाने के लिए अपने दस्तावेज़ों का उपयोग करने का प्रयास करना होगा।
मैं केवल यह रेखांकित करके संक्षेप में बताऊंगा कि दस्तावेज़ कितने महत्वपूर्ण हैं। उनके बिना, आपके उपयोगकर्ता स्वयं हैं और उन्हें अपनी सुरक्षा स्वयं करनी होगी।
इसका मतलब हमेशा कम सफलता के मामले, आपके पारिस्थितिकी तंत्र के भीतर आपके उत्पाद के बारे में खराब विचार, अधिक नाखुश डेवलपर्स या उपयोगकर्ता और आपके ब्रांड या कंपनी पर नकारात्मक प्रभाव होगा।
डॉक्स अपने आप में एक गंभीर उप-उत्पाद हैं, एक निवेश हैं, और आपकी व्यापक उत्पाद रणनीति का हिस्सा होना चाहिए।