有一種場景大家可能會覺得似曾相識，項目經理（產品狗）口頭或者簡單記錄一下軟件產品大致要做的功能，然后就直接讓研發(fā)團隊的人員（程序猿）去狂擼代碼，接著他自己就去喝茶撩妹或者回家陪老婆了（當然小編不會告訴你，寶原科技的項目經理簡直不要太負責，喝茶撩妹倒沒有，溝通到暫時性失聲好么......）。

這種擼起袖子就開始的方式，看似簡單高效，便于直接溝通，能夠快速迭代。殊不知，沒有一份正規(guī)且實時更新的功能需求設計文檔，后期將會付出三四倍的代價去補救......

最終會引發(fā)一場產品狗和程序猿之間的“猿狗大戰(zhàn)”

WHY——為什么需要功能需求設計說明書

在沒有功能設計文檔時，主要有下面幾個問題：

前期研究團隊溝通成本

如何要讓團隊里面的所有人員對軟件產品的功能需求設計達成共識？

研發(fā)人員有一個通病：以為自己了解了一小塊需求就立即開始埋頭狂擼......代碼。最終很可能與項目經理和客戶真正想要的功能相差甚遠。

于是，當研發(fā)人員把數據庫設計好了，代碼也已經寫得差不多了，這時產品狗突然通知，說我們的需求要做一點變化。大家都知道，對程序猿來說，那一點變化，可能會害得程序猿的整個世界都不好了！之前設計的數據庫、寫的代碼都不能用了！所以真的沒有什么比加班加點寫了幾個月的代碼，最終被產品狗告知需求變了，代碼要刪除重新寫更可怕的事了（如果有，那就是連工資都不漲了~）......

還有一個比較隱諱的事情是，每個程序猿都特么認為自己寫的代碼很牛逼（其實對于大多數人這只是一個錯覺，醒醒吧，你寫的代碼并不優(yōu)秀），不太愿意刪除之前所寫的東西，所以總是想在原有的代碼基礎上進行修改。讓他們刪除代碼？比殺了他還難！

但是小編公司的就很不一樣的了，在項目經理了解到客戶的需求后，他每天都會Code Review團隊里面所有人的代碼，一直要求他們把不用的代碼去掉，雖然手頭同時有好幾個項目在忙，但大家的極力配合實現了事半功倍，在客戶規(guī)定的時間內高效的完成了任務。

前期任務進度安排和分配

該文檔也是任務進度安排和分配的重要依據。在沒有功能需求設計文檔之前的所有任務進度計劃都是瞎扯淡，都不知道具體要做什么東西，哪能拿出合理的任務進度計劃。如果你拿出來了，我也不相信那是經過認真分析做的進度計劃，我知道那只是用來給領導看的。

中期產品經理需求變更

軟件在開發(fā)過程中難免會遇到功能的需求變更，此時將程序猿們召集在一起把所有的變更講一遍？接著走出會議室的時候可能每個人都有自己的理解。于是下一場戰(zhàn)爭已悄然臨近......

后期測試團隊產品測試

所以，測試團隊在項目Kickoff 之時就應該介入，而不是在產品開發(fā)完成之后。

前期測試團隊就應該對功能需求設計文檔充分了解，且以此來編寫具體的測試用例文檔。否則，只能是在界面上進行簡單的表面測試。而且真正的BUG 并不在表面，這些BUG 會藏得很深，最后等到發(fā)現的時候可能已經造成很大的損失。

至此，讓甚至都不知道產品有哪些功能的測試團隊來收尾，會造成他們想覆蓋全部的測試用例都會變得異常艱難！

測試用例應該盡可能詳細，盡量保證測試用例走完能確保產品能上線發(fā)布。下圖為我們在登錄注冊時用到的一部分用例：

WHERE——文檔應該放在何處

功能說明文檔一定要保持實時性，任何變更的需求，新增的需求都必須在該文檔中體現。

產品狗在編寫完文檔后，要發(fā)給項目經理、研發(fā)人員、銷售人員、運營推廣人員等等，如何保證每個人的文檔都是最新的呢？如果通過QQ、郵件等方式，是不是每次更新都要重新通知所有人：“嘿，各位兄弟，文檔作了一次修改，我給大家都重新發(fā)一份新的”。每個人電腦里面都有好幾個版本的文檔，時間長了，自己都忘記哪個文檔是最新的；產品狗也記不清是否是所有相關的人都發(fā)了最新的文檔......

研發(fā)人員可能會說通過SVN 來作版本管理啊，給每個人分配一個帳號?！疤彀?，SVN 是啥？”-銷售人員、運營推廣人員估計一臉懵逼。

更好的辦法是通過團隊實時協(xié)作的云端工具。從而實現分享和實時討論，告別反復修改版本再發(fā)送郵件的麻煩。如果你會FQ，那你可以使用Google Docs、Office Online。否則你可以使用石墨文檔、一起寫。

WHAT——什么是功能需求設計文檔&應該包含哪些內容

功能需求設計文檔最重要的是描述產品所要包含的所有功能，越詳細越好，可以結合產品的原型設計圖來講解。讓項目所有相關人知道產品是什么，包含哪些頁面，頁面如何跳轉等。

該文檔是產品經理、項目經理、研發(fā)人員、銷售人員、運營推廣人員溝通的一個橋梁，一份好的功能需求設計文檔是軟件產品是否能成功的關鍵。

考慮是該文檔的受眾，這份文檔不應該包含具體的編程技術上的說明。不管你是用C#/.NET、JAVA 還是其它，這應該是另外研發(fā)團隊內部使用的一份文檔。

一般人第一反映就是去網上找一份功能需求設計文檔模板，我個人感覺那些模板90% 根本沒有存在的必要，太過形式化，沒有實際意義和模板化的內容，只會使文檔成為一個擺飾，更加浪費大家的時間。

那么一份合格的軟件需求設計文檔應該包括哪些內容呢？

項目背景

項目產生的實際背景、具體的運用場景、大致要解決什么樣的問題、針對的閱讀對象、版本修改記錄、文檔作者以及修改人信息。

詳細的功能點描述

寫明產品所包含的所有功能點，對功能、界面、接口的描述一定要充分詳細，每處可以交互的地方都要給出具體的說明。再次強調，一定要詳細描述每一個頁面所擁有的功能。

產品不包含的功能點說明

除了寫明產品所包含的所有功能點外，還應該寫明軟件所不包含的功能，這一點也很重要。

使用場景（畫面感）

將復雜的業(yè)務邏輯融入到具體的使用場景中，更容易讓項目經理、研發(fā)人員、銷售人員、運營推廣人員不同背景的人產生共識。

流程圖

大家都知道“一圖勝千言”，能用圖說明的盡量用圖來說明，只通過大量枯燥的文字可能效果并不太好。流程圖是一種用圖形表示邏輯和算法的工具，特別對研發(fā)人員擼代碼很有幫助。

Windows 用戶可以使用Visio，Mac用戶可以使用 OmniGraffle，還可以使用免費在線作圖,實時協(xié)作工具 ProcessOn。

我之前就用ProcessOn 畫了一個設置了緩存的網絡請求的流程圖，這里作個參考：

人員角色“實例化”

跟上面提到的“畫面感”相結合，將人員和角色能夠實例化。

比如我們的產品要實現如下功能，有兩種表達方式：

醫(yī)生給患者測量血壓，并記錄到系統(tǒng)中。

上海華山醫(yī)院腎內科的王主任醫(yī)生在給32號病區(qū)1號病床的患者劉阿姨量血壓，將測量到的血壓100/70mmHg輸入到透析管理系統(tǒng)。

哪種方式更便于理解？特別是對醫(yī)療知識不太了解的碼農們。當然可能有人覺得第一種方式更簡潔?？赡苁俏遗e的例子不夠好，也可能是我的理解能力不夠強。（但不要懷疑我的智商！哈哈哈...）

結合產品原型設計圖

產品原型設計圖可以幫助粗枝大葉地了解產品大致的框架，便于項目經理、研發(fā)人員、銷售人員、運營推廣人員等人在產品未開發(fā)之前對產品有一個相對直觀的認識。沒有一個原型圖，就想把這幫人拉到同一個頻道溝通一定是不可能的事?。ㄈ绻阕龅搅耍瑏韥韥?，我們公司就急缺您這樣的人才?。?/p>

最后，常用的原型設計工具有墨刀、Mockplus、Axure。

HOW——如何保證文檔質量

要保證需求設計文檔能夠實時更新同步，而不是疲于應付。然后讓大家都通過該文檔來進行溝通，誰有問題直接去看文檔，需求一旦變更首先就更新到文檔。

接著研發(fā)人員就應該嚴格按文檔上的描述來開發(fā)，所以產品的正確打開方式，NO功能需求文檔，NO開發(fā)!

任何口頭、QQ或郵件上的新的功能需求一概不理！

然后另一個比較重要的前提是產品狗要比較給力，否則老板還是會讓你狂擼代碼...