又可導出各種表格，如成本表格等。
對于需求方面，除了必要的用戶需求規(guī)格說明書外，維護《需求跟蹤矩陣表》也是值得推崇的做法，因為通過該excel表，可以把需求、設(shè)計、測試用例等聯(lián)系在一起，當發(fā)生需求變更時，可以很容易地看出變更涉及的內(nèi)容及估算合理的工作量等。另外，在項目發(fā)生人員變動時，該表也為新進入人員快速了解本項目提供了一個窗口。在做設(shè)計時，建議先花些時間畫界面原型，我們會使用Axure工具做原型開發(fā)，界面原型的引入，可以使得客戶能夠較易理解我們設(shè)計的系統(tǒng)所包含的軟件模塊及各菜單的具體功能等，保持我們和客戶之間的交流順暢。
在開發(fā)階段，以測試驅(qū)動開發(fā)也是較為有效的方法，開發(fā)人員在構(gòu)造類和方法時，先寫main函數(shù)等，這對于開發(fā)人員進行單元測試、同行交叉測試等都提供了很好的幫助。
在系統(tǒng)測試階段，引入必要的bug管理工具很有必要，像我們公司用的就是開源的bugzilla，測試人員登入BUG，既可以文本，也可以粘貼附件，有利于開發(fā)人員定位問題，也提供了常用的搜索功能，方便快速尋找某一BUG。同時，公司的所有項目均在bugzilla上，可以了解其它項目的信息等。
同時，項目定期給項目干系人發(fā)送周報的方式也是很有必要的，這樣使得所有與項目有關(guān)的人都可以清楚地了解項目進展狀況，使得大家對于項目的問題、風險予以關(guān)注，也可以在發(fā)送周報的郵件中協(xié)調(diào)資源等。
總結(jié)項目經(jīng)驗
在一個項目成功實施后，一般就可以做一個了結(jié)。不管是成功的項目，還是失敗的項目，我在工作中都要求項目負責人提供《項目總結(jié)報告》，開項目總結(jié)會；當然，這樣的會議不是做秀，若是流于形式的會議則和沒開一樣。在總結(jié)會中，大家關(guān)起門來就是一家人，中肯的評價項目，總是會發(fā)現(xiàn)有可以改進的地方的，為以后項目或現(xiàn)階段正在進行的其他項目做參考。
在項目總結(jié)會上，控制好“度”，融洽的溝通氛圍是很重要的，不能讓項目人員感到挫敗感，也不能讓他們得意忘形，前者可能會讓他們故意回避問題，后者可能會讓他們看不清問題，這樣都不利于項目的總結(jié)。
做好項目度量
項目中過程數(shù)據(jù)的收集是很有必要的，像BUG數(shù)、模塊數(shù)、工時、風險數(shù)、問題數(shù)、代碼行數(shù)、文檔頁數(shù)等等，又可以把這些數(shù)據(jù)進行加工，總結(jié)出像每千行BUG數(shù)，開發(fā)人員產(chǎn)出效率等等指標，相信大家的公司都會有一些度量模板，在這里我就不再重復了。好的度量人員，整理的度量分析報告，有助于我們從中發(fā)現(xiàn)問題，客觀的數(shù)據(jù)更有助于我們進行理性的分析。
做好配置管理
我們公司的配置管理工作，可以說還是做的比較完善的，采用的配置管理工具為SVN，基線、變更等控制較好，文檔和代碼也都會全部納入配置管理，項目實施前必須有《操作手冊》和《安裝部署手冊》等，且質(zhì)管部整理出一整套相關(guān)文檔的模板，供各項目使用。對于長期從事類似項目在全國各地推廣實施的我們來說，配置管理的重要性不言而喻，它是公司的資產(chǎn)，更是團隊持續(xù)發(fā)展的重要保障。
培養(yǎng)程序員養(yǎng)成良好的工作習慣
對于絕大多數(shù)程序員來說，都是只喜歡寫代碼，而不喜歡寫程序注釋，更討厭寫文檔，甚至崇尚敏捷的開發(fā)人員以沒有注釋為美，認為代碼就是最好的注釋。但軟件=程序+文檔，隨著軟件行業(yè)的逐漸成熟，軟件的易讀性、易維護性變得日益重要，因為我們不能保證在軟件從開始至消亡前，不會新加入員工，也不能保證老員工不會流失。我個人比較推崇傳統(tǒng)的做法，也即程序員寫程序必須遵循制定的編碼規(guī)范。
為此，我們團隊建立有代碼走查制度，會定期隨機抽查某程序員的代碼。我不敢說我們團隊內(nèi)開發(fā)人員的技術(shù)水平有多高，但是我們有很好的編程習慣。
先進技術(shù)工具的引入
軟件的出現(xiàn)，很