一定要站在客戶業(yè)務人員的角度，根據(jù)每個角色面對不同業(yè)務的辦理，如何通過使用本系統(tǒng)的一系列功能來實現(xiàn)目標。所以，第一次培訓以前，系統(tǒng)界面是否完整正確、培訓文檔是否完備都是很關(guān)鍵的因素，第一炮打不響，以后就麻煩很多。
作為項目經(jīng)理，其實腦子里就是幾樣東西：做哪些事情、做到什么程度、怎么交貨、手上的資源以及各個事情的優(yōu)先級。所謂多快好省那是人類的夢想，這四個方面都是相互矛盾的，屬于典型的又要馬兒跑，又要馬兒不吃草的類型?？紤]問題的輕重緩急方面，往往是把快放在第一位，各方領導都會給你最后期限，所以保進度是第一位的；省是第二位的，企業(yè)的根本目的是盈利，如果收入不能增加的話，至少費用要控制??；好是第三位的，沒辦法，誰都想精益求精，但是，沒有強大的資源保障，質(zhì)量只好先犧牲了；最后是多，客戶的要求源源不斷，如何降低客戶的期望值，讓他們從理想回到現(xiàn)實也是項目經(jīng)理的分內(nèi)工作。
驗收前，除了做好文檔工作，即可交付成果以外，多花時間搞清楚客戶的做事情流程是很重要的事情，這些在前面已經(jīng)有所提及，這里就不再多說。
我對驗收最大的體會就是舉證問題。即千萬不要讓客戶這么想：你必須有證據(jù)證明你的系統(tǒng)是沒問題的。這樣你就沒戲了，微軟那么多天才，做了XP還天天打補丁，要你的程序沒問題，既不可能，你也沒辦法拿出證據(jù)。你要讓客戶明白，所謂驗收，就是我按照測試文檔的測試用例跑一遍，結(jié)果和預期結(jié)果一致就應該算通過了，而且還容許有一些小錯誤留在驗收后改正，他可以對測試用例提意見。所以，驗收前雙方要確認測試計劃和測試用例。如果他認為系統(tǒng)不符合要求，那么他應該舉證，證明這個系統(tǒng)和最初設計相背離的。所以，參考法律概念，千萬不要舉證倒置。另外，認為系統(tǒng)完美了才能驗收的想法也是錯誤的，軟件開發(fā)合同里一定要注明驗收以后維護期的費用問題，否則，客戶擔心一旦驗收就得不到你們的支持，自然不配合驗收，那么，你這個項目經(jīng)理就很難交功課了。
項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~
http://www.vanceur.cn/pmqhd/index.html
