---
title: "परिचय"
description: "सात-क्रिया दस्तावेज़ीकरण मॉडल क्यों मौजूद है।"
doc_version: "2025-01-09"
last_updated: "2026-08-09"
canonical_url: "https://7act.org/hi/rationale/"
language: "hi"
license: "CC BY 4.0"
---

# परिचय

मेरा मानना है कि हर तकनीकी लेखक कभी न कभी अपने काम को “लोग हमेशा से ऐसे ही दस्तावेज़ बनाते आए हैं” से अधिक व्यवस्थित किसी आधार पर रखना चाहता है। टूलकिट और फ्रेमवर्क सामग्री प्रकार देते हैं, जो तब अत्यंत मूल्यवान हैं जब आप *जानते* हैं कि आपको क्या लिखना है; लेकिन वहीं से *शुरू करना* ऐसा है जैसे हथौड़ा खरीदना और यह न जानना कि आधा काम पेंच घुमाना होगा।

## दस्तावेज़ीकरण फ्रेमवर्क, उपकरण और प्रारूप पर्याप्त नहीं हैं

अधिकांश मौजूदा दस्तावेज़ीकरण फ्रेमवर्क तकनीकी लेखकों की क्रियाओं पर केंद्रित हैं, उपयोगकर्ताओं—अर्थात् दस्तावेज़ों के *उपभोक्ताओं*—की क्रियाओं पर नहीं। किन दस्तावेज़ों का उत्पादन होना चाहिए, इस पर निर्देशात्मक ज़ोर, उन उपयोगकर्ता जरूरतों का वर्णन करने के बजाय जिन्हें संबोधित किया जाना चाहिए, उस वास्तुशिल्प मानसिकता की याद दिलाता है जिसमें दीवारें बनाई जाती हैं क्योंकि *घर में कमरे तो होने ही चाहिए, क्या हम बर्बर हैं*? लचीलेपन की यह स्पष्ट कमी उस सामग्री को लिखने से रोकती है जिसकी वास्तव में जरूरत है।

इन फ्रेमवर्कों के कुछ डिज़ाइनर समस्या से परिचित हैं और कहते हैं कि उनके नियमों का शब्दशः पालन न हो तथा वास्तविक दुनिया में उन्हें लागू करने में लचीलापन रहे। फ्रेमवर्क उपयोग करने वाले लेखक भी इस दुविधा से गुज़रे हैं और अधिकांश मामलों में उन्होंने मॉडल को अपनी जरूरत के अनुरूप बदला है। इस तरह फ्रेमवर्क टूलबॉक्स बन जाते हैं जिनसे टेम्पलेट और विचार चुने जाते हैं। लेकिन यह पैटर्न उस प्रश्न से बचता है कि वास्तव में क्या आवश्यक है।

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

## सामग्री प्रकारों से उपयोगकर्ता जरूरतों की ओर ध्यान ले जाना

एक समाधान यह है कि ध्यान को इस बात से हटाया जाए कि क्या लिखा जाना चाहिए और इस पर लाया जाए कि किस उपयोगकर्ता जरूरत को संबोधित होना चाहिए। इसके लिए पहले से तय संरचनात्मक पैटर्न पर सामग्री बनाने के बजाय दस्तावेज़ीकरण के रणनीतिक पक्ष—जैसे सामग्री रणनीति—की जिम्मेदारी लेनी होती है। यह दृष्टिकोण Diátaxis, DITA और अन्य दस्तावेज़ीकरण फ्रेमवर्कों के साथ पूर्णतः संगत है, क्योंकि यह दस्तावेज़ बनाने वालों को दिशा और उद्देश्य देता है; फिर वे उपलब्ध सामग्री प्रकार, तत्व और उपकरण उपयोग करते हैं।

सैंडविच रूपक से आप बेहतर समझ सकते हैं कि मेरे विचार में फ्रेमवर्क, उपकरण और उपयोगकर्ता-जरूरत के मॉडल कैसे जुड़ते हैं—खासकर यदि आपने अभी दोपहर का खाना नहीं खाया है। फ्रेमवर्क और उपकरण सैंडविच को साथ रखने और सँभालने योग्य बनाने वाली आवश्यक सामग्री हैं, पर सैंडविच का स्वाद और अर्थ भरावन से आता है—अर्थात् उपयोगकर्ता जरूरतों का वह मानसिक मॉडल जिसका आप अनुसरण करते हैं। यह बाहरी हितधारक अनुरोधों जैसा *नहीं* है, हालांकि इनमें मेल हो सकता है। और यदि कुछ है, तो OKR सॉस हैं।

![दस्तावेज़ीकरण सैंडविच: ऊपर फ्रेमवर्क और सामग्री प्रकार, बीच में उपयोगकर्ता जरूरतें, और नीचे प्रारूप तथा टूलचेन।](https://passo.uno/uploads/sandwich-2.jpg)

दूसरे शब्दों में, प्रभावी दस्तावेज़ बनाने के लिए केवल उपकरण और सामग्री प्रकार पर्याप्त नहीं हैं; आपको उन जरूरतों का मॉडल भी चाहिए जिन्हें दस्तावेज़ को उत्पाद के रूप में पूरा करना है, या उन क्रियाओं का जिन्हें उपयोगकर्ता उसके माध्यम से पूरा करते हैं। यह मॉडल उस सॉफ़्टवेयर उत्पाद के प्रकार से काफी हद तक स्वतंत्र होना चाहिए जिसका आप दस्तावेज़ीकरण कर रहे हैं, ठीक उसी तरह जैसे उत्पाद डिज़ाइन और संतुष्टि के वैचारिक मॉडल विशिष्ट विवरणों से ऊपर उठते हैं। एक सामान्य मॉडल की ओर बढ़ना आवश्यक है क्योंकि यह पेशेवरों को साथ सीखने और संवाद करने में मदद करता है।

आगे मेरा उपयोगकर्ता जरूरतों का *वर्णनात्मक* मॉडल है, जिसका मैं आज दस्तावेज़ बनाने और व्यवस्थित करने में अनुसरण करता हूँ।

## सात-क्रिया दस्तावेज़ीकरण मॉडल

मैं जो दृष्टिकोण यहाँ प्रस्तुत कर रहा हूँ वह *उन उपयोगकर्ता क्रियाओं का मॉडल है जिन्हें दस्तावेज़ों को पूरा करना चाहिए*। यह UX अनुसंधान और दस्तावेज़ीकरण फ्रेमवर्कों को एक वैचारिक और कार्यात्मक परत से जोड़ता है जो दो पहलुओं पर ध्यान देती है: उत्पाद के रूप में दस्तावेज़, और वह जो उपयोगकर्ता उनसे हासिल करते हैं। यह वर्णन करने का प्रयास है कि तकनीकी दस्तावेज़ों को *क्या करना चाहिए*—दस्तावेज़ों को ऐसे उत्पाद की तरह मानना जिसे कोई व्यक्ति वास्तविक लक्ष्य पाने के लिए उपयोग करता है।

जैसा मैंने कहा, मॉडल का केंद्र *क्रियाएँ* हैं। मैंने सात क्रियाएँ पहचानी हैं जो दस्तावेज़ का उपभोक्ता उपयोग करते समय जिन लक्ष्यों को पाना चाहता है, उनका अच्छा हिस्सा समेटती हैं। ये अलग-अलग उत्पादों और क्षेत्रों में दस्तावेज़ों से उपयोगकर्ता के संवाद के सामान्य पैटर्न हैं: मूल्यांकन (पहचान), समझ (सीख), अन्वेषण (खोज), अभ्यास (प्रशिक्षण), स्मरण (पुनर्प्राप्ति), विकास (एकीकरण), और समस्या-निवारण (समाधान)।

क्रियाओं का क्रम जानबूझकर चुना गया है, लेकिन सख्त नहीं। मैंने उन्हें ऐसे क्रम में रखा है जो मेरे विचार में सॉफ़्टवेयर तकनीकी दस्तावेज़ों के प्रति उपभोक्ताओं के दृष्टिकोण से मोटे तौर पर मिलता-जुलता है। ये क्रियाएँ अलग-अलग चरणों या स्तरों पर होती हैं। नियमित सप्तभुज पर रखने पर ऊपर की क्रियाएँ उत्पाद से संवाद के शुरुआती चरणों में अधिक होती हैं, जबकि नीचे की क्रियाएँ तब होती हैं जब उत्पाद का ज्ञान और उपयोग सुदृढ़ हो चुका हो।

## निष्कर्ष

यहाँ प्रस्तुत मॉडल सामग्री प्रकारों की जगह उपयोगकर्ता जरूरतों की दृष्टि से दस्तावेज़ों के बारे में सोचने का तरीका देता है। इसका उद्देश्य मौजूदा फ्रेमवर्कों को बदलना नहीं, बल्कि उनका पूरक होना है। साथ उपयोग करने पर वे तकनीकी लेखकों को ऐसी सामग्री बनाने देते हैं जो संरचनात्मक रूप से ठोस और वास्तविक उद्देश्य की सेवा करने वाली हो, न कि केवल टेम्पलेट भरने वाली।

यह मॉडल [दस्तावेज़ीकरण मेट्रिक्स और लक्ष्य-निर्धारण](https://passo.uno/docs-observability-do11y/) (do11y) का आधार भी बन सकता है। केवल पृष्ठ-दृश्य या संतुष्टि स्कोर पर ध्यान देने के बजाय टीमें माप सकती हैं कि उनके दस्तावेज़ प्रत्येक क्रिया को कितनी अच्छी तरह पूरा करते हैं। उदाहरण के लिए, दस्तावेज़ से उत्पाद अपनाने की रूपांतरण दर मूल्यांकन की प्रभावशीलता माप सकती है, जबकि समाधान समय समस्या-निवारण की सफलता का संकेत हो सकता है।

सैद्धांतिक मॉडलों की तरह यह मॉडल विस्तृत शोध या कारक विश्लेषण पर आधारित नहीं है। इसे जैसा है वैसा वितरित किया जाता है और किसी भी परिस्थिति में आप मुझे आपका भोजन खराब करने के लिए उत्तरदायी नहीं ठहरा सकते। फिर भी, आशा है कि यह अधिक उद्देश्यपूर्ण तकनीकी दस्तावेज़ चाहने वालों के लिए उपयोगी दृष्टिकोण देगा।

![इंडियाना जोन्स और दस्तावेज़ीकरण की सात क्रियाओं वाला पिक्सेल-कला पुस्तकालय दृश्य।](https://passo.uno/uploads/indy.jpg)

## Sitemap

- [सात-क्रिया दस्तावेज़ीकरण मॉडल](https://7act.org/hi/index.md)
- [परिचय](https://7act.org/hi/rationale/index.md)
- [क्रियाएँ](https://7act.org/hi/actions/index.md)
- [मूल्यांकन](https://7act.org/hi/actions/appraise/index.md)
- [समझ](https://7act.org/hi/actions/understand/index.md)
- [अन्वेषण](https://7act.org/hi/actions/explore/index.md)
- [अभ्यास](https://7act.org/hi/actions/practice/index.md)
- [स्मरण](https://7act.org/hi/actions/remember/index.md)
- [विकास](https://7act.org/hi/actions/develop/index.md)
- [समस्या-निवारण](https://7act.org/hi/actions/troubleshoot/index.md)
- [शब्दावली](https://7act.org/hi/glossary/index.md)
- [सात-क्रिया दस्तावेज़ीकरण Skill](https://7act.org/hi/skill/index.md)