गुप्त ज्ञान खतरनाक है
सॉफ़्टवेयर टीमों में अंतर्निहित या “जनजातीय” ज्ञान इस सवाल को उठाता है कि क्या वास्तव में दस्तावेज़ित किया जा सकता है और क्या केवल अनुभव तथा mentorship से ही सीखा जा सकता है। टिप्पणीकार अप्रलेखित प्रक्रिया-विशेषताओं को सच्चे अंतर्निहित ज्ञान (जैसे design taste या debugging intuition) के साथ मिला देने की आलोचना करते हैं, और चेतावनी देते हैं कि बाद वाले को पूरी तरह औपचारिक बनाने की कोशिश उलटी पड़ सकती है और विशेषज्ञों को नुकसान पहुँचा सकती है। अन्य लोग यह देखते हैं कि बेहतर documentation, सार्वजनिक internal channels, और यहाँ तक कि company-specific LLM “oracles” जैसी प्रथाएँ छिपे ज्ञान को सामने ला सकती हैं, जबकि सब कुछ कैद करने की security, liability, और maintenance लागतों को भी रेखांकित करते हैं.
अंतर्निहित बनाम जनजातीय/अप्रलेखित ज्ञान की परिभाषा
- कई लोग तर्क देते हैं कि लेख “अंतर्निहित ज्ञान” का गलत उपयोग करता है, और इसे “जनजातीय” या केवल अप्रलेखित ज्ञान के साथ मिला देता है।
- थ्रेड में, अंतर्निहित ज्ञान को इस प्रकार वर्णित किया गया है:
- ऐसा कौशल/अंतर्ज्ञान जिसे दस्तावेज़ों में पूरी तरह कैद नहीं किया जा सकता (जैसे, बाइक चलाना, कोड का “taste”, debugging instincts, भौतिक शिल्प कौशल)।
- ऐसा ज्ञान जो केवल specs पढ़ने से नहीं, बल्कि अनुभव और संदर्भ से उभरता है।
- अप्रलेखित स्पष्ट तथ्य (जैसे, “internal account must be created before external account”) दस्तावेज़ योग्य और अंतर्निहित ज्ञान से अलग माने जाते हैं।
दस्तावेज़ीकरण की भूमिका और सीमाएँ
- स्केलिंग, onboarding, और “bus factor” कम करने के लिए दस्तावेज़ीकरण महत्वपूर्ण है, लेकिन इसे बनाना और बनाए रखना महंगा होता है और यह अक्सर पुराना पड़ जाता है।
- अत्यधिक दस्तावेज़ीकरण और हर चीज़ को “micro-document” करने की कोशिश विशेषज्ञों का मनोबल गिरा सकती है और संगठनों को धीमा कर सकती है।
- कुछ लोग दस्तावेज़ीकरण को करियर के लिए सकारात्मक मानते हैं (“grow करने के लिए खुद को replaceable बनाइए”); अन्य लोग ऐसे संस्कृतियों की ओर इशारा करते हैं जहाँ ज्ञान साझा करना आपको expendable बना देता है।
- कई उदाहरण: ऐसे wikis जो अव्यवस्थित हो जाते हैं, जिन्हें लगातार सँवारना पड़ता है, और जिन्हें अक्सर कुछ ही लोग लिखते हैं।
अंतर्निहित ज्ञान, विशेषज्ञता, और सीखना
- अंतर्निहित ज्ञान को अपरिहार्य और विशेषज्ञता के केंद्र के रूप में देखा जाता है; इसे समाप्त करने की कोशिश हानिकारक मानी जाती है।
- वास्तविक विशेषज्ञता में यह जानना शामिल है कि कौन-सा thumb rule किस संदर्भ में लागू होता है; इस mapping को लिखकर व्यक्त करना कठिन है।
- कई कौशल (math, music, design, debugging, figure skating, आदि) के लिए docs से आगे practice और mentoring की आवश्यकता बताई जाती है।
LLMs और ज्ञान-ऑरेकल्स
- कुछ लोग chats, docs, और meeting transcripts पर प्रशिक्षित LLM-संचालित “company loremasters” का सुझाव देते हैं।
- अन्य लोग संशय में हैं:
- LLMs hallucinate करते हैं और भरोसेमंद ढंग से “I don’t know” नहीं कहते।
- कच्चे meeting logs शोरयुक्त होते हैं; उच्च-गुणवत्ता वाली मानव-लिखित सामग्री फिर भी आवश्यक है।
- सुरक्षा और liability संबंधी चिंताएँ महत्वपूर्ण हैं: एक चुराया गया model या API access meeting notes, internal politics, और security details उजागर कर सकता है, और संवेदनशील घटनाओं को models से “भुलाना” कठिन होता है।
संगठनात्मक प्रथाएँ और प्रोत्साहन
- सुझाई गई प्रथाएँ: सार्वजनिक Slack channels, “newest member maintains docs,” operations से जुड़े runbooks, और डिफ़ॉल्ट रूप से खुली internal information।
- कुछ लोग औपचारिक knowledge management frameworks (जैसे DIKW) और military practices की ओर इशारा करते हैं जो documentation, automation, और shared vision को मिलाते हैं।
- समग्र भावना: अप्रलेखित स्पष्ट ज्ञान को आक्रामक रूप से प्रबंधित करें; यह स्वीकार करें कि गहरी विशेषज्ञता हमेशा कुछ हद तक अंतर्निहित ही रहेगी।