專案管理經驗分享

今年的高項又棄考了，真的沒時間看書，安慰一下自己：考過了並不代表什麼！就是平時吹水時聲音可以大點，沒證的只有點頭說是的份。平時也接觸過不少有證書的同事，高項，pmp，管理水平真的一般般。對軟體公司的來，專案管理水平對公司的業績有著直接的影響。凡是沒意識到這點的人，說明他對專案管理的認識還不夠，死記硬背一些理論是沒用的，還快也會忘記，要真的理解這些理論在管理過程中的意義所在才是最重要的，快速交付才是硬道理。下面談談專案中實際工作中遇到的一些與專案管理相關的問題。

專案經理一定要有乙份這樣的東西去把握某個專案的總體的關鍵資訊。有利於工作開展時，任務安排的輕重緩急。專案干係人的識別：在功能設計時，如果某些功能跟重要的干係人有關係的話，如領導所操作的頁面，還有統計報表，這些功能一定要設計好點。搞好點，領導很有可能把你們產品推薦給其他同行。一傳十，十傳百。一些後台操作不是很頻繁的功能，可以隨便點就行了。業務誰說了算，做需求時就聽取多點。 接過很多專案好像都沒有這份東西。

記得第一次去做需求時，就遇到這樣的問題了，當時使用的原型法，畫了一些簡單的頁面給客戶確認，原型列表和功能的資料是隨便寫的。發給了客戶確認。不知道客戶看還是沒看，當時的情況有點特殊，又不好讓客戶簽名，他們就說看了，大概是這樣，先做看看先吧。我看功能頁面都很簡單，需求也不是很複雜，就開始做了，花了兩個星期做出來了，給客戶使用的時候，發現跟他們想要的有出入。幸虧他們不是說跟他們想要的完全不一樣，又花了乙個星期就修改。總花了三個星期。

吸取教訓：以後做需求時，借鑑在上家公司的經驗，畫了原型出來的同時也把對使用者的使用的理解製作用例測試，按角色使用場景製做，資料是用客戶提供的真實資料，當場給客戶講解，剛開始客戶有點不耐煩，有些客戶聽你講需求理解的時候，你還沒講完他就說是了，這裡時候必須跟他們講這個環節的重要性。跟客戶的合作久了之後，我對業務熟悉了之後，很多業務根本都不用這樣需求確認了，去開完會回來就知道怎麼做了。效率很高，這也是為什麼軟體專案一般二期才開始掙錢，如果你知道客戶只做一期的專案（有些客戶有開發團隊），這種可以開高點**。

失敗經驗：

後來在泛華的時候，看到大公司的調研團隊跟我們公司做調研的時候，也犯了我第一次做需求時的錯誤。那時候他們來我們公司做需求調研，他們也只有製作完原型跟客戶開會確認，確認時我也在場，只是按他們的理解對著原型講。並沒有使用測試用例去講。在系統上線之後，我們公司的業務部門在使用系統的才發現很多功能和資訊都不全，甚至有更加嚴重的缺失，流程無法走下去。我們公司在開發過程中又拼命的壓縮時間，正大把這次合作看得很重，又豪無底線的答應。他們在開發過程測試過程中很明顯發現了很多邏輯上的bug，也不敢說出來，以為需求確認書上有人簽名了就行了。按原型做完就算ok了。

**結果：

原型上的描述根本沒有業務邏輯，就算有客戶簽名，客戶驗收時發現業務邏輯有問題，客戶表示我不會驗收的，你頁面是長得跟需求確認時的一樣，但沒法工作，沒有給我帶來工作效率的提高，頁面多漂亮都沒用，要知道對於我們這種貸款公司，業務部門不能順利放款，他們肯定的不會簽收。多有道理。最後這個專案正大正式宣布失敗走法律程式。

**失敗原因：1專案管理水平差。2沒有專業性（客戶說什麼就是什麼）。3資訊系統開發技術水平差，技術積累較少。

成功的原因總是驚人的相似,失敗的原因確各有不同。下面總結一下在之前公司的成功經驗:

專案管理經驗分享

我的專案經驗分為專案啟動前，專案開發中，專案維護中三個階段總結。一 專案啟動前 1 需求分析 根據需求給定的需求說明書，去仔細分析理解每乙個需求任務，評估功能需求的可做性 技術可行性，評估功能的實現和耗費的資源 人力和時間 的可支援性。例如 在tulipb b02 專案開發過程中，在使用者遠端許可權...

ERP專案管理經驗分享

本人進入軟體行業已經有5個年頭了，主導實施和參與過的大大小小的專案有20餘個。其中有些專案做的非常好，提公升了客戶企業的管理水平，也規範了企業的業務操作水平，優化了企業的流程，客戶非常認同我們實施的價值 也有的專案實施效果一般，客戶在應用軟體前後沒有明顯的效果，唯一的成果就是計算機代替了人來彙總一些...

專案管理經驗 八年專案管理經驗分享

閒下來的時候，忽然想到，算算工作時間也快8年了，作專案經理時間不長，前前後後加一起3年多點。有一段時間作產品，後來又作專案，自己覺得學到了一些東西，現在拿出來分享，歡迎討論。專案管理 團隊內部成員 溝通專案經理一定要和每個成員充分溝通，了解他們的想法和個人發展方向，每個人每個階段的希望和目標都是不同...