有個問題需要單獨對還沒有PM覺悟的程序員說，其實是在調研的時候就定了的，就是使用什么樣的開發工具。沒有經驗的程序員往往會拿著C++或者JAVA的資格證書或者擁有一兩個開發工具的一些經驗而得意洋洋。其實老板和PM根本不看重這個，他們關心的是使用什么樣的工具能盡快的達到目的。管你什么C++，DELPHI，PB還是JAVA，只要能做的出來，VFP都可以用。我舉這個例子并非說不看中工具，而是提醒想轉型為PM的程序員，第一要把工具當作工具，而不要被工具套進去，鉆研一些一輩子都用不上的技術;第二要掌握的并非是單獨的一個工具，而是流行的程序設計的思想，以及在最短時間內掌握一門陌生工具的能力。只有建立了這樣的思維，才有可能轉為PM，否則一輩子都是技術工人，最多就是個技術總監。
2.變更
對任何項目，變更無可避免，無從逃避，只能去積極應對，這個應對應該是從需求分析就開始了。對一個需求分析做的很好的項目來說，基準文件定義的范圍越詳細清晰，用戶跟PM扯皮的幌子就越少。而需求沒做好，基準文件里的范圍含糊不清，被客戶抓住空子搞你一下是非常頭疼的事情，往往要付出無謂的犧牲，有時候甚至非�；鸫�。
需求做的好，文檔清晰又有客戶簽字，那么后期客戶提出的變更就超出了合同的范圍，需要另外收費。這個時候千萬不能手軟，并非要刻意賺取客戶的錢財，而是不能養成客戶經常變更的習慣，否則后患無窮，維護的成本會讓PM吃不消。在客戶提出變更請求時，要建立變更申請登記表和變更申請表，并讓客戶簽字。當然，有時候一些不是非常關鍵的模塊PM也不至于一點不講情面，該賣面子的時候還是要賣，尤其是當著對方領導的面，千萬要賣面子，但是也別賣的太干脆，不要讓他們得到的太容易。
需求做的不好，客戶抓住漏洞或者非常不講道理，麻煩就大了。有時候爭論會很厲害，到非常白熱化的地步，PM與客戶代表幾乎溝通不了。PM在客戶關系和短期利益兩方面難以取舍，一般都是向客戶妥協，最終形成惡性循環。這種情況非常難辦。一般這種情況都是到了項目后期，做重大的更改幾乎是不可能的事情，如果白做就要虧錢。而這個時候如果PM跟對方高層的人關系搞的定，可以透過對方高層把事情壓住。然而由于已經到后期，客戶代表不會輕易更換，對方這次沒有改成，必然心懷不滿，下回在別的模塊依然會找麻煩或者在談二期的時候動動手腳，都是很讓PM傷腦筋的事情，這方面目前還沒有什么好的解決方法，所以盡可能的做好需求比什么都重要。相對需求來說，什么WBS，風險管理，計劃進度都是扯淡，需求做好了，一帆風順。還有一種辦法就是裝可憐，要裝的非常的象，在對方的領導面前裝，而且不能讓人看出是裝的樣子，要讓你自己都覺得你自己是真的可憐，那么就算這次客戶硬是要求改了，下回他也必然不好意思再叫你改。其實人心都是肉長的，如果可能的話，我還是不贊同使用一些手段的，但是有時候客戶非常難以在短時間打動而工期又將接近，這種情況下就要靠PM耍一些手段了。各人有各人的方式，八仙過海，各顯神通吧。
PM在變更管理中需要做的是分析變更請求，評估變更可能帶來的風險和修改基準文件。
3.質量控制
大公司有質量管理部門(QA)，QA的成員基本上都是由非常有經驗的PM轉型過來的老狐貍，是老總接班人的有力爭奪者。一個QA會管理多個項目，有時候甚至會親身參與。PM和QA有些象貓和老鼠，不停的通過報表傳遞一些心照不宣的假數字。QA對PM的工作最終是有評定的：A級表示總體在控制下;B級表示當前在控制下;C級表示有顯著問題;D級表示有重大問題。如果PM得了個D，那可不太妙，不但世界級的QA會每個月要收報告，地區QA會一個星期找來面談一次，訓一頓。得到A的PM是很逍遙的，基本上不會有人來過問。在沒有QA的公司，質量控制只能由經過授權的團隊成員進行，效果就要差的多了。
質量管理貫穿整個項目周期，詳細的可以參見CMM。
4.成本管理
PM經常通過控制進度和預估來控制成本。PM必須經常問自己，項目已經到了什么階段?完成了多少?花費了多少?完成時成本是多少?掙值法的術語不少，象BCWS，BCWP，ACWP，但是關系比較簡單，大家參閱一下相關資料，這里不再羸述�？傊�，PM要管理好成本，注意節約，但并非是拼命剝削程序員，該花的還是要花。
五.結束階段
文章來源于領測軟件測試網 http://www.kjueaiud.com/
