在第一個版本就把這些標(biāo)準(zhǔn)全部實(shí)現(xiàn)，而是有步驟有重點(diǎn)地實(shí)現(xiàn)，逐步成為一個好軟件。因此《需求變更文檔》是不必可少的，同樣作個Excel表格，量化解決。包括下列幾項(xiàng)：客戶名稱、需求提出人、提出日期、需求關(guān)閉時(shí)間，功能模塊名，客戶現(xiàn)在版本號，需求描述，需求分類（需求、Bug）等。每次發(fā)布新版本都把從上一版本發(fā)布之日關(guān)閉的需求列表都單獨(dú)摘成一個文件，附帶到這次新發(fā)布的版本之后。
此舉有兩個好處，其一，能夠清楚的列出客戶以往所提的需求，因?yàn)橛幸恍┛蛻籼岢龅母膭涌偸欠捶磸?fù)復(fù)，一個問題一會要改成A,然后覺得不好要改成B，之后覺得還不如A好，便又要求改回去，這樣給公司的進(jìn)度和安排帶來很大的不便，如果因?yàn)檫@個耽誤了其他的工作，便可以有此根據(jù)和客戶進(jìn)行溝通，防止客戶賴賬；其二，可以評判技術(shù)支持和相關(guān)程序員的工作量。此文檔為EXCEL格式，但最好還有一個word類型的文檔，每次客戶提出修改意見時(shí)，將此文檔打印出來交由客戶簽字，作為憑證，此方法實(shí)際中并不是次次可行，一些強(qiáng)權(quán)客戶或不敢承擔(dān)責(zé)任的就不簽字，那也沒轍。
《測試結(jié)果》和《需求變更文檔》要定期（可一周或一個月）給老板一份。這表明了你的工作量，讓他看看你確實(shí)一直很辛苦地在工作，另外，也能看出你的認(rèn)真負(fù)責(zé)態(tài)度。
13、《用戶使用手冊》
按標(biāo)準(zhǔn)說，應(yīng)該由文案寫，但在大多數(shù)的軟件公司中都不設(shè)這個職位，因此要么由項(xiàng)目經(jīng)理寫要么由測試人員寫，關(guān)鍵看是誰給客戶做培訓(xùn)。在目前我做的這個項(xiàng)目中，并沒有專職測試，所以這個工作還是項(xiàng)目經(jīng)理來做?！队脩羰褂檬謨浴房筛鶕?jù)實(shí)際情況寫成三種版本，其一，chm類型文件，適用于C/S的項(xiàng)目，就像微軟的產(chǎn)品中，都會有此幫助手冊；其二，做成網(wǎng)頁形式的幫助文件，適用于B/S項(xiàng)目；其三，就是做成word文檔，雖然可保存至本地，但使用起來沒有前二者方便。
剩下的還有《開發(fā)任務(wù)書》、《項(xiàng)目總結(jié)報(bào)告》、《軟件驗(yàn)收評審》等，并不是必須的，可根據(jù)客戶需要和實(shí)際的項(xiàng)目來選擇使用，再次并不一一贅述。
并且，以上所有文檔，雖然有些是必須的，比如《需求分析說明書》、《測試結(jié)果》、《用戶使用手冊》等，但根據(jù)不同的行業(yè)、不同的地區(qū)以及不同的項(xiàng)目和團(tuán)隊(duì)規(guī)模，文檔的具體內(nèi)容都會有所不同，不必較真。
只要能抓到老鼠，白貓黑貓都是好貓，況且，沒必要的多余的文檔會浪費(fèi)時(shí)間和成本等資源。