摘要：在scrum中，sprint計畫會議（簡稱計畫會議）作為乙個sprint的開始，產品負責人（簡稱po）要和開發團隊一起確立本次sprint的目標，否則開發團隊可能就不知道做什麼，進而無法開展sprint中的活動。在scrum中，sprint計畫會議（簡稱計畫會議）作為乙個sprint的開始，產品負責人（簡稱po）要和開發團隊一起確立本次sprint的目標，否則開發團隊可能就不知道做什麼，進而無法開展sprint中的活動。
那麼如果產品負責人沒有參加計畫議會應該怎麼辦呢？
為避免造成歧義，在分析之前需要澄清一下的是，文中所說的產品負責人，主要是指自主研發專案中po或者非自主研發下的**po（非客戶人員）。在scrum指南中雖然沒有明確指出產品負責人到應該是誰（客戶or**商），但業界比較認同的是產品負責人是「客戶的代表」這種說法，即你公司自己的人作為產品負責人，由於篇幅有限不再贅述。
隨著國內越來越多的企業開始使用scrum做為敏捷轉型的方法，對於這樣的企業來說，可能會對scrum中產品負責人的職責存在一定程度上的認識偏差。無論是從scrum指南上來看，還是從其他參考資料（如《scrum 精髓》）中，原則上是要求產品負責人參加計畫會議且準時的。可隨著專案的發展壯大，需求分析、干係人數量以及複雜度等都會隨之增長，這也就導致了產品負責人的工作量呈幾何式的增長。產品負責人沒有參加計畫會議可能不僅僅是主觀認知上的原因也會被一些客觀因素所影響。
所以一般來說，導致產品負責人沒有參加計畫會議的主要原因有：
1. 產品負責人沒有明確其職責：主要體現在產品負責人沒能清楚或沒有重視其在計畫會議中的職責而沒有參加。
2. 計畫會議的召開沒有固定性：主要表現在計畫會議的召開的時間不固定，存在一定可能上和產品負責人工作計畫相衝突而沒有參加。
3. 計畫會議的效率低、時間長：主要表現在產品負責人的工作量多而複雜的情況下，計畫會議開的時間長、效率低，導致產品負責人主觀抗拒不願參加。
4. 沒有做好應對突發狀況的工作：主要體現在產品負責人因市場變化、客戶的要求等外界不確定性所影響等不能參加計畫會議。
綜上，接下來將會分別對上述分析的4個方面給出解決措施。
scrum master，在日常的工作中要做好「政委」工作，將scrum的思想滲透給scrum團隊中的每乙個人。其中，就產品負責人而言，要讓他清楚的了解，作為產品負責人在scrum框架中的作用和職責以及事件參與的重要程度等。對於計畫會議來說，原則上是要求產品負責人參加計畫會議且準時的，因為產品負責人需要和團隊一起確立sprint目標和範圍，否則可能會導致sprint的無目標或偏離目標而沒有達到預期的效果。
「沒有規矩不成方圓」，首先要立規矩（計畫）。如，在乙個正準備敏捷轉型的團隊，在其啟動會上（或其他踐行敏捷之前的活動），就要先立規矩。其中就應包含sprint的週期，以及什麼時間哪些人需要參加哪些scrum事件等。當然已經執行了一段時間的敏捷團隊，也可以重新立規矩，如果沒有（需要）的話。對於計畫會議而言，需要固定好每乙個迭代什麼時間開，開多長時間，以及參加的人員。
在日常的工作中，scrum master要做好「保姆」的工作，可以在即將要開會前「吼」一嗓子。但我們建議是以會議提醒郵件的方式，目前主流的郵件管理系統（outlook、foxmail），都可以做到「重複週期」的設定，簡單又方便的提醒到scrum團隊中的成員。
上述兩點，其實說白了，就是要在思想和流程上先僵化，要讓每個人（scrum 團隊）都知道在什麼時間就做什麼事情，保持團隊節奏，避免出現團隊中的任何人，在開會的時間還不知道要開會的情況。
此外，還應該提公升開發團隊的能力，就如scrum指南所指出的，開發團隊也可以完成產品負責人管理產品代辦列表的工作。這就需要開發團隊具備自組織的能力（關於自組織能力的建設，請留意之後我們專家團隊的faq），在我們華為雲devcloud內部，其實也一直貫徹著，人人都是產品經理的理念，做到團隊中的每乙個人都可以成為產品負責人的backup。
還有一點需要特別注意的，也是比較容易忽略的——產品負責人也是人。產品負責人也會有接孩子、開家長會、度假等工作以外的事情。這也就是傳說中的「週末事件」，所以在對scrum事件的時間安排上，應避免在一周的結束和開始進行（星期
一、星期五），以降低關鍵事件被日常生活中斷的概率。所以很多團隊會選擇星期
二、三作為sprint的開始。如果存在「週末事件」的影響（發生頻率較多），那麼這也就對應了一開始提到的，如果有需要就重新「立規矩」。
最後還需要考慮到極端情況，就是計畫會議產品經理必須參加，這往往是由未來工作調整上的突發性引起的，或其他重要價值的事項。對於這種情況，就可能不得不把會議推遲到產品負責人時間ok的時候了。如果只是延遲了幾個小時，那麼其實影響並不大，在當天晚些時間開會即可，而且其他會議也不受影響。可如果會議推遲較多，那麼很可能就是工作規劃上發生巨大變動，這就要視情況而定做調整，甚至取消該sprint。
一般來說，計畫會議可能會持續開4到8個小時。這對於產品經理來說，無疑是加重了其工作負擔，所在一定程度上是不願意接受這麼長時間的會議的，那麼就需要在會議上能提公升效率。
我們在實際開計畫會議的時候，通常將計畫會議分為上下半場。大致（不同團隊可能有所不同）如下：
這裡可以清晰的看到，乙個計畫會議被分為產品負責人和團隊一起參加的，以及開發團隊自己參加的兩個「會議」。所以實際上產品負責人不用參與完整的計畫會議，這就給產品負責人在會議上節省了時間。在這一過程中scrum master要能掌控好，避免產品負責人參與到了細節和技術實現上的討論中。
這裡還需要提到的是，計畫會議的乙個重要輸入項，乙個有優先順序並且合適顆粒度大小使用者故事的待辦工作列表，而且其中需求細節已經在梳理會上就被開發團隊所知曉了。這也要求了產品負責任人要重視使用者故事的質量，這實際上也是在幫助自己減輕溝通上的負擔，提公升效率。更多關於使用者故事的編寫請參考《「
使用者故事等於需求說明
」——
你一定沒有寫好使用者故事》 。
對於只參加半場會議的產品負責人，如果整個流程上控制的好，那麼其結果，就是可以提公升產品負責人參加會議的可能性和意願性的。當然，這個上下半場也不是完全絕對沒問題的，如在下半場開發團隊發現sprint目標可能會有些變動，那麼可以再和產品負責人做輕量級的對其和調整，一般問題不大。
以上關於產品負責人沒有參加計畫會議的分析，是根據常見的情況所論述的，但肯定不僅於此，因為真正的實際情況永遠是變幻莫測的，我們需要一直圍繞著敏捷的核心思想開展活動和處理解決問題，在踐行的過程中，採取是「先僵化、後優化、再固化」的方針，不斷完善和改進我們的流程和思想，進而提公升效能和競爭力。
《scrum 指南》
《scrum 精髓》
點選關注，第一時間了解華為雲新鮮技術~
如何拓展產品負責人的角色
scrum中的產品負責人 product owner 是業務和開發之間的介面。在複雜大型企業中，由於有複雜的產品和需要做很多的決策，使得由一人充當這樣的角色通常並不可行。在這種情況下，就需要擴充產品負責人的角色。u0026 xd n 在benelux 2013 xp days大會上，timo pun...
產品上線前，相關負責人需實際體驗成品
解決問題 重點解決己成功下單的客戶被臨時告知缺貨的問題,保證有貨。優化 如圖所示，顯示了很多預警庫存為0的sku。浪費預警資源。很簡單的優化，加個過濾條件，必須是審核通過的預警庫存，並且實際庫存小於等於預警庫存的，才提示給採購部門。並且把實際庫存列字型加粗變紅。so明顯的優化為什麼要等到最後才發現呢...
產品負責人應該交付有推動作用的需求說明
jeff sutherland最近提出 使用者故事應該是 有推動作用的需求說明 enabling specification 能讓團隊不必跟產品負責人反覆對話，就能高效地往前推進工作。要想讓敏捷團隊達到最佳效率，使用者故事必須是有推動作用的需求說明。如果做不到這一點，團隊在sprint中就要不斷跟產...