你這里提到的文檔，主要包括：接口開發文檔、技術框架說明文檔、新框架踩坑文檔、第三方SDK開發說明文檔、工作交接文檔等等。

接口開發文檔，這個好理解，基本上稍大點的項目，后臺開發都會提供，但大多數項目管理，都存在一個通病，那就是原始文檔能夠提供，但正確率不敢保證；后續開發、維護、增刪引發的內容變動并不會及時的更新到接口文檔中去，很不方便項目的維護。所以接口文檔要及時更新。內容應該是要細化到每個入參，每個返回字段的作用內容說明，數據格式等等。
另外，開發中我發現，后很多接口，即便是某個入口參數傳錯了，也能夠成功的拿到數據。這給后面的調試和排查問題帶來很大的干擾，后開和前端、移動端都不知道有沒有出錯，錯在哪里。這種情況應該杜絕，參數錯了就訪問-失敗，沒什么好說的，很快就能夠定位到問題在哪里，是誰的問題。
/
第三方SDK開發文檔，主要是項目中采用第三方公司提供的服務SDK時的文檔，他能夠指導開發人員完成開發工作，當對應部分功能出現問題時，能夠從中找到解決方案，因此這種文檔也頗為重要，不容有失，越詳細越好。

工作交接文檔，這個很好理解，想必也是大家最頭疼的文檔，因為十回有九回半拿到的這個文檔都是死然并卯的，毛用沒得還落人口實，看，我離開時是留有很詳細的交接文檔的。有問題怪我咯？心里總是萬馬奔騰，而且還是滿身草的那種。。。扯遠了。該文檔應該包含如下內容：該員工負責了那些功能模塊，目前這些功能模塊的開發進度，各模塊的功能說明，各模塊所在的分包packge，各功能模塊的入口，完成情況，是否有遺留的問題，重點注意事項等等。
這份文檔相當重要，它能有效的幫助接替者快速且全方位的掌握對應功能模塊的現狀，了解現狀的實際情況，掌握重點難點，不需要花費太多的時間和精力去完全踩一遍項目的坑就能上手高效地開展工作。這里以上一篇《Android開發項目管理7宗罪之四——開發任務的分派》的內容為例，前任開發中離崗時，對所負責的功能模塊完成情況只字不提，存在的問題只字不提，重點難點只字不提，只是 大概說了下各子功能所在的包，筆者無奈之下接手后，不得不從頭到尾的reView一遍他的代碼，理解開發思路，同時結合流程圖，接口文檔，需求文檔確定功能模塊的現狀，最后驚訝的發現，其實該功能只是完成了總工作量的30%。后面花了接近3周的時間才完善該功能，單單是掌握該功能模塊的現狀，梳理邏輯就花了一周。最后感嘆，將近3周，還不如我自己從 0 開始開發來得好，這樣雖然工作量多了些，但不必如此勞心勞神勞力。

最后我們說說新技術/新框架的踩坑文檔。

踩坑文檔：主要是記錄在使用新技術/新框架過程中遇到的各種問題以及解決這些問題所經歷的慘烈過程所形成的的文案。

以筆者曾經所在的一個項目為例，該項目為了節約開發時間和成本，快速集成項目，采用了螞蟻金服出品的mpass框架，該框架被用于名聲極響的支付寶等項目上。但不是開源框架，若要使用，是需要螞蟻金服收費授權的，所以市場上鮮有相關資料介紹，對其很是陌生。這不，在該項目集成mpass框架初期，遇到了各種各樣的坑，以至于團隊不相信螞蟻金服的官方文檔的真實性。而螞蟻金服派出來的售后服務伙伴能夠提供的幫助比較有限，往往不能有效的解決問題。若要螞蟻方面派出高級專家支援的話，對方人員的一切開銷級補貼都需要項目組一力承擔，成本壓力巨大。而不得不咬著牙關參考著官方文檔自己研究，直接導致了 不少員工不得不開啟9-10-6/7的工作模式而項目組規定21:00之后打出租車報銷費用，這樣一算下來，項目組近20號人打車費用都高的嚇人了。

經過數月的攻堅，框架集成成功，前端開發也成功集成進來，項目能夠得以推進。但很遺憾的是數月的攻堅工作并沒有留下任何一篇有關踩坑mpass框架集成的文檔，開發者離崗后，后續接手的人對mpass礦機一無所知，一臉懵逼，工作無法盡快開展。這時不得不向項目負責人咨詢，但項目負責人更喜歡的是這時候你能夠加班加點的看代碼，看官方文檔研究出問題來。這時候，我真想說——研究NMDNGB，加個CZ的班，加班你這也叫項目管理，球技術文檔都沒留下一個，你這不是逼人再去踩一次前面的坑么？你就這么管理的啊？算了，得過且過，將就用著吧！！！……

所以，一定要記住，重要的新技術/新框架的技術文檔、踩坑文檔一定要寫好，越詳細越好，越有利于后面工作的開展，省時省力省成本……尤其是作為項目的直接管理者，一定要大力推動這件事情，一旦項目團隊出現成員變動，這些資料就將大顯神威！！！

總結

以上是生活随笔為你收集整理的Android开发项目管理7宗罪之五——项目组个性文档文件的管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。