敏捷相關方的參與和愿景規(guī)劃對于敏捷來說，相關方是可以包括任何與項目有關的人的。也就是說，不管是客戶、用戶、高層領導、甲方員工，只要是與我們要進行的項目有關聯(lián)的人都是相關方。在 PMP 的十大知識領域中，有一個 管理相關方 ，但是從敏捷的角度來看，我們與相關方應該是相輔相成的，所以，用 “參與” 會更合適些。 當然，敏捷中強調的是客戶合作，其實意思也就是越親密越好。甚至客戶應該直接入駐項目團隊中。但是，您也知道事實上這一點是很難辦到的。而且更重要的是，相關方或者說甲方團隊并不是采用敏捷的，甚至可能反感敏捷。這時候，我們還是要動用一些管理技巧的。因此，今天這篇文章我們先簡要地說一說 PMP 中的 管理相關方 都做了些什么。 PMP 的管理相關方在 PMP 中，管理相關方這一塊原來是在溝通管理中的，在 PHP 第5版之后才單獨成為了一個獨立的知識領域。從這也可以看出，不管是傳統(tǒng)項目管理還是敏捷，和相關方的關系都是決定項目成功失敗的一個重要方面。我們也需要將相關方的滿意度作為一個關鍵項目目標來進行管理。
簡單來說，就是搞明白哪些人或團隊或組織是項目的相關方，并把他們登記在冊。主要是這些相關方的重要性和影響程度，以及它們對項目的支持力度。在 PMP 中，相關方分析矩陣、權利或影響/利益矩陣、凸顯模型等都是很有效的工具，關于這些東西將來我們在學習 【信管師】 相關的課程時再進行講解。 在識別相關方的時候，最開始我們需要一個大表格，列出所有和項目有關的相關方。但是，其中一定有許多更為重要的相關方對項目會有重大的影響。這就需要我們對相關方進行有效的規(guī)劃管理。
相關方管理的核心策略就是在整個項目開發(fā)過程中，鼓勵相關方積極地參與項目。這里面需要注意的是我們要根據相關方的重要程度，使用一些不同的溝通方式，才能達到有效的溝通與組織。我們可以通過對相關方參與級別信息的排序來管理相關方。比如說參與級別有：不知曉；抵制；中立；支持；領導；從這些名詞的字面意思就可以看出他們的意思，所以也就不多做解釋了。通過各種溝通手段，盡量讓相關方達到中立及支持以上的水平。
在敏捷中，管理相關方的參與非常地簡單，因為前面提過很多次的 客戶合作 就是敏捷團隊對待相關方的態(tài)度。當然，我們也一直在強調，事情總不會那么順利的，相關方人數(shù)眾多，都參與到項目來也是不實際的。所以，我們也會采用一些 PMP 比較經典的方法來增強與相關方的溝通，以及處理一些和相關方之間的沖突。這個后面會說到。
看起來是監(jiān)督相關方嗎？難道要監(jiān)督他們的行為做風？不不不，這里的監(jiān)督是監(jiān)督整個項目團隊與相關方之間的關系，并及時根據情況調整策略。 共同的愿景上面我們一起簡單看了看在 PMP 中關于相關方管理的一些內容。敏捷本身也會借鑒許多好的管理實踐，特別是同為項目管理的 PMP 實踐，作為全世界最大的項目管理培訓課程，自然會很很多東西是值得我們學習的。不過先繞回來，看看在敏捷中，我們要如何與相關方建立共同的愿景。 敏捷章程在 PMP 中，我們有 項目章程 。而在敏捷中，我們也有對應的敏捷章程。作用其實也都差不多，正式啟動項目的文書，也代表著領導層或者相關方為項目團隊賦予權利。但是，敏捷章程對于項目的描述可能會更偏概要一些，項目目標是不可缺少的，收益的預期，驗收標準和邊界條件，問題和風險等等內容。而更偏敏捷的內容是我們會指定關鍵的成功要素，制定初始的發(fā)布計劃（里程碑），更重要的是，在敏捷章程中，我們要強調漸進明細的作用和團隊的力量。剩下的內容，其實就和普通的 項目章程 差不多了。 另外，我們還需要制定團隊的章程，其實主要就是這個團隊如果要走敏捷路線的話，那么還是需要一些統(tǒng)一的理念的。比如說團隊的價值觀、工作協(xié)議、基本規(guī)則、團隊規(guī)范等。這些都是根據各自團隊的情況進行制定的。 對于完成的定義DoD ， Definition of Done ，對于完成的定義。這個縮寫也是敏捷中非常重要的一個概念。為什么會有這么奇怪的東西，完成了不就是完成了，為什么還要“定義完成”？不知道你有經歷過這種事情沒，開發(fā)做完了，這是他的“完成”。但是 PO 一使用，發(fā)現(xiàn)一大堆問題，這個完成在 PO 這里顯然還不算是完成。而有的時候，PO 覺得東西做完了，可以發(fā)布了，但客戶看了一圈，覺得離他預想的發(fā)布內容還有不少的差距。很明顯吧，大家對于完成的“定義”完全不同。 所以，在團隊和相關方的參與中，定義一個統(tǒng)一的對于“完成”的定義是一個重要的工作。比如說，我們對于開發(fā)工作的完成定義應該是達到多少的測試覆蓋率并且全部通過，代碼是否要在迭代評審后再進行人工評審，測試用例要詳細到什么程度等等。而在發(fā)布前對于功能特性的定義則包括是否有全量測試，是否要進行回歸測試，是否應該核對用戶故事，上線前的問題是否修復，著重修復哪些級別的問題之類的定義都是要清晰明確的。 此外，還有對于迭代沖刺的過程中，每天的 DoD （代碼要提交、測試要運行之類的）；用戶故事在核實中以什么標準確定完成的 DoD（是否遵循規(guī)則、是否有測試化用例等）等等。 從這里可以看出，完成的定義是非常重要的，而且另一個重要方面是，我們通過完成的定義可以與相關方達到一致。讓所有項目的參與人都能明確地知道現(xiàn)在的迭代已經完成了多少工作，還差多少完成，這個完成是大家都明白都一致理解的那個完成。 敏捷模型這里的敏捷模型也是主要針對軟件開發(fā)的。比如說 用例圖 、 數(shù)據模型（UML）、界面設計 等。用例圖在許多教材中都會說到，特別是后面我們學習 信息系統(tǒng)項目管理師 時會重點記住一大堆圖，其中就會有這個 用例圖 。 用例圖最大的特點就是有左邊這個小人。然后它的每一個用例其實都可以看做是一個功能或者模塊。這個用例還可以繼續(xù)再分解下去。 數(shù)據模型的話就是純技術方面的內容了，主要就是面向對象中的 UML 圖。界面設計則主要是前端展示的界面草稿。這里就不多說了，有興趣的同學自己查閱下相關的資料。 線框圖線框圖對于做過產品經理的同學來說都不在話下。它們就是功能的粗繪展示。可以用于后期的界面設計和高保真原型的制作。最簡單的就像是下面這種手繪圖。 之前的文章中，我說過 Scrum 中的 PO 是不畫原型的（看情況）。不過這種線框圖還是非常便于團隊以及相關方理解的。我們絕對抵制的是那種非常高保真，花費了很多時間來制作的那種原型。但是線框圖這種方便、好用甚至你可以直接在白板上作畫的工具還是非常值得推薦的。如果一定要用 Axure 的話，我建議是有基本的鏈接跳轉就可以了，剩下的還是盡量以線框圖的形式展示。畢竟，我們要達到一致的是對于功能和界面業(yè)務流程的一致。具體的細節(jié)應該是界面設計師去摳的。 虛擬人物這也是 產品經理 的一種基本工具，就是建立一個虛擬的人物卡。這種虛擬人物卡可以建立多張，由團隊給他們角色和稱謂，就像一個真實人物的簡歷卡一樣。主要就是用于在需求分析時從不同用戶的角度來查看用戶可能關注我們的產品角度。這個一般也是和重要的相關方一起研究商討的，畢竟，需求就是從他們那里來的。既然是項目管理的課程，那么這些產品經理相關的內容大家還是自己去了解一下吧，畢竟我也不是一名 產品經理 。更重要的是，我接觸過的 產品經理 九成以上都只是畫原型圖的。 總結今天的內容一是說明了下相關方這一塊在 PMP 中是如何定義以及管理的。另一方面則是學習了一些可以與相關方建立共同目標愿景的工具。說實話，這些工具更偏 產品經理 的范疇。但是，只要是能與相關方打好關系的東西，我們都應該多了解一些。畢竟，上文中我們也提到過，相關方的滿意度對我們的項目來說非常重要。而且，重要的相關方，要么是我們的領導層，要么是我們的金主，要么是我們的上帝。你說，哪個得罪得起。不過在敏捷中，我們只要做好我們的就好了，沒有誰高誰低的問題，因此，完成的定義非常重要。今天的內容看似簡單、無關，但其實它們是能左右一個項目生死的關鍵內容。 參考文檔： 《某培訓機構教材》 《用戶故事與敏捷方法》 《高效通過PMI-ACP考試（第2版）》 《敏捷項目管理與PMI-ACP應試指南》 |
|
|
