關於技術文件

關於寫技術文件，我覺得是很多做技術的同學頭疼的，因為寫起來確實有很多注意的細節，很花時間和精力，而反過來說，做技術的同學更頭疼的是，工作中竟然沒有文件說明，沒有了文件那麼就是個人主義了，所以文件的事情對很多人來說是一種比較糾結的情況，有些雞肋的感覺。

從我的理解來看，文件是對你工作成果的一個輸出，我的認知，文件大體有幾類：

1. 理念型文件，不會描述細節，是對一種思想的闡述

2. 設計型文件，不會太籠統，會有一些整體的設計，會對純思想的內容做一層抽象，結合應用場景的解決方案。

3. 操作型文件，裡面會有很多的技術細節

4. 流程型文件，這種文件的主要是做一些鋪墊和補充，比如有些內容簡介，制度規約之類的。

如果是上面的文件中，我覺得很多人對設計型文件和操作型文件會更感興趣，而對上領導來說，其實對於理念型和設計型文件更感興趣。

所以不同的角度看待文件的感覺和初衷還是有一定的差別的，越是細節的文件可能更新頻率和內容變化就越大，而作為通泛統一的思想和設計，可能會比較穩定。

你說寫文件好不好，我覺得這個問題確實得看工作的情況。對很多人來說寫了額大量的流程型文件，他會覺得比較空虛，這種不充實的感覺主要是因為他沒有涉及到做一件事情的核心，只是做了一些外圍的事情，這個時候你說文件好不好，肯定不好，在我早期的工作裡面，其實我是比較排斥這類文件的，但是作為工作的流程需要，還是需要這樣一個形式，所以這可能不是一件好事，但是為了工作能夠順利開展，事情還得做，文件還得補充。

而工作中，你的工作成果和技術積累，其實就是透過文件的積累整理出來的。我舉三個例子。

首先第一個是文件庫的事情。

    文件庫是很多公司都在使用的技術手段，如果我們要重新設計一個文件庫，就會把他規劃的很細很全，但是實際去寫文件的時候，會發現事情比預想的要難一些，因為從業務和技術兩個維度，技術上都可以實現，但是具體去操作的時候就有很大的差別。

第二個是運維開發文件的事情。

    為了提高公司同事對於運維開發的一些基礎技能提升，我和兄弟部門發起了一個運維開發的培訓。但是培訓畢竟會有一種流於形式的感覺，很多人過來聽就是單純的來聽聽，也壓根沒打算做出什麼樣的東西來。所以從理念和態度上來說，這個事情的意義和實際的應用能不能很好的結合起來，預期和結果還是會有差距的。所以我們準備對已有的技術分享做一層沉澱，透過一些內容上的調整和梳理行程一個較為系統的文件，如果新員工來了之後，就會少走一些彎路。這個時候這個文件的重要性就體現出來了。

第三個是工作成果文件的事情。

比如我們前期做了很多的預研工作，也做了很多的測試，最終從報告的輸出來看，其實文件的結論部分和思想的總結就是這個文件的核心了。

所以說前期我畫了很多的腦圖，規劃圖，設計圖，同事感覺我想的已經很明白了，但是實際去做的時候會有各種因素的干擾，最終事情沒有預想的那麼好。從工作成果的角度來看，你似乎很難拿得出一些亮點成績來。這對我們的工作積極性和對於工作的影響是有很大，沒有文件的產出，你的成果就很可能不被重視起來，同時你工作的時候也會比較尷尬，可謂是困難重重，我早期的工作就吃了很大的虧，很多事情浮於表面，一直美歐推動起來，和這個還是有很大的差距的。

如果說文件的編寫有什麼技巧，我覺得一定是有一個系統的認識，如果為了寫文件而寫文件，那麼文件的質量會有很大差距，這種情況是儘可能少寫這類文件。