那邊把需求收集過(guò)來(lái)，然后需要利用自己的語(yǔ)言來(lái)對(duì)問(wèn)題進(jìn)行描述。若在這個(gè)描述的過(guò)程中，CIO站在自己的角度去思考，則往往會(huì)引起一些不必要的歧義。筆者認(rèn)為，CIO在整理需求的時(shí)候，最好能夠站在用戶的角度去思考問(wèn)題。同時(shí)，需求整理好后，最好能夠把自己整理的需求再讓用戶去確認(rèn)一遍。讓他們審核一下，看看書面需求分析與他們的想法是否有出入。
　　二是在需求描述中，最好能夠配有實(shí)際案例。有時(shí)候，有些需求確實(shí)很難描述清楚。或者因?yàn)檎Z(yǔ)言組織的不好，以及文化、工作背景的不同，不同的人看需求報(bào)告確實(shí)會(huì)產(chǎn)生不同的理解。為此，筆者認(rèn)為，最好能夠在需求中配上具體的案例。通過(guò)案例描述來(lái)把需求認(rèn)識(shí)的歧義降至到最低。如當(dāng)CIO描述“銷售訂單來(lái)對(duì)物料進(jìn)行追蹤”這個(gè)需求時(shí)，可以配上具體的案例。例如企業(yè)有一張銷售訂單，分別生成四張采購(gòu)訂單，需要購(gòu)買A、B、C、D四個(gè)物料。其中，A物料因?yàn)閭}(cāng)庫(kù)中有庫(kù)存，所以采購(gòu)沒(méi)有下采購(gòu)訂單。而第二張采購(gòu)訂單因?yàn)椴少?gòu)人員操作不小心刪除了，其后來(lái)手工補(bǔ)了一張采購(gòu)訂單。C物料一半用庫(kù)存，一半采購(gòu)。D物料后來(lái)利用其他物料來(lái)代替。把企業(yè)用戶碰到的實(shí)際情況一一利用案例描述出來(lái)。如此的話，無(wú)論是誰(shuí)，看到這個(gè)案例也就明白了需求中具體描述了什么內(nèi)容。很明顯，通過(guò)這個(gè)案例描述可以在很大程度上消除CIO與程序員或者外部實(shí)施顧問(wèn)認(rèn)識(shí)上的分歧。
　　所以，筆者建議，CIO在巴自己的需求報(bào)告拿給別人看的時(shí)候，先要捫心自問(wèn)，看看這份需求報(bào)告會(huì)不會(huì)十個(gè)人看得出十個(gè)不同的結(jié)果。若不幸真的是如此的話，那么CIO就應(yīng)該想出一些可行的措施，把這個(gè)歧義降低到最低。
　　問(wèn)題三：是否詳細(xì)定義了可靠性？
　　在考慮需求分析報(bào)告是否可以過(guò)關(guān)的時(shí)候，還需要考慮一個(gè)問(wèn)題，就是要衡量一下這個(gè)需求的可靠性問(wèn)題。如這個(gè)需求執(zhí)行過(guò)程中會(huì)不會(huì)失敗，以及失敗會(huì)否給其他業(yè)務(wù)帶來(lái)什么樣的不利后果。同時(shí)，當(dāng)失敗時(shí)系統(tǒng)以何種形式來(lái)告知管理員這個(gè)失敗的結(jié)果，等等。
　　如仍然是上面這個(gè)需求?，F(xiàn)在在根據(jù)銷售訂單生成采購(gòu)訂單的時(shí)候，由于一些原因可能銷售訂單無(wú)法按物料清單展開而正確生成采購(gòu)訂單。如可能系統(tǒng)中某個(gè)物料有庫(kù)存，所以某個(gè)物料就沒(méi)有發(fā)生采購(gòu)；又如可能某個(gè)原材料沒(méi)有定義供應(yīng)商，所以系統(tǒng)無(wú)法為這個(gè)供應(yīng)商生成采購(gòu)訂單等等。
　　CIO在需求分析的時(shí)候，應(yīng)該預(yù)見這些情況可能會(huì)發(fā)生。那么，CIO就需要從程序的可靠性出發(fā)，想出一些應(yīng)對(duì)的措施。如因?yàn)橛袔?kù)存而沒(méi)有下采購(gòu)訂單，這是屬于正常的作業(yè)。但是，此時(shí)系統(tǒng)應(yīng)該以某種形式來(lái)告知用戶這種情況。如在生成采購(gòu)單的時(shí)候通過(guò)日志信息記錄等等都是可以的。而因?yàn)闆](méi)有定義供應(yīng)商而導(dǎo)致采購(gòu)訂單無(wú)法下達(dá)，此時(shí)，就需要系統(tǒng)通過(guò)非常明顯的方式告知企業(yè)用戶因?yàn)槭裁词裁丛蚨鴮?dǎo)致采購(gòu)訂單無(wú)法下達(dá)。總之，當(dāng)因?yàn)橐恍┮馔馇闆r，導(dǎo)致某個(gè)流程被意外中斷時(shí)，無(wú)論是合法的還是不合法的，系統(tǒng)都要能過(guò)以明文的形式告知用戶。否則的話，根據(jù)這個(gè)需求開發(fā)的解決方案的可靠性就會(huì)受到質(zhì)疑。
　　同時(shí)，這個(gè)提示信息業(yè)要盡量的讓人看的明白。如筆者發(fā)現(xiàn)有些系統(tǒng)在設(shè)計(jì)上確實(shí)也考慮到了這個(gè)可靠性問(wèn)題，但是他們沒(méi)有更進(jìn)一步，讓用戶頭疼不已。如因?yàn)闆](méi)有供應(yīng)商而導(dǎo)致無(wú)法正常生成采購(gòu)訂單的時(shí)候，系統(tǒng)只提示“采購(gòu)訂單無(wú)法生成”。即沒(méi)有告訴用戶因?yàn)槭裁丛驅(qū)е虏少?gòu)訂單無(wú)法生成；同時(shí)也沒(méi)有告訴用戶哪些原材料無(wú)法生成采購(gòu)訂單。如此的話，用戶就需要從頭開始去查找錯(cuò)誤的原因。其實(shí)，到底為什么無(wú)法生成采購(gòu)訂單的原因，在后臺(tái)程序判斷中都會(huì)有所體現(xiàn)。只需要用戶把判斷的參數(shù)，如某個(gè)編號(hào)的零件供應(yīng)商ID為空等等信息反饋到前臺(tái)。那么系統(tǒng)管理人員憑借這條信息就可以非常容易的定位錯(cuò)誤信息。并在最短時(shí)間內(nèi)把問(wèn)題解決掉。
　　所以筆者認(rèn)為，CIO在做需求分析的時(shí)候，除了要做好具體的需求描述之外，最好還要從這個(gè)可靠性出發(fā)，考慮發(fā)生意外事故時(shí)所需要傳遞的故障信息、錯(cuò)誤檢測(cè)以及恢復(fù)策略等等。并且，這些信息要能夠幫助用戶迅速定位并且解決問(wèn)題。即要反映出問(wèn)題發(fā)生的原因而不能夠只是結(jié)果。

    項(xiàng)目經(jīng)理勝任力免費(fèi)測(cè)評(píng)PMQ上線啦！快來(lái)測(cè)測(cè)你排多少名吧~

    http://www.vanceur.cn/pmqhd/index.html