scrum中的產品負責人（product owner）是業務和開發之間的介面。在複雜大型企業中，由於有複雜的產品和需要做很多的決策，使得由一人充當這樣的角色通常並不可行。在這種情況下，就需要擴充產品負責人的角色。
\u0026#xd;\n
在benelux 2013 xp days大會上，timo punkka將在乙個專題討論會上討論了拓展產品負責人角色的可能解決方案。infoq就產品負責人的角色、精益管理和客戶協作等問題採訪了他。
\u0026#xd;\n
infoq：你在benelux xp days 2013上的主題演講將談到擴充套件產品負責人角色。你能舉例子說明嗎，以及什麼時候需要這樣做？
\u0026#xd;\n
timo：有很多原因。顯然，當企業規模擴大時，其可擴充套件性將會影響各方面；技術、業務、戰略等，但在我看來，最主要的原因是需要不斷作出決策的數量。企業需要在不同的產品和產品線、短期收入和長期生存、銷售產品和銷售服務等等之間取得平衡。作出決策需要用最佳最可靠的資訊，並且每個人都需要保持一致把這些決策付諸行動。做出這些權衡決策通常被稱為路線圖或組合管理。對於乙個產品負責人來說，工作顯得太多了。\u0026#xd;\n\u0026#xd;\n也就是說，很多時候是敏捷是以開發開始，並有乙個產品負責人――這樣的團隊模式有助於讓開發團隊對優先順序有清晰的認識。然而，在工作分配到團隊的backlog前，依然有大量需要做決策的事情。這就是擴充套件其角色所帶來的幫助。
infoq：有時我知道團隊對產品負責人有很高的期望，而產品負責人卻很難滿足這些期望，你是這樣認為嗎？
\u0026#xd;\n
timo：是的，我也這樣認為。而且不單是開發團隊，就連作為企業也認為如果選擇了敏捷開發模型，則只關注開發功能 ――並且仍然希望這會解決一切問題。事實並非如此。敏捷開發將最終影響整個企業。例如在開發和產品管理中，可以立竿見影地看到效果。是的，我的意思是產品管理者是在使用敏捷的企業中。 \t\u0026#xd;\n\u0026#xd;\n也許產品負責人不應設定這些期望，但並沒有意識到還有什麼其他實際上是需要去做的，以及它們需要如何改變。產品負責人面對的事情的狀態，可能是利益相關者（stakeholders）們要在危機會議、多種方案之間艱難抉擇其優先順序並找出理由。正因為如此，他們沒有意識到，其實可以自己主動地工作，以更好地了解並對路線圖和投資作出決策。
\u0026#xd;\n每乙個人都需要對這樣的工作負責。對於乙個產品負責人來說任務顯得過於繁重了。
infoq：如何做才能擴充套件產品負責人的角色？
\u0026#xd;\n
timo：我經常談到層次――在敏捷的場景下也許令人驚訝。我的意思不是指象命令鏈那樣的層次，而是指專注於不同時間跨度的角色層次結構。角色專注於那些影響不同時間跨度的決策。例如，產品負責人通常專注於當前的版本，但產品管理更應關注跨越幾個版本的路線圖。使用象遊戲魂斗羅那樣，在角色和規劃層次之間構建的合作等級，是具有協作性和能動態變化。專注於特定的時間跨度的人並不是孤立的工作，或只是每隔一段時間交接給下一手負責人。來自不同規劃層次的人會合作，這為定位和對方向的共同理解提供了機會。\u0026#xd;\n
infoq：在你的演講中，你將會談到精益組合管理。你能解析這是什麼嗎，以及它能如何在商業和敏捷it團隊之間帶來溝通的橋梁？
\u0026#xd;\n
timo：精益組合管理建立在對敏捷開發來說極其重要的魔法――公開透明之上。在許多場合我曾與一些企業一起工作，這些企業是有更多的「專案」在進行，而不是人們努力去做這些專案（譯者注：這裡作者意指傳統的軟體專案開發，沒調動人的積極性）。我們已經太習慣了，如「我們必須至少從這裡開始」的說法 ，這讓我們在專案進展中變得盲目。精益投資組合管理，或者我意思是，當我使用這個詞的時候，它指導我們限制正在做的事情的數量。其實我提倡放棄做專案的概念，並專注於在開發流程中，使用頻繁的發布。在有的環境下發布的版本可能只是乙個計畫項，但當然最好是實際上交付給使用者使用。\u0026#xd;\n\u0026#xd;\n這帶來了很多好處。一旦限制了正在進行的事情的數量，其狀態將更清晰地展現在大家眼前。擁有乙個穩定的節奏進行決策，也將能減少危機會議的次數。當我們要經常停下來重新同步計畫，我們也有機會去開發每個迭代週期中最有價值的部分，並更早關注下乙個迭代，這才更有意義。
infoq：演講中有一些真實的使用者協作的案例嗎？
\u0026#xd;\n
timo：在研討會期間，我們會做的一項工作，就是針對乙個有很複雜的分布式客戶鏈的虛構組織，完成乙個視覺化的反饋路徑矩陣。反饋是必要的，並應該盡可能有不同的形式，並要在不同的規劃層次中存在。除了敏捷開發中典型的規劃和審查會議，我們的例子還包括：客戶代表小組，不同的利益相關者群組的專題討論、來自不同利益相關者群組的參與者的專題討論、針對不同使用者體驗研究和實地考察。當客戶鏈在地理上是分布式的時候，我們還需要使用如傳統的調查和問卷的做法，但是使用它們去支援其他做法，這是更有協作性的實踐。\u0026#xd;\n
infoq報道過了11月28——29日在比利時梅赫倫舉辦的xp days benelux大會。早前，infoq採訪了大會的兩位主持關於敏捷開發新趨勢、成功的敏捷轉變和歐洲企業對敏捷的採納。
\u0026#xd;\n
檢視英文原文：how to scale the product owner role
\u0026#xd;\n
感謝張龍對本文的審校。
\u0026#xd;\n
技術負責人的三種角色
企業管理是一盤棋，而技術是支撐企業生存和發展的重要一環。因此，作為企業的技術負責人，無論企業處於發展中的哪個階段，實施管理都無外乎是要做好幾件事 定目標，在深入了解企業的資源狀況和整體目標的基礎上，做好相對固定的長期技術計畫 分任務，做好計畫以後，把計畫分解成若干技術執行人員能夠充分理解和執行到位的...
技術負責人的三種角色
from 摘要 公司的發展會經歷各種不同階段，比如初創期 發展期 穩定期或擴充套件期，也許發展中很多時候是瓶頸期 對於不同發展階段，公司的技術負責人應該承擔怎樣的角色？該挑起什麼擔子？重點該聚焦在哪些方面？企業管理是一盤棋，而技術是支撐企業生存和發展的重要一環。因此，作為企業的技術負責人，無論企業處...
技術負責人的三種角色
發表於 2014 11 11 16 12 程式設計師 高博 程式設計師 雜誌 2014年11月刊 管理實踐 團隊管理 企業管理 ctocto俱樂部 摘要 公司的發展會經歷各種不同階段，比如初創期 發展期 穩定期或擴充套件期，也許發展中很多時候是瓶頸期 對於不同發展階段，公司的技術負責人應該承擔怎樣的...