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

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

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