|
|
開發團隊采用敏捷時，產品管理會給他們已經超負荷的工作量中再增加更多工作，團隊因此措手不及。敏捷需要新的產品管理技巧，傳統的人員編制模型一般無法適應新的產品負責人角色。鑒于大多數產品經理已經超負荷工作，他們如何管理這些新的活動，以便從軟件項目和產品上獲得更多價值？
簡而言之，敏捷產品經理必須改變他們的工作方式，以趕上更快的開發周期以及更短的客戶反饋周期。本文將給出一個成功過渡到敏捷產品管理的概覽，指出要避免的常見陷阱是什么，應對新挑戰有哪些建議的解決方案。
傳統的產品管理角色
在討論敏捷組織中的產品經理角色前，讓我們回顧一下傳統產品經理的角色。在許多組織中，該角色往往是模糊的，而敏捷新的產品負責人角色，并沒有讓事情變得更加簡單。你是一名產品負責人或者產品經理嗎？現實情況是，極少數的大學課程致力于產品管理專業，所以大多數產品經理源自不同的背景——從市場營銷、工程、售前和售后支持，甚至來自于業務拓展背景——每種背景的觀點都傾向于自己的專業。一個組織中的產品經理可能與另一個組織中的產品經理專注于非常不同的事情（這不會讓他們更好或更差）。
話雖如此，一名“嫻熟”的產品經理通常對以下常見任務負有責任：
* 定義產品愿景以及路線圖
* 建立商業案例，以獲得資金
* 確定發布產品的最佳市場時機
* 細分市場，識別目標受眾
* 識別并跟蹤競爭對手
* 成為開發團隊的“客戶心聲”
* 識別要解決的客戶需求
* 確定下一次發布要交付的功能
* 記錄產品需求
* 向管理人員和其他利益相關者提供最新的發布狀態
* 為公司最大化市場發布的影響做好準備
* 教授市場部門如何定位產品
* 教授銷售部門如何銷售產品
* 教授專業客服如何支持客戶
* 對發布中已知的“陷阱”和備忘提供支持
無論產品經理有何不同，所有傳統產品經理有一個共性。他們中很少有人會花很多時間跟開發團隊在一起，因為傳統的產品經理主要關注戰略活動，還有很長的需求文檔，讓開發團隊在未來18個月保持忙碌，18個月是傳統軟件發布花費的時間。
當開發團隊采用敏捷時，這馬上會改變……
敏捷如何改變傳統產品經理的角色
敏捷引入了一種新的產品管理角色：產品負責人（Product owner）。產品負責人主要的職責是準備產品backlog、給開發人員介紹故事并給開發團隊充當“客戶心聲”。
由于敏捷軟件開發更快的開發周期，產品負責人的角色給開發人員與客戶之間提供了關鍵的接口，在每個sprint結束時快速搜集客戶反饋，并適應不斷變化的客戶需求。這是傳統開發方法中非常缺失的角色，在客戶意見非常少的情況下，開發工作卻可以進行數月，導致軟件行業眾所周知的不良統計——罕有在預算內完成的項目、經常為時已晚、對客戶沒多大價值。
從本質上說，產品負責人的角色是把產品管理嵌入到開發團隊中，以此提醒開發人員他們的決定應該由客戶價值來驅動，提醒產品經理并非所有功能在技術上是平等的，并以此積極回應市場和客戶在產品發布之前不斷變化的需求。
終于可以建立起響應客戶需求的解決方案，這聽起來是夢幻般的消息，然而，產品經理的負擔通常在擁抱敏捷之前就已經很重了。
產品負責人的角色很耗時間：在sprint計劃上，產品負責人給開發團隊介紹接下來幾周要著手的故事。在sprint中（通常是1到4周），她監視進度、闡述故事細節、驗證完成的故事并為下一個sprint做故事調查。對于大多數產品，這可不是一份兼職工作！據Enthiosys這樣的產品管理顧問公司評估，軟件團隊采用敏捷時，產品管理的工作量會增加50%左右。
那么我們先前列出的傳統產品經理的任務有什么變化？誰與客戶需求保持聯系？誰去掌握市場趨勢和競爭對手的動向？誰去評審最近銷售的得失？誰為新產品制定包裝和價格？誰去指導銷售團隊和支持團隊新的功能？
除非在你的團隊中有超級英雄般的產品經理——那些晚上只需要4小時不到的睡眠時間、而且沒有工作與生活的平衡、可以接受50%更多工作的人——否則總有事情會搞砸。
避免一人獨大的陷阱
團隊采用敏捷時，產品經理往往不是開發團隊的正駕駛，而開發團隊則越來越習慣敏捷實踐——從短時間盒到持續集成和測試驅動開發。那時，往往是技術領袖承擔產品負責人的角色。一旦開發團隊熟悉了這些關鍵的開發概念，并開始更快速地交付更好的軟件，他們就會想要確保他們的努力會給用戶帶來更大的價值，那時，產品負責人的角色需要一些“真正的”產品管理技能。通常，這就是傳統產品經理被拉進來參與敏捷體驗的時候。
我見過的最大陷阱，是簡單地把已有的產品經理轉變為產品負責人。每個人都關注于采用敏捷時，這似乎是自然而然的轉變，但代價沉重。當公司陷入該陷阱，鑒于工作日仍然只有8到12小時，傳統產品經理被迫決定他們以后每天的工作重點時，有兩件事情會發生：
最常見的情形是，產品經理完全接受她新的產品負責人角色，學習編寫好的故事，并去了解她的開發團隊。這通常是非常激動人心的時刻，尤其是如果你有一位中立的敏捷教練，不去指出在許多年沒有協作后可能會發生的事情時。但是，這讓產品負責人沒有時間去做傳統的產品管理任務，因此那些工作就半途而廢了。風險是一個非常高產的開發團隊在錯誤的時間，交付以錯誤價格啟動的軟件，銷售和支持不足，導致產品無法滿足目標受眾，并帶來預期的收入。軟件失敗往往由市場失敗導致，而不是開發失敗導致，因此在只配備產品負責人角色（但沒有留下產品管理資源去完成最需要的、戰略性的產品管理任務）的情況下，交付解決方案給市場時，會冒著失敗的風險。
一個不太常見的情形（但影響相同）是產品經理不接受產品負責人的角色。當產品經理有更多“全局性”的謀略，并對產品負責人日常的戰術職責不感興趣時，就會發生這種情況。此時，團隊的需求不清，困難重重，在他們前進時總在不愉快地做假設，因為問題出現時沒有“客戶的心聲”。一個要監測的紅色警示是用戶故事沒有驗收標準。由于傳統產品經理不會參與需求的驗證（最常見的是質量保證小組），編寫驗收標準經常是一種挑戰，并很快就被忽視。沒有定義良好驗收標準的故事，冒著在sprint結束時不被接受的風險，當產品負責人和開發團隊忙于“但我以為你認為……”的討論時，會令人沮喪，并需要代價高昂的返工去修正原來的故事。當完成標準（definition of done）沒有明確的驗收標準時，其代價是故事不斷被返工，相關的開發生產力也會下降。
因此，公司轉向敏捷時，產品管理怎么去適應，并避免上面討論的陷阱呢？
產品管理適應敏捷需要的實用建議
讓我們來探討一些經驗教訓，我真希望當我從傳統產品經理轉變為敏捷產品經理時，我已經了解到這些。
停止不交付實際客戶價值的工作，無論是直接還是間接的，并溝通你將要停止的工作。這似乎是一種明顯的倒退，但如果你真地采用這種思維狀態，你會發現真的有許多小事情不會給客戶帶去任何價值。例如，在你的組織中，有沒有報告是某個人自己用來追蹤，卻只有很少的客戶價值？或者你是否一直在開發銷售工具，卻對銷售團隊沒有多少價值？
偏愛現場交互勝過冗長的文檔，無論它是描述業務案例還是經營管理，或是記錄需求。這是一個方面，你可能要有一種信念，那就是相比那些閉塞的需求文檔（以及比薩），值得信賴的開發人員更具創造力和生產力。要相信：當人們被賦予做決定的權力時，他們會竭盡全力。
實踐嚴格的優先級排名。需求、業務目標或者你們日常的活動是否排列過優先級，分配實際的優先級數字而不要使用MoSCow優先級方法（必須有must-have，應該有shold-have，可以有could-have，不會有won’t-have），通常最終會有太多的必須有和應該有。如果這種做法對你有點困難，那就假設某天你只有一名開發人員。那么你會讓他做什么？那就是你首要的需求。
擁抱變化，把它當作機會而不是威脅。實際上這可以成為產品經理的巨大負擔。基于過去sprint中接收到的客戶反饋，每個 sprint都去重新評估團隊將要從事的工作。你不必在一份巨大的、需要花費18個月去完成的需求文檔上簽署名字而遠離了你的生活。你甚至可以犯錯，并在 2周后糾正那些錯誤。
識別關鍵的產品管理任務
對所有的產品管理任務排列等級。咱們來看看：采用敏捷時，大多數產品經理會對新加的產品負責人角色不知所措。一定要識別出哪些任務對你們產品的成功最為關鍵，直到你的產品管理團隊配備了足夠多的人員，去履行新的敏捷職責。減少甚至丟棄一些其他任務（至少是當下），并清晰地同你的組織溝通你的側重點會在哪里、什么可能不再會交付。至于所有產品管理任務的概覽，可以參考實用的營銷框架（Pragmatic Marketing Framework），該文檔最近為響應產品負責人這一角色更新過。
不要放過戰略部分。你們選擇的關鍵產品管理任務應該有良好數量的對內任務（關注于團隊），以及對外任務（關注組織的其他方面和組織外部）。對內和對外工作的比例可能不同，這取決于你們正在開發的軟件，以及你們產品的市場定位。例如，對于一個完善的產品，每次有新的發布時，不需要像一個嶄新的產品進入嶄新的市場一樣，實施很多銷售工作。
配備適合的人員去履行新的角色和職責
假設你需要三頭六臂。在極少數情況下，一個人既可以是產品負責人（策略上對內的角色），又是產品經理（策略上對外的角色）。可以開始考慮誰能幫助處理一些產品管理的任務。固執的組織結構會讓這成為一個挑戰，因此獲得管理層的支持可能會有幫助。如果不行，同大家說清楚你在分身乏術的情況下，什么是無法完成的。
授權承擔產品負責人角色的人能夠接觸到團隊，一旦完成故事，要求他們去驗證故事。最重要的是，不要讓產品負責人把履行對外工作作為其首要的團隊責任，從而分散弱化了產品負責人的主要職責。
小心配對個人和產品管理的角色。為了實現這兩個戰略和新戰術上的產品管理功能，選才時要對號入座。一般的指導原則是，善于分析和注重細節的人往往能當好產品負責人。關注大局、外向的人往往能當好產品經理。業務分析師可以成為很好的產品負責人，產品營銷經理非常適合一些戰略性的產品管理任務，比如競爭對手分析、為發布啟用銷售和技術支持。不要太執著于職稱——它們會造成障礙——給人員分配產品管理任務時，要分配他們熟練并有激情的任務。如果你很幸運，在你的產品管理隊伍中有人同時擅長戰術和戰略方面，可以考慮按功能分割他們的時間，而不是用戰略/戰術路線來分割。例如，某個人同時為某個功能集擔當產品負責人和產品經理的角色，而另一個人為其它功能集同時擔當兩個角色。在這種情況下，這兩個人要騰出時間站在一條戰線上，共享共同的產品愿景和發展路線。
更加接近你的客戶
了解要交付的客戶價值。敏捷主要關注于交付客戶價值，并消除浪費活動，因此你必須找出一種方法，讓你可以更加接近你的客戶。客戶互動的方法和實踐有很多，以下是我最喜歡的三種：
投入到社交網絡中。社交網絡的出現為產品經理提供了一個有效的機制，讓他們不需要跨越全球就能與客戶互動。它對功能的優先級還有達爾文效應，用戶可以自行提高或降低功能的優先級。只要你知道與你積極互動的用戶的相對數量，這種對話可以非常富有成果。除非你所有的用戶都是參與者（迄今罕見），否則社交網絡存在著風險，那就是讓用戶子集驅動你的產品路線。欲知更多有關產品經理使用社交網絡的情況，可以關注 Forrester的Tom Grant最近所做的工作。
利用你組織里的其他人，尤其是那些天天與客戶交流的人——銷售、銷售工程師、支持工程師以及顧問。假如你的組織在全公司內有效地使用諸如Salesforce.com一樣的客戶關系管理系統（CRM），那么你可以利用這一個技術，將客戶意見匯集起來。使用CRM系統來采集客戶檔案和收益潛力時，它可以成為一個金礦，產品經理可以調閱該系統，評估某個功能請求在其客戶群體中的重要性，同時也可以迅速確定由哪些客戶來驗證某些功能。客戶越是關心某個功能，你越可能迅速得到真實的反饋。在 Forrester 的這篇文章中，可以了解更多有關CRM系統可為產品經理做些什么的內容。
投入到產品理事會中。如果你無法采納以上兩種方法，你仍然需要聽聽那些與客戶交談的人。一個節省時間的方法是建立一個由跨職能代表組成的產品理事會。每個月你都傾聽來自業務上方方面面的意見，搜集大家的意見并加入到產品路線中。閱讀博文使用產品理事會來駕馭你的開發可以了解更多這方面的內容。
磨練你的產品管理技能以適應敏捷的需要
經常更新你的產品路線，讓它們成為有效的溝通工具，而不是合同的重擔——至少一個季度一次，但我喜歡每個月一次。包括明確的“基于客戶反饋的變更主題”的公開聲明，用以加強你們做變更的開放性，同時澄清敏捷產品路線事實上代表著一種意圖，而不是承諾，你們的承諾是交付價值，而不是具體的功能，因為客戶需求改變時那些功能馬上就會改變。
學習把路線功能分割到sprint故事中 。Standish 集團的研究發現，45%的功能從來不會被使用，只有20%的功能經常或總是被使用。我們的目標是側重在20%必須具備的功能上，并放棄其余的。往往我們開發了過猶不及的功能，卻發現只有很少用戶會使用它們，或者它們會增加產品的復雜度。把重點放在交付某個功能絕對必須具備的故事上，并讓用戶告訴你他們何時需要更多功能。使用短發布周期，你很少會有興趣把精力放在市場價值低的功能上，并可以在下一個發布中對用戶需求做出快速響應。同時如果你的客戶無法接受1年多次發布的頻率，你仍然可以向他們演示新增的功能以獲取他們的反饋，讓他們對明年的發布感到興奮。確定20%重點關注的功能，要把功能分割成小而有價值的故事，在每個sprint結束時逐步交付。掌握這種分割方法是最需要磨練的技能之一。請閱讀“切割故事的20種方法”，以了解分割故事卻仍能交付價值的方法。
讓你的故事（以及它們的驗收標準）保持直白。在你們產品的backlog上，最頂上的故事應該要充分調研，在sprint計劃會議上介紹給團隊時，要沒有歧義。正如之前提到的，不要跳過驗收標準，或者準備好返工的代價。與測試人員協作，最后確定每個故事的驗收標準清單。我發現調研故事以及訪問客戶的最佳時機是在sprint開始，當開發人員有足夠的工作時間，而且往往問題也很少的時候。
總結
當我們了解情況后，就知道采用敏捷并不代表產品經理的結束。你會面臨的最大轉變是某個擁有產品管理經驗的人會嵌入到開發團隊中。恰當地配備好人員并履行新的產品負責人角色，同時不丟失產品管理戰略角色的位置，是改變產品管理實現敏捷企業的關鍵。
那些沒有按照敏捷需求重新評估新的產品管理角色，用他們當前的產品經理來勉強應付敏捷管理的組織，無法完全享受到實現敏捷企業的益處。那些利用實用指導的組織則會處于讓人羨慕的境地，總能給他們的市場交付富有競爭力的解決方案。
我真心希望這篇文章可以幫你避免一些常見的陷阱，我個人過渡到敏捷產品管理時已經經歷過，與你分享的實用提示可以輔助這種迫切需要轉型的公司過渡到敏捷上。欲了解更多信息，請下載在2009敏捷大會上演示過的關于本文重點的幻燈片。
關于Catherine Connor
Catherine Connor目前是Rally軟件的產品負責人，她在那里負責推動Rally整套的敏捷管理方案。此前，Catherine把一個富有創造力的產品管理方案推向了市場，整合了敏捷項目管理和客戶關系管理系統，以縮小客戶、銷售和開發人員之間的距離。在Rally任職前，Catherine在Borland 軟件工作，她在那里開始應用敏捷方法，同時她是用IBM Rational軟件產品做需求管理的積極支持者。她的經驗使她很適合記錄從傳統產品管理過渡到敏捷產品管理的最佳實踐和陷阱。Catherine的編程經驗，以及實現軟件方案時對軟件客戶的支持經驗超過20年。
it知識庫：如何改變產品管理才能實現敏捷企業，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
