成功的企業級軟件項目管理：優化績效完美交付的最佳實踐（簡體書）

本書旨在解決困擾軟件行業的一個問題：如何組織軟件項目管理以實現優化績效、完美交付。作者尼爾.懷特（PMP，項目管理領域的專家）介紹了一種新的方法：Enterprize組織。本書描述了Enterprize組織所定義的項目中的關鍵角色與責任，包括產品經理、項目經理、業務架構師、產品架構師、過程架構師、資源經理、團隊帶頭人和團隊成員。本書還討論了如何利用Enterprize組織大型項目、小型項目、多個項目和維護性項目，並通過設置的“問題與答案”欄目回答了項目管理過程中常見的一些問題。．

作者：（美國）尼爾?懷特（Neal Whitten） 譯者：陳秋萍

尼爾?懷特，PMP，在項目管理、軟件開發和人力資源開發領域是一個非常受歡迎的演講家、教師、顧問和作家。他在IBMT作了近23年，曾經擔任項目團隊帶頭人、項目經理和高級系統工程師的職務，在項目管理、軟件工程等方面積累了豐富的經驗。之后他于1993年創建了Neal Whitten集團并擔任集團總裁。該集團提供的服務包括發現組織在項目管理方面的問題并解決問題、進行項目評審、在項目管理原則的應用上對組織進行培訓，以及對項目所有成員進行培訓。

《項目管理核心資源庫?成功的企業級軟件項目管理:優化績效完美交付的最佳實踐》由電子工業出版社出版。

第1章EnterPrize組織概述1
產品經理2
項目經理3
業務架構師3
產品架構師3
過程架構師4
資源經理4
團隊帶頭人5
團隊成員5
工作關系6
職能匯報視圖6
項目匯報視圖6
大型項目、中型項目、小型項目和維護性項目的組織7
第2章產品經理9
獲取產品經費10
為產品的利潤與損失負責10
批準影響產品整體成功的產品計劃11
作為直接匯報人的資源經理11
作為產品發起人12
作為上報的終點12
問題與答案13
第3章項目經理18
為項目負全責18
負責項目的運作20
展示領導力，推動事情的進展21
沒有直接匯報人22
應用最近項目的經驗22
定義項目角色與責任23
領導項目計劃活動23
進行項目跟蹤24
采用項目管理最佳實踐25
根據項目優先級進行管理，進行風險管理26
與高管和客戶溝通項目狀態27
將決策下放給合理的低層員工27
促進客戶的參與27
鼓勵和支持上報28
實施有效的變更控制28
挑戰傳統思維29
指導項目成員29
促進良好的工作關系30
保留關鍵的項目文檔31
問題與答案31
第4章業務架構師45
定義客戶要解決的問題（需求）46
負責產品設計的業務過程方向46
沒有直接匯報人47
管理客戶的期望47
推動產品內容“滿足最小需求”49
與產品架構師、團隊帶頭人和項目經理密切合作49
是解決業務相關問題的催化劑50
對項目成員進行與業務過程相關的指導51
問題與答案51
第5章產品架構師55
負責為客戶的問題提供技術解決方案——做什么及如何做56
擔任變更控制委員會的主席56
沒有直接匯報人58
與業務架構師、團隊帶頭人和項目經理密切合作58
保證可接受的技術過程與方法被定義和遵循59
是解決技術相關問題的催化劑59
對項目成員進行與技術相關的指導60
問題與答案60
第6章過程架構師63
定義或裁剪軟件開發過程64
沒有直接匯報人65
管理項目過程的設計、記錄及度量65
保證項目遵循正確的過程66
是解決過程相關問題的催化劑67
對項目成員進行與過程相關的指導67
建議或批準對所選活動的度量68
問題與答案69
第7章資源經理72
有直接匯報人72
雇用和解雇74
進行資源計劃與分配75
定義直接匯報人的角色與責任76
幫助直接匯報人獲得成功76
將決策下放到合理的低層員工77
是解決領域相關問題的催化劑78
評估直接匯報人的績效79
為直接匯報人提供薪酬與獎勵79
提供職業咨詢與發展80
營造高效的工作環境81
作為公司溝通的渠道81
執行公司政策與實踐82
為直接匯報人管理后勤82
保證未來的工作機會83
問題與答案84
第8章團隊帶頭人94
第9章團隊成員110
第10章組織大型項目119
第11章組織多個項目128
第12章組織小型項目142
第13章組織維護性項目150
第14章項目管理辦公室162
第15章是否過于“溫和”190
第16章上報的過程210
第17章其他問題與答案226
詞匯表235

定義客戶要解決的問題（需求）
業務架構師與客戶密切合作以理解需要解決的問題。業務架構師保證這些問題定義清楚并編寫在通常被稱為產品需求的文檔中。該文檔至少要得到客戶和開發組織的批準，也可以讓其他感興趣的部門批準，如一個或多個測試組織、產品規劃和市場營銷組織、培訓組織和質量保證組織。
產品需求文檔比較簡潔，嚴格專注于客戶必須解決的問題，用容易理解的術語來描述客戶的問題。產品需求文檔不應該有意地關注這些問題的解決方案。遺憾的是，大部分人花很少篇幅來定義要解決的問題，而是利用產品需求文檔的大部分篇幅來定義要創建的解決方案。
如果產品需求文檔不專注于客戶要解決的問題，則開發組織很有可能不會全面地考慮或甚至不理解客戶真正想要和需要的是什么。為什么這么說？因為開發組織要加快產品開發速度——滿足進度需求。因此，開發組織經常代表客戶做假設，導致開發組織對自己的愿景太著迷，太想看到自己構想的產品。這時業務架構師就要堅持定義產品需求文檔，并讓恰當的小組理解并批準該文檔。
負責產品設計的業務過程方向
業務架構師必須保證客戶問題的解決方案確實適合客戶的業務，換句話說，解決方案是否能夠對客戶現在采用或計劃采用的業務流程模型提供有益的補充。開發組織看起來是最優雅、最出色、最先進的技術產品，而對客戶來說可能是商業夢魘。業務架構師保證在定義和開發產品時能夠滿足客戶的需求，即業務架構師持續地關注創建正確產品所需要做的一切。業務架構師與項目中大多數成員不同，后者更關注如何正確地創建產品。
沒有直接匯報人
業務架構師是客戶的代表，這是一個要求很高的關鍵工作。它可能是全職的工作，如果不是全職的，業務架構師可以同時在幾個小的產品團隊或項目團隊中擔任這個角色。和項目經理一樣，業務架構師也不能是具有人員管理和工作分配職責的資源經理。也就是說，業務架構師不應該有直接匯報人，只有資源經理才有直接匯報人。
如果業務架構師要求員工來協助他日常的業務架構職責，在經理與員工問題上該員工應該直接向資源經理匯報，但接受業務架構師分配的任務。第7章的“問題與答案”中的問題7.1討論了為什么已經擔任EnterPrize組織中關鍵職位的項目成員不應該擔任EnterPrize組織中的另一個關鍵職位。