近幾天剛剛交付驗收了一個(gè)政府的軟件項目，在這個(gè)項目的開(kāi)發(fā)過(guò)程中遇到了不少困難，包括技術(shù)上的障礙和一些實(shí)際的人為上的問(wèn)題。一個(gè)項目之所以能成功，能讓客戶(hù)滿(mǎn)意，領(lǐng)導放心的原因可能大多都差不多，大多都是老生長(cháng)談的那幾條。但是一個(gè)項目失敗的原因卻各有各的不同。下面再根據自己的體會(huì )寫(xiě)一些項目總結，一為了總結不足，積累經(jīng)驗，二為了以后項目中避免犯同樣的錯誤。
一.要和客戶(hù)有足夠有效的溝通
和客戶(hù)的溝通要貫穿整個(gè)項目開(kāi)發(fā)的始終，從立項調研，需求獲取到最后的驗收測試，后期維護。
1.要盡量多的主動(dòng)跟客戶(hù)溝通
客戶(hù)一般工作都很忙，所以要通過(guò)多種方式和客戶(hù)保持溝通，電子郵件，電話(huà)，座談，調查，會(huì )議等。最初的需求盡量保證有幾次所有與項目相關(guān)的部門(mén)和人員都能參加的討論會(huì )，把他們的各自的工作都描述一下，盡量不要遺漏，都羅列出來(lái)，因為這是原始需求。這往往不容易做到，因為政府部門(mén)很難抽出時(shí)間把各部門(mén)人員集中在一起來(lái)做這些事情的，但是我們必須得這樣要求他們，要求他們把這個(gè)看成一項工作來(lái)抓，因為前期工作做不充分，后面的開(kāi)發(fā)會(huì )不會(huì )很成功。在對某個(gè)功能或者需求不能確定的情況下，最好能整理成列表文檔發(fā)給客戶(hù)，讓客戶(hù)以電子版的形式重新描述一下發(fā)過(guò)來(lái)，盡量不要經(jīng)常打電話(huà)騷擾客戶(hù)，要集中把要了解東西發(fā)給客戶(hù)，以便他們集中精力來(lái)處理你問(wèn)的問(wèn)題。
2.要盡量保證有效的溝通
每次溝通要有一定的目的性，把溝通交流的結果用文檔的形式保存下來(lái)；需求制訂出來(lái)要得到客戶(hù)的確認，在經(jīng)過(guò)幾次反復之后會(huì )得到一個(gè)相對比較穩定的需求，雖然客戶(hù)的需求不可能一直不變，這也是很多人搞項目頭疼的地方，但是我認為客戶(hù)的需求實(shí)際上是很少改變的，改變的是你對客戶(hù)需求的理解。對客戶(hù)的每一個(gè)要求都要重視，尤其是客戶(hù)后來(lái)提到的一些改動(dòng)建議，要讓他們以書(shū)面的形式發(fā)過(guò)來(lái)，必要的時(shí)候要求負責人蓋章簽字，我們不能為了下面的下面的一個(gè)小辦事員隨便打個(gè)電話(huà)就對程序做出大的改動(dòng)。再改動(dòng)比較大的情況下，我們可以要求客戶(hù)對合同的變更追加費用，前提是把需求做為合同的附件加進(jìn)去，防治最后驗收的時(shí)候造成爭執。
3.和客戶(hù)溝通要找準對象
一般企業(yè)或者政府都有專(zhuān)門(mén)負責信息的人員，而且最好要求客戶(hù)那邊找一個(gè)人專(zhuān)門(mén)負責這個(gè)項目。這樣找對方了解需求的時(shí)候就不會(huì )出現不知道找誰(shuí)的情況，客戶(hù)那邊有專(zhuān)人負責會(huì )帶來(lái)很多好處，這個(gè)項目就是因為客戶(hù)那邊負責這個(gè)項目的人員經(jīng)常更換而為我們項目的開(kāi)發(fā)造成了很多的不變。
二.提高開(kāi)發(fā)效率和保證項目質(zhì)量
政府的項目一般都是開(kāi)始的時(shí)候不著(zhù)急，你催他們準備資料他們也不著(zhù)急，但是一旦他們把資料準備全了，都交給你了就著(zhù)急了，要求對方在很短的時(shí)間內保證質(zhì)量的把項目交付。所以如何提高開(kāi)發(fā)效率和保證項目質(zhì)量是確保項目成功的關(guān)鍵。
1.保證良好充分的測試
當然軟件測試的范疇很大，但是為了趕進(jìn)度我們往往不能不保證進(jìn)行所有的軟件測試。軟件的測試也是遍布整個(gè)項目開(kāi)發(fā)周期的，我了解了一下TDD，TDD的思想很好，很適合開(kāi)發(fā)中小型的項目，實(shí)施起來(lái)也很方便，但是不能純粹的用敏捷開(kāi)發(fā)的理論，必要的文檔還是需要的。我認為代碼模塊的單元測試，開(kāi)發(fā)最后階段的集成測試和部署后的整體功能測試和用戶(hù)驗收測試是必不可少的。項目進(jìn)度再緊張也要進(jìn)行單元測試，只要保證單元測試能通過(guò)，以后代碼可以慢慢重構。集成測試保證項目各個(gè)模塊能良好的協(xié)作共同完成復雜的任務(wù)，這點(diǎn)不能保證的話(huà)，展示給客戶(hù)的最終功能就不能保證。而功能測試和用戶(hù)驗收測試是純粹的黑盒測試，自己內部人員先對照原始客戶(hù)的需求進(jìn)行功能測試，列出BUG列表，經(jīng)過(guò)幾次反復修改后給客戶(hù)一個(gè)可以進(jìn)行驗收測試的系統。
2.保證相對必要的文檔以及保證文檔的可用性
每個(gè)模塊的文檔要獨立起來(lái)，要實(shí)現的目標，測試的結果，模塊所用的數據庫的結構，存儲過(guò)程，設計思路，調用的接口等這些是必須的。我也不建議面面俱到的文檔，但必要的需求文檔，模塊文檔，測試文檔是必須的，我們的項目小的不足以讓我們去學(xué)習龐大的RUP什么的。
3.迭代開(kāi)發(fā)
剛開(kāi)始可以根據客戶(hù)的需求弄出一個(gè)藍圖來(lái)，交給客戶(hù)看，以便讓客戶(hù)能盡量早的知道最終的開(kāi)發(fā)出來(lái)的系統是什么樣子的，這個(gè)藍圖要盡量直觀(guān)，一般在需求整理完畢后一周就能出來(lái)，這也是指導以后開(kāi)發(fā)工作的東西，要完整的包含所有的域模型，便于開(kāi)發(fā)人員對問(wèn)題域的理解。然后把優(yōu)先級最高的一系列功能完整后出一個(gè)DEMO版給客戶(hù)，要讓客戶(hù)盡量早的發(fā)現正在制作的項目和用戶(hù)想要的結果的之間的偏離和差距，告訴你后以便你盡早的調整，別等你的正式版出來(lái)后用戶(hù)發(fā)現這個(gè)功能你做的不對，你就傻了，那時(shí)候要改動(dòng)的地方就太多了。然后再弄完善一下給用戶(hù)個(gè)beta版，這時(shí)候就已經(jīng)接近最終版本了，可能還有一些小BUG。最后把小BUG完善修復一下給客戶(hù)正式版1.0讓客戶(hù)驗收。至于二期項目以后再說(shuō)，先把一期項目的余款結了再說(shuō)，對吧。
4.制訂開(kāi)發(fā)規范
開(kāi)發(fā)規范訂的太死會(huì )限制程序員，每個(gè)開(kāi)發(fā)人員都會(huì )有一些習慣，但是為了協(xié)作，制訂一個(gè)相對通用的規范是有必要的。包括文檔的規范，數據庫設計規范，編碼規范以及各種命名規則。盡量用一些業(yè)界通用的規范，網(wǎng)上都有，我CSDN的博客上也整理了一些，MSDN的類(lèi)庫開(kāi)發(fā)人員指南里面也有一些。盡管某些規范很有爭議，我感覺(jué)你也得選擇其中一種來(lái)做為你的項目開(kāi)發(fā)規范。
5.建立開(kāi)發(fā)基礎
保證機器和軟件的可用，盡量大的內存，盡量快的處理器，操作系統，開(kāi)發(fā)工具都要到位，該想到的就得想到，還要給開(kāi)發(fā)人員一個(gè)相對安靜舒適的環(huán)境，最好能很方便的喝到冰箱里的可樂(lè )，而且能在累的時(shí)候有綠色的植物看。再一個(gè)就是建立一個(gè)開(kāi)發(fā)基礎結構，這個(gè)也頗有爭議，幾乎每個(gè)公司都有自己的系統類(lèi)庫，開(kāi)發(fā)框架以及配套的代碼生成工具，這都很好，在開(kāi)始可以對員工做適當的培訓，讓他們都能體驗自底向上設計的好處，都能用的上這個(gè)架構，你可以在架構中要求開(kāi)發(fā)人員以指定的方式實(shí)現某些通用的任務(wù)，比如說(shuō)日志記錄和錯誤處理等，而不是讓他們使用自己習慣的方式去處理問(wèn)題，因為.NET的靈活性讓實(shí)現一個(gè)任務(wù)有很多中方案和手段。
小節：雖然這個(gè)帖子沒(méi)有討論具體技術(shù)，而且都是一些空話(huà)套話(huà)，并且這些空話(huà)套話(huà)可能別人也都說(shuō)的不帶說(shuō)了，但我感覺(jué)還是有必要自己總結一下的。
聯(lián)系客服
