僅藉此處記錄我個人在軟體專案管理工作中所遇到的問題，以及經驗總結。

最近一段時間在工作當中，我遇到了許多問題，也犯了一些錯誤。一來可能是對公司的管理制度，軟體管理流程還不太熟悉，二來確實是最近經驗尚淺還望讀者見諒。

言歸正傳，

專案初期

在專案初期與客戶洽談需求時，我不懂得如何抓住重點，如何用最簡單的手段把客戶想要的東西呈現出來。我的教訓是，客戶多半是不懂技術的，包括我們專案經理有時候對某些專業的技術可能也不是太懂，那麼我們應該抓住的是什麼呢？從業務著手，對於我自己來說這是一個很大的挑戰。（本人技術出身）那麼在專案初期，我們也不可能把專案或者說軟體規格描述的多麼的細緻，那麼至少要把握住幾個關鍵的流程，最好以圖的方式把他們之間的關係畫出來。最好用一些動態的好看的容易理解的一些圖片組合。實在美術水平不佳，就直接用標準流程圖來畫，相信使用者也是能看的明白的。這是立項時最重要的要確定的東西。而我犯的錯誤就是從功能去描述初期軟體形態，那是非常愚蠢的一件事情。因為一開始的時候誰也不知道要什麼功能，而且從功能無法很好的體現出軟體的業務價值，使用者也無法理解與接收。除了主要業務流程以外，其次重要的當然就是工期以及人力投入了。這個根據實際的情況和使用者的期望給出一個比較合理的值即可。無需很精確，甚至可以不太準確。

立項

立項後當然就需要跟詳細的需求以及專案計劃咯。這個時候與客戶應該需要建立一種長期的溝通機制了。找對人，頻繁的溝通確認需求。運用需求管理知識一切可用的東西吧。我想說的是，最近犯的幾個錯誤。

1、不要偷換概念，最近我召開了一個會議，我把他的名字取為XX討論會，我原本的想法是，如果會議效果比較好，大家沒什麼意見，我就可以把這次會議當做是XX確認會。結果會後我就更大家這麼說了。後來想起來，我是多麼的愚蠢。我這樣偷換概念其實是在欺騙我的團隊，也是在掩耳盜鈴。我會失信與我的團隊，這是多麼嚴重的一件事情啊。會後我的QA也嚴厲的批評了我，及時姑且不談信任，如果要開XX確認會，那QA流程也是不一樣的。我還少了很多本應該要去走的標準流程。

敏捷書裡曾說過這樣一句話“不要丟下團隊中任一個人”。慚愧啊~

2、學會專案經理解決問題最佳實踐——溝通。在立項的計劃會議中，我遇到了一個問題，客戶之前提出最好開發3*80個人日完成軟體研發，但是客戶允許砍掉一些不太緊要的功能。（但在這之前我和我們的技術經理已經商量過需要5*80個人日來完成）這個時候在電話裡，我並沒有太在意，心裡自己盤算了一下就答應了下來。結果客戶就以此發了確認函。回頭我再更改我的計劃時，我的技術經理開始咆哮了，一下砍了我100多人日，我如何能完成？就算只實現最精簡的功能也看來是很困難的事情。這下我才意識到我應該先找我的團隊來評估這件事情，凡事都不能妄下定論。特別是對使用者的承諾，不是兒戲。不過還好，後來我的領導讓我再補一個開發評估，把我的實際情況做一個評估報告，結合目前的情況，再與使用者重新溝通確認工時。只希望使用者能講道理了。總之，以後我不僅要和使用者建立良好的溝通，還需要與我的團隊做好溝通，我的團隊才是我的堅實後盾，我必須充分信任我的團隊。就想我在裡講到的，良好的溝通的好處，整合他人的才能；讓別人願意和你合作；給對方信心；減輕壓力

今天到這裡，以後繼續。

專案管理是一個很奇妙的東西，不像我以前所接觸的任何軟體技術那麼直白，清晰。他更讓人捉摸不透。剛你認為你已經懂了，已經明白的時候，其實你不懂。當你覺得你還不懂的事情，其實你已經做對了。希望我以後會有更深的體會。也希望更多的與我志同道合的人與我交流溝通。Mark 2012/01/07