1樓：堅持的金牛座
寫給誰看，很重要。
技術文件是乙個很大的分類，讀者有研發、市場、運維、銷售，這麼多不同的人，用一本手冊寫不全，要是寫全在一本裡就成了字典，厚重不易檢索。你在網路上能找出一大摞的技術資訊（技術論壇、愛好者論壇、貼吧等等），閱讀和查詢比看文件來得方便。
如何接到任務後，開始寫技術文件呢？我過往工作中的一次技術文件寫作案例是，公司有一款新的通訊產品，賣點是最小的運用級路由器（只有一指頭的大小），口袋網管，和uTraffic視覺化管理。資料的讀者物件就是網路設計人員、和運維人員，如果提出由你來寫技術文件，你會先做的第一件事是什麼？
我的做法是，不懂產品就去問開發人員，清楚文件要交付的物件，相應的文件寫成什麼樣也就有了概念。
最終定為：解決方案文件+產品文件。
重點寫方案的場景組合，輕量寫操作配置，因為產品是一鍵式完成上電和功能初始配置。網設人員看解決方案文件，運維人員看產品文件的網管運維（一圖一步驟的寫內容）。
2樓：暴躁樂谷
先按照自己的理解寫完，然後給身邊不懂這塊技術的朋友看。如果朋友看不懂，那麼要不修改措辭，要不就在後面加上FAQ。
好的技術文章不是一口氣寫出來的，而是通過不斷地優化出來的。
3樓：
1、了解文件受眾以及需求，可通過訪談等形式。
2、確定文件為產品導向還是客戶導向，根據需求描述到何種程度。
3、通過思維導圖等工具列出文件大綱及編寫要點。
4樓：
IBM中國ID團隊的《Information Development》這門課剛剛把主要內容講完，還有一些簡歷、郵件等等的寫法沒有講。
像IBM、微軟這些公司，雖然動作相較於一些網際網路公司有些慢，但是文件寫的確實看上去就比別人格調要高一些，原因可能主要是他們有專門的團隊去做這件事情，再者面向企業的業務比較多，而這些業務的複雜性也要比消費級的業務大，所以寫好文件就存在於整個公司的基因裡面了。對於個人來說如果對TW感興趣到這些大公司做專業的文件寫作工作也是不錯的，如果是程式設計師的話有這樣乙個文件的意識，作為full stack的一部分，必然也是不錯的。據老師介紹，國外像CMU等等高校已經有技術文件開發這個專業了，而國內的話除了有一些像這種技術英語寫作之類的課程，並沒有成體系的培養方案。
那這些主要業務面向企業的科技公司為什麼要寫技術文件呢？眾所周知的是，現在面向普通消費者的智慧型裝置UI的設計正在變得越來越傻瓜化直覺化，即使是小孩子也可以在很短的時間內上手，但是對於企業級的產品，往往都是GUI非常複雜甚至沒有GUI只有命令列介面的，這就造成了IT從業人員（程式設計師、Administer）不可能在拿到產品之後就憑感覺直接開始用，跟我們日常的大多數產品一樣，軟體的說明書（Instruction）就必不可少了，當然，這裡就指的是技術文件。也許有一天隨著人機互動的發展，企業級產品也可以以更好的方式部署和使用，到那時技術文件或者技術文件開發這個職位也將消失吧，但在那之前或者自認為產品還沒有做到可以沒有文件就可以完全上手，還是老老實實寫好文件。
回到技術文件寫作本身DQTI的主要指標：
! Accuracy
! Clarity
! Completeness
! Concreteness
! Organization
! Retrievability
! Style
! Task orientation
! Visual effectiveness
隨便在豆瓣上搜了兩本書：
科技文件寫作實務人民郵電出版 (豆瓣)
Developing Quality Technical Information (豆瓣)
5樓：
跟@梁濤的差不多， 只不過我是用gitbook來寫， 當然是私密專案。
gitbook的好處就是：
markdown
版本控制方便管理
寫完可以生成epub、pdf、mobi、web等格式，分發給團隊其他人。
為了說的更詳細，本人寫了一篇blog：使用Gitbook來編寫你的Api文件悟道集
6樓：Zakk
關於技術寫作的書很多，技術寫作專業出身的同事曾經推薦過的一本叫《Technical Communication》，目前已經出到第十版了。
7樓：
在此只說專案文件的一些個人心得：
1. 弄清讀者是誰：給終端使用者（小白）的、給系統維護人員、給後來的技術人員交接的的文件肯定不一樣，給小白的重截圖，給維護的重操作，交接的重原理。
2. 切換「無知者」模式：很多東西是在做專案的過程中試錯積累出來的。
做著做著：這麼幹原來不行啊，應該這樣這樣，改設計！做著做著：
哎呀，原來有這個問題沒有考慮到，現在加進去，改設計！做著做著：哦？
什麼？客戶要改需求？好吧，我改設計！
這樣下來大型的IT專案做到最後，和最開始的設計已經大相徑庭了，按照原來設計的思路來寫文件肯定是不行的，按照時間順序把修改加上會更加混亂。寫文件的時候需要切換到「無知者」模式，把自己想象成乙個剛剛接受專案要開始設計的人，面對已知的這些「新要求」和對技術全新的理解，重新寫乙份文件，這樣才能脈絡清晰，可讀性高。
3. 遵循標準構架：大型專案牽扯的東西多，有實際的裝置有虛的概念，有使用者介面也有關鍵性配置，雜七雜八什麼都有，如果不按照乙個標準構架來寫文件，很容易就眉毛鬍子一把抓。
這時候就一定要找乙個標準構架，比如OSI七層構架，TCP-IP四層構架等等，從上到下或者從下到上，寫著也方便，看著也舒服。
8樓：
我覺得這個問題很有趣在於它提出了乙個特殊的情況：
並不是所有時候都是內行更有，或者只有內行才有發言權。
找內行看，本來有地方邏輯或者語言之類有不清楚，可能自己就腦補了。
找個門外漢讀讀這技術文件，一下子就看得出寫的好不好了。
而且有時候是「哪怕技術性專業性太強的地方讀不懂」，都依然能讀出好壞的。
9樓：梁濤
宣傳一下自己寫的東西，雖然感覺一點也不完美。
1. 一圖勝千言（http://www.
ituring.com.cn/article/17520
）：2. 大聲朗讀自己寫的每一行字，不爽的、不通的，改之。
3. 「最好的文字來自經常的修改。」
10樓：胡浩
最近做完乙個專案，好好的整理了一下文件。我覺的，寫技術文件，可以整理自己的思路，對這個專案中的知識點，要知其然，更要知其所以然。寫文件，首先是要明確這個文件的主題，主要說清楚乙個什麼問題。
一篇文件如果要涉及多個問題的話，最好先分別簡要介紹一下，然後另寫一篇較詳細的文件，來補充被引用的文件，這樣下來，每篇文件都各有所專，思路的話可以清晰一點。
在寫文件時，要結合專案的需求和大概的實現流程，最好是貼圖來解釋一些比較難理解的地方，有圖有注釋，這樣更好理解。對於文件中，自己認為比較重要的地方，需要用紅色標記出來，這樣讓看的人有重點。
看過公司的規範文件，上面章節，修訂記錄，目標關注，頁首頁尾都很正規，最後的附錄恰到好處，而且都是pdf版的。建議先把文件寫出來，給不了解這個文件主題的人審閱，看看他能理解個大概不？如果不能，詢問意見並且做二次修改。
文件的內容在引用網上資料的同時，要融入自己的思考，結合專案需要，提煉自己的中心句，讓別人看的話，有的放矢。
如果自己覺的很滿意了，就把doc格式轉成pdf格式的，然後再發布到共享中去，我總是覺的，doc格式的就是沒有pdf格式的看得爽。
嗯嗯，目前就想到這麼多。
11樓：吳思揚
作為乙個曾以超詳細文件而遭人白眼的互動設計人員，我最大的敗筆，在於寫文件只在乎自己有沒有成就感，而不是別人看不看得懂、能不能順利理解，後果是，文件雖全，但沒人有耐心理解消化，最後還是都跑來問我，不勝其煩。
得出的乙個實際教訓是，把厚的做薄。別光顧著文件好看、結構清晰，而去問看文件的人，這麼寫能不能看懂，用什麼形式寫更容易懂，哪些地方不用太詳細，哪些地方要多說幾句。
如果還處於做不厚的境況，就還是先老老實實有一句寫一句吧， MECE 原則、金字塔原理是基本功。
如何寫好織體？
張暉 四部和聲題做織體先加入簡單節奏型，經過音或者助音形態。進而可以使用節奏錯位使各聲部形成簡單的自由對位形態，但此時要注意有些聲部進行在複調概念中會形成平行聲部。另一種密集排列方式，可以仿寫各種奏鳴曲或者練習曲的分解方式進行織體變化。 Rax Xu 題主的問題不是在於織體死板，而在於旋律和和聲的寫...
如何寫好述職報告？
昨日依然繽紛著 首先要擬定好標題 前言 主體三個版塊。標題一般寫人名述職報告就可以。前言一般包括四個方面 崗位職責，工作成果，下一階段計畫，總結分享。崗位職責包括自己從何時起擔任何職，主要負責什麼工作 工作成果是對這一階段工作成果的展示分享 下階段計畫是針對部門發展及自身提高進行的規劃 總結分享是對...
如何寫好留學簡歷？
BJ Cheung 貼兩個UPenn Career Center給的CV模板Master s student resume sampleshttps careerservices.upenn.edu preparing effective resumes phd postdoc resume sam...