沒有功能需求設(shè)計文檔？對不起，拒絕開發(fā)！
在很多軟件公司，特別是一些創(chuàng)業(yè)型的團隊中，對于這樣的情景可能大家都很熟悉：項目經(jīng)理或者產(chǎn)品經(jīng)理(產(chǎn)品狗)口頭或者簡單記錄一下軟件產(chǎn)品的大致要做的功能，直接就讓研發(fā)團隊的兄弟(程序猿)去狂擼代碼。然后他就去喝茶撩妹或者回家陪老婆了...
這種擼起袖子就開干的方式，看似簡單高效，便于直接溝通，能夠快速迭代。卻不知，發(fā)現(xiàn)沒有一份正規(guī)且實時更新的功能需求設(shè)計文檔，會付出三四倍的代價來彌補。
最終會引發(fā)一場產(chǎn)品狗和程序猿之間的“猿狗大戰(zhàn)”...
WHY - 為什么需要功能需求設(shè)計說明書
在沒有功能設(shè)計文檔時，主要有如下幾個問題：
- 前期研究團隊溝通成本
如何要讓團隊里面的所有人員對軟件產(chǎn)品的功能需求設(shè)計有一個共識?沒有功能設(shè)計文檔，反正我是想不出有什么辦法。當該項目的團隊人員越多，溝通成本就變得很高。
研發(fā)人員很容易有一個通?。阂詾樽约毫私饬艘恍K需求就立即開始埋頭狂擼......代碼。最終很可能與項目經(jīng)理和客戶真正想要的功能相差甚遠。
更可怕的，研發(fā)人員把數(shù)據(jù)庫設(shè)計好了，代碼也已經(jīng)寫得差不多了，這時產(chǎn)品狗突然跑到程序猿這，說我們的需求要做一點變化，大家都知道，“對產(chǎn)品狗來說那一點變化，可能會害得程序猿擼過幾天幾夜”。那很小的變更可能導致之前設(shè)計的數(shù)據(jù)庫，碼的代碼都不能用了。對于程序猿沒有什么比加班加點寫了幾個月的代碼，最終被產(chǎn)品狗告知需求變了，代碼要刪除重新寫更可怕的。估計只能用漲工資來安慰一下那受傷的心靈了。
還有一個比較隱藏的事情是，每個程序猿都認為自己寫的代碼很牛逼(其實對于大多數(shù)人這只是一個錯覺，你寫得代碼并不優(yōu)秀)，不太愿意刪除之前所寫的東西，總是想在原有的代碼基礎(chǔ)上進行修改，讓他們刪除代碼比殺了他還難。
作為公司的技術(shù)負責人，我每幾天都會Code Review團隊里面所有人的代碼，一直要求他們把不用的代碼去掉，但他們的應對方式總是加兩個//。注釋掉他們寫的代碼，而不是去做真正的刪除動作。他們總有自己的理由，“這只是暫時注釋掉，后面會用到”，但最終的結(jié)果是那些代碼就像尸體一樣，一直在那里，干擾著團隊人員正常的思路。所以我只能強制性讓他們那些“暫時沒有用，以后會用到的代碼”干掉 。
- 前期任務進度安排和分配
該文檔也是任務進度安排和分配的重要依據(jù)。在沒有功能需求設(shè)計文檔之前的所有任務進度計劃都是瞎扯淡，都不知道具體要做什么東西，哪能拿出合理的任務進度計劃。如果你拿出來了，我也不相信那是經(jīng)過認真分析做的進度計劃，我知道那只是用來看領(lǐng)導看的。
- 中期產(chǎn)品經(jīng)理需求變更
軟件在開發(fā)過程中難免會遇到功能的需求變更，將程序猿們召集在一起把所有的變更講一遍?當走出會議室的時候可能每個人都有自己的理解。下一場戰(zhàn)爭已悄然臨近...
- 后期測試團隊產(chǎn)品測試
測試團隊應該在項目Kickoff之時就應該介入，而不是在產(chǎn)品開發(fā)完成之后。測試團隊應該對功能需求設(shè)計文檔充分了解，且以此來編寫具體的測試用例文檔。否則，只能是在界面上進行簡單的表面測試，而真正的BUG并不在表面，這些BUG會藏得很深，等發(fā)現(xiàn)的時候可能已經(jīng)造成很大的損失。測試團隊想覆蓋全部的測試用例此時已經(jīng)相當困難，他們甚至都不知道產(chǎn)品有哪些功能。
測試用例應該盡可能詳細，盡量保證測試用例走完能確保產(chǎn)品能上線發(fā)布。下圖為我們在登錄注冊時用到的一部分用例：
WHERE - 文檔應該放在何處
功能說明文檔一定要保持實時性，任何變更的需求，新增的需求都必須在該文檔中體現(xiàn)。
一只產(chǎn)品狗(或一群)在編寫完文檔后，要發(fā)給項目經(jīng)理、研發(fā)人員、銷售人員、運營推廣人員等人，如何保證每個人的文檔都是***的呢?如果通過QQ，郵件等方式，是不是每次更新都要重新通知所有人：“嘿，各位兄弟，文檔作了一次修改，我給大家都重新發(fā)一份新的”。每個人電腦里面都有好幾個版本的文檔，時間長了，自己都忘記哪個文檔是***的;產(chǎn)品狗也記不清是否是所有相關(guān)的人都發(fā)了***的文檔。
研發(fā)人員可能會說通過SVN來作版本管理啊，給每個人分配一個帳號。“天啊，SVN是啥?”-銷售人員、運營推廣人員估計一臉懵逼。
更好的辦法是通過團隊實時協(xié)作的云端工具。從而實現(xiàn)分享和實時討論，告別反復修改版本再發(fā)送郵件的麻煩。如果你會FQ，那你可以使用Google Docs、Office Online。否則你可以使用石墨文檔、一起寫。
WHAT - 什么是功能需求設(shè)計文檔 & 應該包含那些內(nèi)容
功能需求設(shè)計文檔最重要的是描述產(chǎn)品所要包含的所有功能，越詳細越好，可以結(jié)合產(chǎn)品的原型設(shè)計圖來講解。讓項目所有相關(guān)人知道產(chǎn)品是什么，包含哪些頁面，頁面如何跳轉(zhuǎn)等。
該文檔是產(chǎn)品經(jīng)理、項目經(jīng)理、研發(fā)人員、銷售人員、運營推廣人員溝通的一個橋梁，一份好的功能需求設(shè)計文檔是軟件產(chǎn)品是否能成功的關(guān)鍵。
考慮是該文檔的受眾，這份文檔不應該包含具體的編程技術(shù)上的說明。不管你是用C#/.NET、JAVA還是其它，這應該是另外研發(fā)團隊內(nèi)部使用的一份文檔。
一般人***反映就是去網(wǎng)上找一份功能需求設(shè)計文檔模板，我個人感覺那些模板90%根本沒有存在的必要。都太過形式化，不要沒有實際意義和模板化的內(nèi)容，只會使文檔成為一個擺飾，反而是在浪費大家的時間。
那么一份合格的軟件需求設(shè)計文檔應該包括哪些內(nèi)容呢?
- 項目背景
項目產(chǎn)生的實際背景、具體的運用場景、大致要解決什么樣的問題、針對的閱讀對象、版本修改記錄、文檔作者以及修改人信息。
- 詳細的功能點描述
寫明產(chǎn)品所包含的所有功能點，對功能、界面、接口的描述一定要充分詳細，每處可以交互的地方都要給出具體的說明。再次強調(diào)，一定要詳細描述每一個頁面所擁有的功能。
- 產(chǎn)品不包含的功能點說明
除了寫明產(chǎn)品所包含的所有功能點外，還應該寫明軟件所不包含的功能，這一點也很重要。
- 使用場景(畫面感)
將復雜的業(yè)務邏輯融入到具體的使用場景中，更容易讓項目經(jīng)理、研發(fā)人員、銷售人員、運營推廣人員不同背景的人產(chǎn)生共識。
- 流程圖
大家都知道“一圖勝千言”，能用圖說明的盡量用圖來說明，只通過大量枯燥的文字可能效果并不太好。流程圖是一種用圖形表示邏輯和算法的工具，特別對研發(fā)人員擼代碼很有幫助。
Windows用戶可以使用Visio，Mac用戶可以使用OmniGraffle，還可以使用免費在線作圖,實時協(xié)作工具ProcessOn。
我之前就用ProcessOn畫了一個設(shè)置了緩存的網(wǎng)絡(luò)請求的流程圖，這里作個參考：
人員角色“實例化”
跟上面提到的“畫面感”相結(jié)合，將人員和角色能夠?qū)嵗?。比如我們的產(chǎn)品要實現(xiàn)如下功能，有兩種表達方式：
醫(yī)生給患者測量血壓，并記錄到系統(tǒng)中。
上海華山醫(yī)院腎內(nèi)科的王主任醫(yī)生在給32號病區(qū)1號病床的患者劉阿姨測量血壓，將測量到的血壓100/70mmHg輸入到透析管理系統(tǒng)。
哪種方式更便于理解?特別是對醫(yī)療知識不太了解的碼農(nóng)們。當然可能有人覺得***種方式更簡潔?？赡苁俏遗e的例子不夠好，也可能是我的理解能力不夠強。(但不要懷疑我的智商!哈哈哈...)
結(jié)合產(chǎn)品原型設(shè)計圖
產(chǎn)品原型設(shè)計圖可以粗枝大葉地產(chǎn)品大致的框架。便于項目經(jīng)理、研發(fā)人員、銷售人員、運營推廣人員等人在產(chǎn)品未開發(fā)之前對產(chǎn)品有一個相對直觀的認識。沒有一個原型圖，想到這幫人拉到同一個頻道溝通一定是不可能的事。(如果你做到了，那么趕緊把你的簡歷發(fā)我，我決定錄用你!)
常用的原型設(shè)計工具有墨刀、Mockplus、Axure。
扯了這么多，來個例子吧。
本軟件是給北京某醫(yī)院集團腎內(nèi)科透析患者所使用的軟件，包括院內(nèi)管理系統(tǒng)、院外大數(shù)據(jù)平臺、醫(yī)護端APP、患者端APP...
使用場景一：
腎內(nèi)科的醫(yī)生王醫(yī)生給31號病床劉阿姨進行透析上機操作，王醫(yī)生在院內(nèi)透析管理系統(tǒng)上點擊上機操作，信息會傳遞到院外的大數(shù)據(jù)平臺以及醫(yī)護端APP、患者端APP上...
劉阿姨患者的家屬登錄到患者端APP后，可以實時查看劉阿姨透析過程中的所有信息，還可以查看血壓、血糖、體重等歷史數(shù)據(jù)...
當劉阿姨在家中通過藍牙血壓計測量血壓時，自動同步到醫(yī)院內(nèi)部，如果劉阿姨的血壓超過預先設(shè)置的值，院內(nèi)的王醫(yī)生則會在自己的手機上查看到劉阿姨的血壓異常報警信息，王醫(yī)生可以立即跟劉阿姨的家屬進行實時溝通...
...<此處省略N字>...
本軟件(v1.0.1版本)不包括的功能需求如下：
醫(yī)生與患者的實時IM
醫(yī)生排班設(shè)置
修改密碼
患者積分
功能模塊詳細描述：
一、APP登錄頁面
由于本產(chǎn)品不存在患者自己注冊的場景，所有的患者錄入都發(fā)生在院外透析系統(tǒng)中，患者及家屬在院外只需要輸入相應的手機號，即可登錄系統(tǒng)。
登錄頁面只有兩個輸入框，一個手機號，一個密碼。
當用戶要輸入手機號時，手機應該彈出純數(shù)字鍵盤，最多只能輸入手機號固定的11位。密碼最多輸入10位。
當用戶點擊登錄時，APP與后臺服務器進行交互：
不輸入手機號和密碼，直接點擊登錄按鈕，應該提示用戶輸入手機號和密碼。
輸入手機號但不輸入密碼，點擊登錄，提示“請輸入密碼”。
輸入不正確的手機號，點擊登錄，應該提示“不存在該用戶”。
輸入小于11位的手機號，應該提示“請輸入正確的手機號”。
二、登錄后首頁
下圖是左側(cè)是一個首頁，右側(cè)是一個點擊透析預警的詳細頁面:
首頁包括功能點：
- 資訊信息輪播 首頁頂部資訊信息輪播功能，點擊可以跳轉(zhuǎn)到新的頁面可以查看資訊詳情。
- 病情咨詢 點擊“病情咨詢”模塊，患者查看向指定的醫(yī)生了解自己的病情。
- 透析記錄 點擊透析記錄，患者可以隨時隨地查看自己的過往透析記錄。
- 食物速查 點擊食物速查，可以查看所有類別的食物成份含量。
- 透析上下機實時信息列表 當患者在醫(yī)院內(nèi)進行透析上下機等操作時，會記錄患者的透析上機時間 、下機時間等信息。點擊其中的一條記錄，跳轉(zhuǎn)到透析詳情頁面，如上圖右側(cè)所示。
HOW - 如何保證文檔質(zhì)量
要保證文檔能夠?qū)崟r更新同步，而不是疲于應付。那就是讓大家都通過該文檔來進行溝通，誰有問題直接去看文檔，需求一旦變更首先就更新到文檔。
研發(fā)人員嚴格按文檔上的描述來開發(fā)，在沒有文檔之前，對不起，拒絕開發(fā)!任何口頭、QQ或郵件上的新的功能需求一概不理!提前是產(chǎn)品狗要比較給力，否則老板還是會讓你狂擼代碼...
【本文為51CTO專欄作者“朱成林”的原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
