在很多軟體公司，特别是一些創業型的團隊中，對于這樣的情景可能大家都很熟悉：項目經理或者産品經理（産品狗）口頭或者簡單記錄一下軟體産品的大緻要做的功能，直接就讓研發團隊的兄弟（程式猿）去狂撸代碼。然後他就去喝茶撩妹或者回家陪老婆了...
這種撸起袖子就開幹的方式，看似簡單高效，便于直接溝通，能夠快速疊代。卻不知，發現沒有一份正規且實時更新的功能需求設計文檔，會付出三四倍的代價來彌補。
最終會引發一場産品狗和程式猿之間的“猿狗大戰”...
WHY - 為什麼需要功能需求設計說明書
在沒有功能設計文檔時，主要有如下幾個問題：
- 前期研究團隊溝通成本
如何要讓團隊裡面的所有人員對軟體産品的功能需求設計有一個共識？沒有功能設計文檔，反正我是想不出有什麼辦法。當該項目的團隊人員越多，溝通成本就變得很高。
研發人員很容易有一個通病：以為自己了解了一小塊需求就立即開始埋頭狂撸......代碼。最終很可能與項目經理和客戶真正想要的功能相差甚遠。
更可怕的，研發人員把資料庫設計好了，代碼也已經寫得差不多了，這時産品狗突然跑到程式猿這，說我們的需求要做一點變化，大家都知道，“對産品狗來說那一點變化，可能會害得程式猿撸過幾天幾夜”。那很小的變更可能導緻之前設計的資料庫，碼的代碼都不能用了。對于程式猿沒有什麼比加班加點寫了幾個月的代碼，最終被産品狗告知需求變了，代碼要删除重新寫更可怕的。估計隻能用漲工資來安慰一下那受傷的心靈了。
還有一個比較隐藏的事情是，每個程式猿都認為自己寫的代碼很牛逼（其實對于大多數人這隻是一個錯覺，你寫得代碼并不優秀），不太願意删除之前所寫的東西，總是想在原有的代碼基礎上進行修改，讓他們删除代碼比殺了他還難。
作為公司的技術負責人，我每幾天都會Code Review團隊裡面所有人的代碼，一直要求他們把不用的代碼去掉，但他們的應對方式總是加兩個
//
。注釋掉他們寫的代碼，而不是去做真正的删除動作。他們總有自己的理由，“這隻是暫時注釋掉，後面會用到”，但最終的結果是那些代碼就像屍體一樣，一直在那裡，幹擾着團隊人員正常的思路。是以我隻能強制性讓他們那些“暫時沒有用，以後會用到的代碼”幹掉 。
- 前期任務進度安排和配置設定
該文檔也是任務進度安排和配置設定的重要依據。在沒有功能需求設計文檔之前的所有任務進度計劃都是瞎扯淡，都不知道具體要做什麼東西，哪能拿出合理的任務進度計劃。如果你拿出來了，我也不相信那是經過認真分析做的進度計劃，我知道那隻是用來看上司看的。
- 中期産品經理需求變更
軟體在開發過程中難免會遇到功能的需求變更，将程式猿們召集在一起把所有的變更講一遍？當走出會議室的時候可能每個人都有自己的了解。下一場戰争已悄然臨近...
- 後期測試團隊産品測試
測試團隊應該在項目Kickoff之時就應該介入，而不是在産品開發完成之後。測試團隊應該對功能需求設計文檔充分了解，且以此來編寫具體的測試用例文檔。否則，隻能是在界面上進行簡單的表面測試，而真正的BUG并不在表面，這些BUG會藏得很深，等發現的時候可能已經造成很大的損失。測試團隊想覆寫全部的測試用例此時已經相當困難，他們甚至都不知道産品有哪些功能。
測試用例應該盡可能詳細，盡量保證測試用例走完能確定産品能上線釋出。下圖為我們在登入注冊時用到的一部分用例：
WHERE - 文檔應該放在何處
功能說明文檔一定要保持實時性，任何變更的需求，新增的需求都必須在該文檔中展現。
一隻産品狗（或一群）在編寫完文檔後，要發給項目經理、研發人員、銷售人員、營運推廣人員等人，如何保證每個人的文檔都是最新的呢？如果通過QQ，郵件等方式，是不是每次更新都要重新通知所有人：“嘿，各位兄弟，文檔作了一次修改，我給大家都重新發一份新的”。每個人電腦裡面都有好幾個版本的文檔，時間長了，自己都忘記哪個文檔是最新的；産品狗也記不清是否是所有相關的人都發了最新的文檔。
研發人員可能會說通過SVN來作版本管理啊，給每個人配置設定一個帳号。“天啊，SVN是啥？”-銷售人員、營運推廣人員估計一臉懵逼。
更好的辦法是通過團隊實時協作的雲端工具。進而實作分享和實時讨論，告别反複修改版本再發送郵件的麻煩。如果你會FQ，那你可以使用
Google Docs、
Office Online。否則你可以使用
石墨文檔 一起寫。
WHAT - 什麼是功能需求設計文檔 & 應該包含那些内容
功能需求設計文檔最重要的是描述産品所要包含的所有功能，越詳細越好，可以結合産品的原型設計圖來講解。讓項目所有相關人知道産品是什麼，包含哪些頁面，頁面如何跳轉等。
該文檔是産品經理、項目經理、研發人員、銷售人員、營運推廣人員溝通的一個橋梁，一份好的功能需求設計文檔是軟體産品是否能成功的關鍵。
考慮是該文檔的閱聽人，這份文檔不應該包含具體的程式設計技術上的說明。不管你是用C#/.NET、JAVA還是其它，這應該是另外研發團隊内部使用的一份文檔。
一般人第一反映就是去網上找一份功能需求設計文檔模闆，我個人感覺那些模闆90%根本沒有存在的必要。都太過形式化，不要沒有實際意義和模闆化的内容，隻會使文檔成為一個擺飾，反而是在浪費大家的時間。
那麼一份合格的軟體需求設計文檔應該包括哪些内容呢？
- 項目背景
項目産生的實際背景、