終可交付成果一定要是可以被檢查的，比如，【界面要求：美觀大方、簡潔明快】，這個要求我就不知道如何檢查。所以，給開發(fā)小組布置任務(wù)的時候就要考慮如何檢查結(jié)果，比如我見過一個計劃，里面有一個任務(wù)【開發(fā)人員熟悉EJB編程】，這個任務(wù)，除了讓這些人去參加一些專業(yè)認(rèn)證考試，否則，結(jié)果很難被檢查。所以，時刻考慮如何檢查結(jié)果、如何向客戶交付是項目經(jīng)理一直要注意的事情，我聽說有些老項目經(jīng)理拿到項目是倒排計劃的，即首先看如何驗收和驗收標(biāo)準(zhǔn)，然后決定工作計劃。很多項目開始了很久，還不知道如何驗收，那么這個項目出問題的可能性就很大了。做項目就是為了驗收，我們的角色不是研究機構(gòu)，我們的目的就是在付出那么多勞動后得到結(jié)果。
　　
另外我插一句：我是極其不主張到客戶現(xiàn)場開發(fā)的。尤其是一大群技術(shù)人員直接和客戶交流，很容易引起沖突和矛盾（技術(shù)人員的本性決定的）。我的做法是項目經(jīng)理和項目實施人員到現(xiàn)場，軟件開發(fā)人員還是在公司做項目。項目實施人員就是初級項目經(jīng)理，他們了解自己的產(chǎn)品，懂得一些客戶的業(yè)務(wù)，關(guān)鍵是在于他們具有良好的溝通能力，俗稱“皮厚”。他們是客戶和研發(fā)人員的橋梁，其職業(yè)方向也是很機動靈活，以后可以有很多方向可以轉(zhuǎn)，比開發(fā)人員的路要寬得多。

11.接著，我們再談?wù)勛钭屓祟^痛的需求變更問題。變更通常分為兩種：一種是部分更改了原先的目標(biāo)，即需求變更；另一種是沒改變目標(biāo)，但是客戶不滿意目前的實現(xiàn)方式，大到流程的實現(xiàn)，小到界面的布局，都是屬于這類。碰到這種情況是難以避免的，主要是事先溝通的不夠充分和客戶隨著項目的進展，慢慢想清楚了問題，改變了以前的思路。這時候，如果需要改并且你的戰(zhàn)略是容許這種情況的，那么注意下面幾點：

1. 確保以前的文檔，就是記載著以前的結(jié)論的東西，客戶是否簽過字，如果沒有，趕緊把你的工作停下來，趕快再和客戶自己確認(rèn)一下你的方案，然后讓他簽字，避免以后說話沒有憑據(jù)；
　　
2. 和客戶坐下來，自己探討他修改的根本目的是什么，是不是有同樣能達(dá)到相同目的，但是對你來說有代價更小的選擇？
　　
3. （項目初期的工作）明確更改流程，一般是客戶指定一人簽字（否則客戶每個領(lǐng)導(dǎo)都有權(quán)力來插一杠子，你就廢了），以正式項目文件的方式提交給你，然后，你做評估分析，分析對成本、進度的影響，在你的領(lǐng)導(dǎo)同意后，出相應(yīng)意見書，主要是要說明更改設(shè)計的原因和指出由此帶來的不確定后果（這個東西先寫出來，后面如果真的發(fā)生了，至少不是你的錯）。然后再讓客戶在上面簽字。見過醫(yī)院給病人做手術(shù)以前讓家人簽的免責(zé)條款嗎？對，就學(xué)習(xí)那個，讓大家都意識到任何的更改都有成本和代價。
12.系統(tǒng)開發(fā)告一段落后，就進入客戶培訓(xùn)、系統(tǒng)驗收階段，這個階段，我一般會注意以下幾個問題：
一、給客戶做培訓(xùn)前，多注意一些表面功夫。很多程序員認(rèn)為，系統(tǒng)的邏輯核心是否正確是關(guān)鍵，至于界面如何，界面上的用詞是否準(zhǔn)確，那是無關(guān)緊要的問題，而且培訓(xùn)的時候也是信手拈來，想到哪里說到哪里，下面聽講的人不知所云，云山霧罩，培訓(xùn)效果自然可以想象。我的體會是，給客戶做培訓(xùn)的版本，如果你在做多次測試以后仍然不能確定邏輯是否合乎要求，那么，你至少要在界面上多花一點功夫。注意每個界面的布局、用詞、鏈接的正確性等等，總之不要讓客戶看到一些他不該看到的東西。文檔方面，準(zhǔn)備至少兩個文檔：用戶手冊和培訓(xùn)手冊。這兩個文檔的內(nèi)容很多都是一致的，但是角度完全不同。用戶手冊往往是站在系統(tǒng)設(shè)計者的角度，按照自己的思路，分模塊講解系統(tǒng)的操作和功能；而培訓(xùn)手冊，