第六步：撰寫詳細(xì)的需求文檔。 
　　《框架圖》下載西喬的模版?？梢暬憩F(xiàn)產(chǎn)品的框架、布局、細(xì)節(jié)、部分交互。 
　　《流程圖》》下載西喬的模版。理出產(chǎn)品的邏輯關(guān)系。
　　《功能需求文檔》》下載西喬的模版。 羅列 功能、應(yīng)用、交互上細(xì)節(jié)，分離基礎(chǔ)件，作為開發(fā)分工和系統(tǒng)及數(shù)據(jù)構(gòu)造的 基礎(chǔ)文檔。 
　　第七步：商討需求文檔 
　　盡量召集甲方所有相關(guān)部門的負(fù)責(zé)人 一起召開這次會議，商討需求文檔。 
　　在閱讀到你的需求文檔之前，可能甲方的大部分人都對產(chǎn)品沒有可視和具象的理解。也從未關(guān)注到細(xì)節(jié)和邏輯關(guān)系。所以需要產(chǎn)品經(jīng)理從全局角度和邏輯線索講解文檔。 
　　更可能發(fā)生的狀況是，沒有人堅持看完或仔細(xì)看過你寫的文檔。
　　所以這次會議是一場耐心和體力的考研。
　　文檔作者需要 分別向各個部門指出他們需要關(guān)注和拍板的地方，聽取他們的建議，將任何變動要求都分類記錄。 
　　安撫情緒。解答困惑?？刂菩枨笞儎印?nbsp;
　　第八步：定稿需求文檔 
　　分職能（部門）類建立表格文檔。將會議協(xié)商中所有 分歧性意見和變動意見 都逐條寫下。抄送所有相關(guān)負(fù)責(zé)人。并要求他們糾正分歧和確認(rèn)變動。 
　　所有會議中可能被提出但是未出現(xiàn)在此郵件文檔中的 意見，不會列入需求文檔中。當(dāng)然允許可以書面反饋補(bǔ)充。 
　　根據(jù)確認(rèn)過的反饋回復(fù)，修改需求文檔。直到需求文檔定稿。 
　　協(xié)商討論和文檔修改可能經(jīng)過2~3輪。所以需要項目經(jīng)理提前提醒客戶注意，搜集需求和文檔定稿的 時間線里程碑。如果這個階段耗時過久，會嚴(yán)重延誤整個項目進(jìn)度。要求客戶盡量集中地謹(jǐn)慎地提出建議和修改。 
　　三種武器： 
　　需求問卷：無論是面對專業(yè)還是不專業(yè)的客戶，交流中都有很多沒考慮到的遺漏點，這些他們看不到的點往往是最關(guān)鍵的點，也有可能是被客戶故意規(guī)避掉的點。 
　　此時撰寫一份需求問卷非常有效。
　　問卷里提出重要的全局性的問題，需要客戶逐條書面回答。 
　　某些問題可以提供多個選項答案，及補(bǔ)充區(qū)域。
　　某些問題 需要確鑿的態(tài)度，Yes或NO。 
　　不要提出需要客戶寫一大段表述性文字的問題。 
　　需求問卷精簡扼要，有針對性，重要，不要浪費客戶的時間，不要把寫字的工作量丟給客戶。 
　　書面確認(rèn)： 
　　書面確認(rèn) 一方面包括 ：所有討論結(jié)果、建議 和變更 都要有書面文字備查。電話和開會上說說的這些口頭表達(dá)都沒有效應(yīng)。這一點一開始你就要聲明，甚至有必要寫在合同里。 
　　另一方面包括：你要盡量提供書面的可視化的東西 來讓甲方確認(rèn)。 
　　甲方很難完備或是提供適合工程使用的文檔。所以千萬不要在項目初期的需求文檔上省懶。 
　　郵件抄送： 
　　郵件抄送一種明確職責(zé)的方法。對方可能不看你的郵件，但代表你告之過。 
　　盡可能地抄送重要郵件給戰(zhàn)略層，可以能避免一些重大問題的出現(xiàn)。
　　結(jié)語：
　　到此看起來，搜集和確定需求真是一件耗時耗力的工程。 
　　其實在理想的工程項目時間分配中，1/3的時間用于確定所有需求和開發(fā)文檔。 1/2的時間用于測試，解決bug，安全測試、壓力測試等。真正用于開發(fā)的只應(yīng)該占1/6。 
　　當(dāng)然web項目的開發(fā)肯定達(dá)不到這個理想狀況。但是也由此可見需求階段的重要性和工作量。這一階段省一分力或有一分遺漏，到了項目后期可能需要十分力來彌補(bǔ)。 
作者：西喬 項目經(jīng)理 產(chǎn)品顧問  創(chuàng)立Magicome公司提供web技術(shù)開發(fā)項目外包開發(fā)及產(chǎn)品端顧問咨詢。  聯(lián)系方式：arthur369@gmail.com

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html