開發(fā)團隊采用敏捷時，產(chǎn)品管理會給他們已經(jīng)超負荷的工作量中再增加更多工作，團隊因此措手不及。敏捷需要新的產(chǎn)品管理技巧，傳統(tǒng)的人員編制模型一般無法適應(yīng)新的產(chǎn)品負責(zé)人角色。鑒于大多數(shù)產(chǎn)品經(jīng)理已經(jīng)超負荷工作，他們?nèi)绾喂芾磉@些新的活動，以便從軟件項目和產(chǎn)品上獲得更多價值？

　　簡而言之，敏捷產(chǎn)品經(jīng)理必須改變他們的工作方式，以趕上更快的開發(fā)周期以及更短的客戶反饋周期。本文將給出一個成功過渡到敏捷產(chǎn)品管理的概覽，指出要避免的常見陷阱是什么，應(yīng)對新挑戰(zhàn)有哪些建議的解決方案。

　　傳統(tǒng)的產(chǎn)品管理角色

　　在討論敏捷組織中的產(chǎn)品經(jīng)理角色前，讓我們回顧一下傳統(tǒng)產(chǎn)品經(jīng)理的角色。在許多組織中，該角色往往是模糊的，而敏捷新的產(chǎn)品負責(zé)人角色，并沒有讓事情變得更加簡單。你是一名產(chǎn)品負責(zé)人或者產(chǎn)品經(jīng)理嗎？現(xiàn)實情況是，極少數(shù)的大學(xué)課程致力于產(chǎn)品管理專業(yè)，所以大多數(shù)產(chǎn)品經(jīng)理源自不同的背景——從市場營銷、工程、售前和售后支持，甚至來自于業(yè)務(wù)拓展背景——每種背景的觀點都傾向于自己的專業(yè)。一個組織中的產(chǎn)品經(jīng)理可能與另一個組織中的產(chǎn)品經(jīng)理專注于非常不同的事情（這不會讓他們更好或更差）。

　　話雖如此，一名“嫻熟”的產(chǎn)品經(jīng)理通常對以下常見任務(wù)負有責(zé)任：

　　* 定義產(chǎn)品愿景以及路線圖
　　* 建立商業(yè)案例，以獲得資金
　　* 確定發(fā)布產(chǎn)品的最佳市場時機
　　* 細分市場，識別目標受眾
　　* 識別并跟蹤競爭對手
　　* 成為開發(fā)團隊的“客戶心聲”
　　* 識別要解決的客戶需求
　　* 確定下一次發(fā)布要交付的功能
　　* 記錄產(chǎn)品需求
　　* 向管理人員和其他利益相關(guān)者提供最新的發(fā)布狀態(tài)
　　* 為公司最大化市場發(fā)布的影響做好準備
　　* 教授市場部門如何定位產(chǎn)品
　　* 教授銷售部門如何銷售產(chǎn)品
　　* 教授專業(yè)客服如何支持客戶
　　* 對發(fā)布中已知的“陷阱”和備忘提供支持

　　無論產(chǎn)品經(jīng)理有何不同，所有傳統(tǒng)產(chǎn)品經(jīng)理有一個共性。他們中很少有人會花很多時間跟開發(fā)團隊在一起，因為傳統(tǒng)的產(chǎn)品經(jīng)理主要關(guān)注戰(zhàn)略活動，還有很長的需求文檔，讓開發(fā)團隊在未來18個月保持忙碌，18個月是傳統(tǒng)軟件發(fā)布花費的時間。

　　當開發(fā)團隊采用敏捷時，這馬上會改變……

　　敏捷如何改變傳統(tǒng)產(chǎn)品經(jīng)理的角色

　　敏捷引入了一種新的產(chǎn)品管理角色：產(chǎn)品負責(zé)人（Product owner）。產(chǎn)品負責(zé)人主要的職責(zé)是準備產(chǎn)品backlog、給開發(fā)人員介紹故事并給開發(fā)團隊充當“客戶心聲”。

　　由于敏捷軟件開發(fā)更快的開發(fā)周期，產(chǎn)品負責(zé)人的角色給開發(fā)人員與客戶之間提供了關(guān)鍵的接口，在每個sprint結(jié)束時快速搜集客戶反饋，并適應(yīng)不斷變化的客戶需求。這是傳統(tǒng)開發(fā)方法中非常缺失的角色，在客戶意見非常少的情況下，開發(fā)工作卻可以進行數(shù)月，導(dǎo)致軟件行業(yè)眾所周知的不良統(tǒng)計——罕有在預(yù)算內(nèi)完成的項目、經(jīng)常為時已晚、對客戶沒多大價值。

　　從本質(zhì)上說，產(chǎn)品負責(zé)人的角色是把產(chǎn)品管理嵌入到開發(fā)團隊中，以此提醒開發(fā)人員他們的決定應(yīng)該由客戶價值來驅(qū)動，提醒產(chǎn)品經(jīng)理并非所有功能在技術(shù)上是平等的，并以此積極回應(yīng)市場和客戶在產(chǎn)品發(fā)布之前不斷變化的需求。

　　終于可以建立起響應(yīng)客戶需求的解決方案，這聽起來是夢幻般的消息，然而，產(chǎn)品經(jīng)理的負擔通常在擁抱敏捷之前就已經(jīng)很重了。

　　產(chǎn)品負責(zé)人的角色很耗時間：在sprint計劃上，產(chǎn)品負責(zé)人給開發(fā)團隊介紹接下來幾周要著手的故事。在sprint中（通常是1到4周），她監(jiān)視進度、闡述故事細節(jié)、驗證完成的故事并為下一個sprint做故事調(diào)查。對于大多數(shù)產(chǎn)品，這可不是一份兼職工作！據(jù)Enthiosys這樣的產(chǎn)品管理顧問公司評估，軟件團隊采用敏捷時，產(chǎn)品管理的工作量會增加50%左右。

　　那么我們先前列出的傳統(tǒng)產(chǎn)品經(jīng)理的任務(wù)有什么變化？誰與客戶需求保持聯(lián)系？誰去掌握市場趨勢和競爭對手的動向？誰去評審最近銷售的得失？誰為新產(chǎn)品制定包裝和價格？誰去指導(dǎo)銷售團隊和支持團隊新的功能？

　　除非在你的團隊中有超級英雄般的產(chǎn)品經(jīng)理——那些晚上只需要4小時不到的睡眠時間、而且沒有工作與生活的平衡、可以接受50%更多工作的人——否則總有事情會搞砸。

　　避免一人獨大的陷阱

　　團隊采用敏捷時，產(chǎn)品經(jīng)理往往不是開發(fā)團隊的正駕駛，而開發(fā)團隊則越來越習(xí)慣敏捷實踐——從短時間盒到持續(xù)集成和測試驅(qū)動開發(fā)。那時，往往是技術(shù)領(lǐng)袖承擔產(chǎn)品負責(zé)人的角色。一旦開發(fā)團隊熟悉了這些關(guān)鍵的開發(fā)概念，并開始更快速地交付更好的軟件，他們就會想要確保他們的努力會給用戶帶來更大的價值，那時，產(chǎn)品負責(zé)人的角色需要一些“真正的”產(chǎn)品管理技能。通常，這就是傳統(tǒng)產(chǎn)品經(jīng)理被拉進來參與敏捷體驗的時候。

　　我見過的最大陷阱，是簡單地把已有的產(chǎn)品經(jīng)理轉(zhuǎn)變?yōu)楫a(chǎn)品負責(zé)人。每個人都關(guān)注于采用敏捷時，這似乎是自然而然的轉(zhuǎn)變，但代價沉重。當公司陷入該陷阱，鑒于工作日仍然只有8到12小時，傳統(tǒng)產(chǎn)品經(jīng)理被迫決定他們以后每天的工作重點時，有兩件事情會發(fā)生：

　　最常見的情形是，產(chǎn)品經(jīng)理完全接受她新的產(chǎn)品負責(zé)人角色，學(xué)習(xí)編寫好的故事，并去了解她的開發(fā)團隊。這通常是非常激動人心的時刻，尤其是如果你有一位中立的敏捷教練，不去指出在許多年沒有協(xié)作后可能會發(fā)生的事情時。但是，這讓產(chǎn)品負責(zé)人沒有時間去做傳統(tǒng)的產(chǎn)品管理任務(wù)，因此那些工作就半途而廢了。風(fēng)險是一個非常高產(chǎn)的開發(fā)團隊在錯誤的時間，交付以錯誤價格啟動的軟件，銷售和支持不足，導(dǎo)致產(chǎn)品無法滿足目標受眾，并帶來預(yù)期的收入。軟件失敗往往由市場失敗導(dǎo)致，而不是開發(fā)失敗導(dǎo)致，因此在只配備產(chǎn)品負責(zé)人角色（但沒有留下產(chǎn)品管理資源去完成最需要的、戰(zhàn)略性的產(chǎn)品管理任務(wù)）的情況下，交付解決方案給市場時，會冒著失敗的風(fēng)險。

　　一個不太常見的情形（但影響相同）是產(chǎn)品經(jīng)理不接受產(chǎn)品負責(zé)人的角色。當產(chǎn)品經(jīng)理有更多“全局性”的謀略，并對產(chǎn)品負責(zé)人日常的戰(zhàn)術(shù)職責(zé)不感興趣時，就會發(fā)生這種情況。此時，團隊的需求不清，困難重重，在他們前進時總在不愉快地做假設(shè)，因為問題出現(xiàn)時沒有“客戶的心聲”。一個要監(jiān)測的紅色警示是用戶故事沒有驗收標準。由于傳統(tǒng)產(chǎn)品經(jīng)理不會參與需求的驗證（最常見的是質(zhì)量保證小組），編寫驗收標準經(jīng)常是一種挑戰(zhàn)，并很快就被忽視。沒有定義良好驗收標準的故事，冒著在sprint結(jié)束時不被接受的風(fēng)險，當產(chǎn)品負責(zé)人和開發(fā)團隊忙于“但我以為你認為……”的討論時，會令人沮喪，并需要代價高昂的返工去修正原來的故事。當完成標準（definition of done）沒有明確的驗收標準時，其代價是故事不斷被返工，相關(guān)的開發(fā)生產(chǎn)力也會下降。

　　因此，公司轉(zhuǎn)向敏捷時，產(chǎn)品管理怎么去適應(yīng)，并避免上面討論的陷阱呢？

　　產(chǎn)品管理適應(yīng)敏捷需要的實用建議

　　讓我們來探討一些經(jīng)驗教訓(xùn)，我真希望當我從傳統(tǒng)產(chǎn)品經(jīng)理轉(zhuǎn)變?yōu)槊艚莓a(chǎn)品經(jīng)理時，我已經(jīng)了解到這些。

　　停止不交付實際客戶價值的工作，無論是直接還是間接的，并溝通你將要停止的工作。這似乎是一種明顯的倒退，但如果你真地采用這種思維狀態(tài)，你會發(fā)現(xiàn)真的有許多小事情不會給客戶帶去任何價值。例如，在你的組織中，有沒有報告是某個人自己用來追蹤，卻只有很少的客戶價值？或者你是否一直在開發(fā)銷售工具，卻對銷售團隊沒有多少價值？

　　偏愛現(xiàn)場交互勝過冗長的文檔，無論它是描述業(yè)務(wù)案例還是經(jīng)營管理，或是記錄需求。這是一個方面，你可能要有一種信念，那就是相比那些閉塞的需求文檔（以及比薩），值得信賴的開發(fā)人員更具創(chuàng)造力和生產(chǎn)力。要相信：當人們被賦予做決定的權(quán)力時，他們會竭盡全力。

　　實踐嚴格的優(yōu)先級排名。需求、業(yè)務(wù)目標或者你們?nèi)粘５幕顒邮欠衽帕羞^優(yōu)先級，分配實際的優(yōu)先級數(shù)字而不要使用MoSCow優(yōu)先級方法（必須有must-have，應(yīng)該有shold-have，可以有could-have，不會有won’t-have），通常最終會有太多的必須有和應(yīng)該有。如果這種做法對你有點困難，那就假設(shè)某天你只有一名開發(fā)人員。那么你會讓他做什么？那就是你首要的需求。

　　擁抱變化，把它當作機會而不是威脅。實際上這可以成為產(chǎn)品經(jīng)理的巨大負擔。基于過去sprint中接收到的客戶反饋，每個 sprint都去重新評估團隊將要從事的工作。你不必在一份巨大的、需要花費18個月去完成的需求文檔上簽署名字而遠離了你的生活。你甚至可以犯錯，并在 2周后糾正那些錯誤。

    識別關(guān)鍵的產(chǎn)品管理任務(wù)

    對所有的產(chǎn)品管理任務(wù)排列等級。咱們來看看：采用敏捷時，大多數(shù)產(chǎn)品經(jīng)理會對新加的產(chǎn)品負責(zé)人角色不知所措。一定要識別出哪些任務(wù)對你們產(chǎn)品的成功最為關(guān)鍵，直到你的產(chǎn)品管理團隊配備了足夠多的人員，去履行新的敏捷職責(zé)。減少甚至丟棄一些其他任務(wù)（至少是當下），并清晰地同你的組織溝通你的側(cè)重點會在哪里、什么可能不再會交付。至于所有產(chǎn)品管理任務(wù)的概覽，可以參考實用的營銷框架（Pragmatic Marketing Framework），該文檔最近為響應(yīng)產(chǎn)品負責(zé)人這一角色更新過。

　　不要放過戰(zhàn)略部分。你們選擇的關(guān)鍵產(chǎn)品管理任務(wù)應(yīng)該有良好數(shù)量的對內(nèi)任務(wù)（關(guān)注于團隊），以及對外任務(wù)（關(guān)注組織的其他方面和組織外部）。對內(nèi)和對外工作的比例可能不同，這取決于你們正在開發(fā)的軟件，以及你們產(chǎn)品的市場定位。例如，對于一個完善的產(chǎn)品，每次有新的發(fā)布時，不需要像一個嶄新的產(chǎn)品進入嶄新的市場一樣，實施很多銷售工作。

　　配備適合的人員去履行新的角色和職責(zé)

　　假設(shè)你需要三頭六臂。在極少數(shù)情況下，一個人既可以是產(chǎn)品負責(zé)人（策略上對內(nèi)的角色），又是產(chǎn)品經(jīng)理（策略上對外的角色）。可以開始考慮誰能幫助處理一些產(chǎn)品管理的任務(wù)。固執(zhí)的組織結(jié)構(gòu)會讓這成為一個挑戰(zhàn)，因此獲得管理層的支持可能會有幫助。如果不行，同大家說清楚你在分身乏術(shù)的情況下，什么是無法完成的。

　　授權(quán)承擔產(chǎn)品負責(zé)人角色的人能夠接觸到團隊，一旦完成故事，要求他們?nèi)ヲ炞C故事。最重要的是，不要讓產(chǎn)品負責(zé)人把履行對外工作作為其首要的團隊責(zé)任，從而分散弱化了產(chǎn)品負責(zé)人的主要職責(zé)。

　　小心配對個人和產(chǎn)品管理的角色。為了實現(xiàn)這兩個戰(zhàn)略和新戰(zhàn)術(shù)上的產(chǎn)品管理功能，選才時要對號入座。一般的指導(dǎo)原則是，善于分析和注重細節(jié)的人往往能當好產(chǎn)品負責(zé)人。關(guān)注大局、外向的人往往能當好產(chǎn)品經(jīng)理。業(yè)務(wù)分析師可以成為很好的產(chǎn)品負責(zé)人，產(chǎn)品營銷經(jīng)理非常適合一些戰(zhàn)略性的產(chǎn)品管理任務(wù)，比如競爭對手分析、為發(fā)布啟用銷售和技術(shù)支持。不要太執(zhí)著于職稱——它們會造成障礙——給人員分配產(chǎn)品管理任務(wù)時，要分配他們熟練并有激情的任務(wù)。如果你很幸運，在你的產(chǎn)品管理隊伍中有人同時擅長戰(zhàn)術(shù)和戰(zhàn)略方面，可以考慮按功能分割他們的時間，而不是用戰(zhàn)略/戰(zhàn)術(shù)路線來分割。例如，某個人同時為某個功能集擔當產(chǎn)品負責(zé)人和產(chǎn)品經(jīng)理的角色，而另一個人為其它功能集同時擔當兩個角色。在這種情況下，這兩個人要騰出時間站在一條戰(zhàn)線上，共享共同的產(chǎn)品愿景和發(fā)展路線。

    更加接近你的客戶

　　了解要交付的客戶價值。敏捷主要關(guān)注于交付客戶價值，并消除浪費活動，因此你必須找出一種方法，讓你可以更加接近你的客戶。客戶互動的方法和實踐有很多，以下是我最喜歡的三種：

　　投入到社交網(wǎng)絡(luò)中。社交網(wǎng)絡(luò)的出現(xiàn)為產(chǎn)品經(jīng)理提供了一個有效的機制，讓他們不需要跨越全球就能與客戶互動。它對功能的優(yōu)先級還有達爾文效應(yīng)，用戶可以自行提高或降低功能的優(yōu)先級。只要你知道與你積極互動的用戶的相對數(shù)量，這種對話可以非常富有成果。除非你所有的用戶都是參與者（迄今罕見），否則社交網(wǎng)絡(luò)存在著風(fēng)險，那就是讓用戶子集驅(qū)動你的產(chǎn)品路線。欲知更多有關(guān)產(chǎn)品經(jīng)理使用社交網(wǎng)絡(luò)的情況，可以關(guān)注 Forrester的Tom Grant最近所做的工作。

　　利用你組織里的其他人，尤其是那些天天與客戶交流的人——銷售、銷售工程師、支持工程師以及顧問。假如你的組織在全公司內(nèi)有效地使用諸如Salesforce.com一樣的客戶關(guān)系管理系統(tǒng)（CRM），那么你可以利用這一個技術(shù)，將客戶意見匯集起來。使用CRM系統(tǒng)來采集客戶檔案和收益潛力時，它可以成為一個金礦，產(chǎn)品經(jīng)理可以調(diào)閱該系統(tǒng)，評估某個功能請求在其客戶群體中的重要性，同時也可以迅速確定由哪些客戶來驗證某些功能。客戶越是關(guān)心某個功能，你越可能迅速得到真實的反饋。在 Forrester 的這篇文章中，可以了解更多有關(guān)CRM系統(tǒng)可為產(chǎn)品經(jīng)理做些什么的內(nèi)容。

　　投入到產(chǎn)品理事會中。如果你無法采納以上兩種方法，你仍然需要聽聽那些與客戶交談的人。一個節(jié)省時間的方法是建立一個由跨職能代表組成的產(chǎn)品理事會。每個月你都傾聽來自業(yè)務(wù)上方方面面的意見，搜集大家的意見并加入到產(chǎn)品路線中。閱讀博文使用產(chǎn)品理事會來駕馭你的開發(fā)可以了解更多這方面的內(nèi)容。

　　磨練你的產(chǎn)品管理技能以適應(yīng)敏捷的需要

　　經(jīng)常更新你的產(chǎn)品路線，讓它們成為有效的溝通工具，而不是合同的重擔——至少一個季度一次，但我喜歡每個月一次。包括明確的“基于客戶反饋的變更主題”的公開聲明，用以加強你們做變更的開放性，同時澄清敏捷產(chǎn)品路線事實上代表著一種意圖，而不是承諾，你們的承諾是交付價值，而不是具體的功能，因為客戶需求改變時那些功能馬上就會改變。

　　學(xué)習(xí)把路線功能分割到sprint故事中 。Standish 集團的研究發(fā)現(xiàn)，45%的功能從來不會被使用，只有20%的功能經(jīng)常或總是被使用。我們的目標是側(cè)重在20%必須具備的功能上，并放棄其余的。往往我們開發(fā)了過猶不及的功能，卻發(fā)現(xiàn)只有很少用戶會使用它們，或者它們會增加產(chǎn)品的復(fù)雜度。把重點放在交付某個功能絕對必須具備的故事上，并讓用戶告訴你他們何時需要更多功能。使用短發(fā)布周期，你很少會有興趣把精力放在市場價值低的功能上，并可以在下一個發(fā)布中對用戶需求做出快速響應(yīng)。同時如果你的客戶無法接受1年多次發(fā)布的頻率，你仍然可以向他們演示新增的功能以獲取他們的反饋，讓他們對明年的發(fā)布感到興奮。確定20%重點關(guān)注的功能，要把功能分割成小而有價值的故事，在每個sprint結(jié)束時逐步交付。掌握這種分割方法是最需要磨練的技能之一。請閱讀“切割故事的20種方法”，以了解分割故事卻仍能交付價值的方法。

　　讓你的故事（以及它們的驗收標準）保持直白。在你們產(chǎn)品的backlog上，最頂上的故事應(yīng)該要充分調(diào)研，在sprint計劃會議上介紹給團隊時，要沒有歧義。正如之前提到的，不要跳過驗收標準，或者準備好返工的代價。與測試人員協(xié)作，最后確定每個故事的驗收標準清單。我發(fā)現(xiàn)調(diào)研故事以及訪問客戶的最佳時機是在sprint開始，當開發(fā)人員有足夠的工作時間，而且往往問題也很少的時候。

　　總結(jié)

　　當我們了解情況后，就知道采用敏捷并不代表產(chǎn)品經(jīng)理的結(jié)束。你會面臨的最大轉(zhuǎn)變是某個擁有產(chǎn)品管理經(jīng)驗的人會嵌入到開發(fā)團隊中。恰當?shù)嘏鋫浜萌藛T并履行新的產(chǎn)品負責(zé)人角色，同時不丟失產(chǎn)品管理戰(zhàn)略角色的位置，是改變產(chǎn)品管理實現(xiàn)敏捷企業(yè)的關(guān)鍵。

　　那些沒有按照敏捷需求重新評估新的產(chǎn)品管理角色，用他們當前的產(chǎn)品經(jīng)理來勉強應(yīng)付敏捷管理的組織，無法完全享受到實現(xiàn)敏捷企業(yè)的益處。那些利用實用指導(dǎo)的組織則會處于讓人羨慕的境地，總能給他們的市場交付富有競爭力的解決方案。

　　我真心希望這篇文章可以幫你避免一些常見的陷阱，我個人過渡到敏捷產(chǎn)品管理時已經(jīng)經(jīng)歷過，與你分享的實用提示可以輔助這種迫切需要轉(zhuǎn)型的公司過渡到敏捷上。欲了解更多信息，請下載在2009敏捷大會上演示過的關(guān)于本文重點的幻燈片。

　　關(guān)于Catherine Connor

　　Catherine Connor目前是Rally軟件的產(chǎn)品負責(zé)人，她在那里負責(zé)推動Rally整套的敏捷管理方案。此前，Catherine把一個富有創(chuàng)造力的產(chǎn)品管理方案推向了市場，整合了敏捷項目管理和客戶關(guān)系管理系統(tǒng)，以縮小客戶、銷售和開發(fā)人員之間的距離。在Rally任職前，Catherine在Borland 軟件工作，她在那里開始應(yīng)用敏捷方法，同時她是用IBM Rational軟件產(chǎn)品做需求管理的積極支持者。她的經(jīng)驗使她很適合記錄從傳統(tǒng)產(chǎn)品管理過渡到敏捷產(chǎn)品管理的最佳實踐和陷阱。Catherine的編程經(jīng)驗，以及實現(xiàn)軟件方案時對軟件客戶的支持經(jīng)驗超過20年。

it知識庫：如何改變產(chǎn)品管理才能實現(xiàn)敏捷企業(yè)，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。