討論：十年專案管理最佳實踐與經驗總結

過去十年，在 IT|軟體專案管理方面有哪些最佳實踐（模式）和好的經驗，歡迎大家補充！

專案管理

* 相信科學

科學就是客觀規律，科學也是一種信仰。

* IT|軟體專案經理不懂軟體工程是萬萬不行的。

專案管理很重要，但不是全部。

IT|軟體專案管理離不開軟體工程。專案管理與軟體工程的交集是軟體專案管理，軟體專案管理只是軟體工程中一小塊（很小）的內容。

在 IBM RUP（Rational 統一過程）中，專案管理只是多個軟體工程科目中的一個科目（discipline）。

軟體工程的內容遠比 PMBOK 大得多，知識的來源也有很多，例如 IEEE 的軟體工程知識體系（SWEBOK）、SEI CMMI、IBM RUP 等等。

* 關係 over 技術

專案管理的核心是人，尤其是人際關係的管理。

專案管理的核心既不是專案，也不是產品，當然更不是什麼進度管理、範圍管理 ... 這些外在的東西。成功的專案，優秀的產品，來自於和諧的關係。而關係的管理恰恰是許多標準教科書上所沒有的。（悖論？）反過來說，只有關係和諧了，那些科學的專案管理方法（進度管理、範圍管理l ...）才會真正發揮作用。

敏捷過程、敏捷方法、敏捷專案管理再次把人放到了中心的地位上，體現了它的優越性。

* 風險管理是專案管理的第一管理

風險包括很多種（關係、需求、過程、進度、架構、質量 ... 等等）。專案經理的首要任務是防範風險。


需求

* 重視業務需求

軟體需求要服務於業務需求。

很多先進的組織會有專人負責 business modeling 和業務需求的分析。建立一個高質量的 business model，是企業資訊化的關鍵。

* 提高需求分析的精度

Use Case 建模是我所知目前最好的一種以使用者|客戶為中心的需求分析和管理方法。

需求的精度不夠導致什麼後果？正好 flying02 提供了一個經典案例：

粗略的需求導致雙輸
http://www.itpub.net/thread-1240442-1-1.html

* 積極應對需求變化

需求變化是最主要的一種專案風險。


過程

* 用 iterative 過程取代 waterfall 過程。

很多專案的失敗、損失都與 waterfall 有關。

...

[ 本帖最後由 張恂 於 2009-12-4 11:47 編輯 ]

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13633641/viewspace-621626/，如需轉載，請註明出處，否則將追究法律責任。