開發主擔主要是業務分析、設計、開發和測試，實際上抓好兩個關鍵要素就可以，乙個是業務設計，乙個是任務管理。任務管理的基礎也是業務設計充分，不清楚不做，粒度要細，要讓開發人員真正明白要做什麼。之所以專案做不好，業務理解設計不充分佔絕大多數，造成任務的分解做不下去，文件也寫不好，乙個專案業務的理解其實掌握在少數人手裡面，不可能全部都清楚，是個逐步細化和知識轉移的過程，這就要求每日的溝通，明白這一點，就知道怎麼去做好專案，其它的都是技術手段。
至於管理控制環節，比如scm、qa，則要盡量的讓大家感覺不到他們的存在，他們只是按計畫在關鍵節點時出現，並且隨時提供支援。審核的發起由他們來做，結果的判定以業務滿足和客戶開發過程標準滿足為主，在能力不足的情況下，不要讓他們有影響專案進度的決策權，專案經理做方案，公司領導來決策。測試也直接納入到專案經理的管理，對專案經理負責。 敏捷、scrum等都是提供了一些很好的方法，不過做專案首先要明白做什麼，這個問題解決了，方法就有用武之地。
至於團隊合作這樣的軟性指標，更多是一種措辭，專案經理首先要做好定位，搞清楚哪些是自己該做的，哪些是公司該做的，你要做的就是用手上的資源把專案做好。
把業務需求理解清楚，把任務分解排程好，對客戶、對上級做好溝通，減少對專案組的干擾，按時把工作做好，最終的目標是按時能拿到獎金。
目標單一，其它的都是手段，方法的引進只是為了解決最關鍵的問題，一次能做好乙個就是成功。
原文
感受 IT專案的成功和失敗
上週六，參加了一場關於it專案成功因素的講座，一些關鍵點記錄如下 需求說不清 範圍難確定 質量無標準 全靠人折騰 國外機構的調查結果 十多年前的結果，但是對現在還是有借鑑意義 it專案失敗的因素 倒序排序 5 technology illiteracy 4 unrealistic expectati...
什麼是軟體專案的成功
傳統觀念上的成功是指基於給定的財政預算，按照需求規格按時交付產品。standish 中給出了一些經典的定義 成功的 successful 按時完成，費用不超出預算，而且所有特性和功能都符合原先的設計規格。不太成功的 challenged 已完成而且可以執行，但費用超出了預算，沒有如期完成，擁有 的特...
從需求到專案的成功
我最近遇到乙個專案，在該專案中，乙個新的開發小組將針對早先的開發小組所開發的 求實現乙個應用程式。這個新的開發小組一看到由3英吋活頁紙訂成的軟體需求規格說明就 到十分恐懼，於是立刻編寫 在構造軟體的過程中，他們沒有參考軟體需求規格說明，而是根據他們對預期系統的不完整且不正確的理解，按他們自己的想像進...