敏捷項(xiàng)目以用戶的需求進(jìn)化為核心，采用迭代、循序漸進(jìn)的方法進(jìn)行軟件開發(fā)。本文通過一個真實(shí)的案例介紹了敏捷項(xiàng)目的實(shí)踐過程和產(chǎn)品經(jīng)理在其中的角色和作用，與大家分享。

一、產(chǎn)品經(jīng)理在敏捷項(xiàng)目中的角色

在敏捷交付項(xiàng)目中，PO扮演著重要角色。PO確定產(chǎn)品的方向和愿景，定義產(chǎn)品發(fā)布的內(nèi)容、優(yōu)先級及交付時間，為產(chǎn)品ROI（profitability of product）負(fù)責(zé)，是維護(hù)產(chǎn)品需求清單（ product backlog ）的人，代表利益相關(guān)者的利益。

PO在敏捷項(xiàng)目中的主要職責(zé)如下：

1. 確定產(chǎn)品的功能；
2. 決定發(fā)布的日期和發(fā)布內(nèi)容；
3. 為產(chǎn)品的ROI負(fù)責(zé)；
4. 根據(jù)市場價值確定功能優(yōu)先級；
5. 每個sprint中，根據(jù)需要調(diào)整功能和優(yōu)先級（每個sprint開始前調(diào)整）；
6. 接受或拒絕開發(fā)團(tuán)隊(duì)的工作成果；
7. 參與Scrum Planning Meetings（Sprint計(jì)劃會議），Sprint Review Meeting（Sprint評審會）和 Sprint Retrospective Meeting（Sprint回顧會）

一句話總結(jié)PO的職責(zé)：告訴產(chǎn)品團(tuán)隊(duì)要做什么，做功能的先后順序是怎樣的，需求有變動時該如何處理。

二、如何在一個月的時間完成20個史詩級故事？

毫無疑問，這是一個impossible mission。先看著個需求是怎么來的。

筆者服務(wù)過一家做園林綠化的公司，這是一個傳統(tǒng)行業(yè)，主要承接市政工程項(xiàng)目。老板在尋找新的市場機(jī)會，他看到了客戶在信息化產(chǎn)品方面的需求，決定投入智慧園林產(chǎn)業(yè)。老板希望為客戶提供信息化、智慧化的公園物聯(lián)網(wǎng)平臺和整體解決方案，以此增加公司的業(yè)務(wù)范圍，為此公司成了新的智慧公園事業(yè)部。

在前期在經(jīng)歷了9個月的的探索并交付了一個內(nèi)部用戶項(xiàng)目后，并沒有取得預(yù)期的成果，銷售部門不知道該賣什么也不了解客戶的需求，研發(fā)部門面臨巨大的交付壓力，老板對部門的整個部門的業(yè)績不是很滿意。

我作為新項(xiàng)目的高級產(chǎn)品經(jīng)理，臨危受命，目的是就是幫助老板探索新的市場機(jī)會，盡早推出產(chǎn)品，讓銷售的兄弟可以帶著彈藥上戰(zhàn)場。

1. 愿景

愿景是描述了項(xiàng)目的發(fā)起原因以及預(yù)期的最終狀態(tài)。

–施瓦伯《scrum敏捷項(xiàng)目管理》

第一步是了解項(xiàng)目的需求。這里有兩個主要的利益相關(guān)者，一個是客戶，一個是老板。在經(jīng)過兩周的市場調(diào)研、競品分析后，我決定對老板進(jìn)行一次訪談以確定需求。經(jīng)過訪談，確認(rèn)了老板的關(guān)注點(diǎn)：

1. 盡快(最后確定下來是1個月)讓客戶看到智慧公園產(chǎn)品的樣子，包括軟件demo和硬件設(shè)備；
2. 盡可能充分展示公園的業(yè)務(wù)場景和設(shè)備(最后確認(rèn)20個業(yè)務(wù)場景，40個設(shè)備)；
3. 在項(xiàng)目啟動前，提供項(xiàng)目的預(yù)算。
4. 可以先開發(fā)一個演示產(chǎn)品(MVP)，數(shù)據(jù)可以是靜態(tài)的。

如果按照以下公式來”一鍵生成”產(chǎn)品愿景：

今天，當(dāng)【用戶群】 想要【期望的活動/結(jié)果】時，他們必須【當(dāng)前的解決方案】 。

這是不可接受的，因?yàn)椤井?dāng)前解決方案的缺點(diǎn)】。我們相信有【一種體驗(yàn)/一個場景/一項(xiàng)服務(wù)/…，是令人向往的】，我們通過【技術(shù)/方法】達(dá)成它。

那么，本項(xiàng)目的愿景就是：”今天，當(dāng)客戶想要了解我們的產(chǎn)品時，他們只能通過畫冊的方式，這種體驗(yàn)不是很直觀，他們看不到設(shè)備的狀態(tài)和運(yùn)營數(shù)據(jù)，我們要給客戶一種更接近實(shí)際效果的產(chǎn)品體驗(yàn)，我們希望通過開發(fā)一個演示產(chǎn)品達(dá)成它。”

Got it，原來老板就是想做一個演示APP!

通過這個APP客戶會可以進(jìn)行瀏覽、拖拽、點(diǎn)擊等交互操作，可以看到運(yùn)營數(shù)據(jù)和設(shè)備的狀態(tài)(演示數(shù)據(jù))，甚至可到公園的視頻監(jiān)控畫面(提前錄好視頻)。

本項(xiàng)目和BOSS溝通后決定采用敏捷項(xiàng)目交付產(chǎn)品，主要目的是:

• 簡化文檔
• 提高效率
• 盡早交付

敏捷項(xiàng)目有很多好處。其中一個就是交付可供客戶使用和驗(yàn)證的最小可行性產(chǎn)品（MVP），獲取反饋后再不斷迭代改進(jìn)，連接真實(shí)的設(shè)備和數(shù)據(jù)，最終打磨出真正符合客戶需求的爆款產(chǎn)品。

在愿景階段我們還需要確定任務(wù)角色和場景，以及發(fā)布產(chǎn)品路線圖。

2. 人物角色和場景

角色可以幫助我們確定目標(biāo)客戶，也就是“誰”的問題；場景可以是我們理解產(chǎn)品如何改變客戶的生活角，確定“在什么情況下”“干什么&遇到什么問題”。可采用頭腦風(fēng)暴和業(yè)務(wù)場景技術(shù)確定任務(wù)角色和場景，本項(xiàng)目確定任務(wù)和主要場景如下：

3. 產(chǎn)品路線圖

接下來是創(chuàng)建產(chǎn)品路線圖，產(chǎn)品路線圖是產(chǎn)品需求的高層次概述，產(chǎn)品路線圖 將用戶關(guān)注點(diǎn)/主題按優(yōu)先級排序，分成若干階段，每個階段都需要一個Sprint計(jì)劃。創(chuàng)建產(chǎn)品路線圖需遵循4 個步驟：

1. 確認(rèn)需求
2. 將需求分類或分定主題，
3. 評估相對工作量和優(yōu)先化級，
4. 評估粗略時間框架（評估sprint持續(xù)時間，以及粗略發(fā)布時間）

本項(xiàng)目是整個產(chǎn)品路線圖的第一個階段。

三、發(fā)布計(jì)劃

發(fā)布計(jì)劃是宣布產(chǎn)品對外發(fā)布的時間和功能范圍，大部分軟件項(xiàng)目以每 2 到 6 個月作為一個發(fā)布周期，一般以產(chǎn)品開發(fā)線路圖開始規(guī)劃發(fā)布。

1. 確認(rèn)優(yōu)先級

優(yōu)先級排序是根據(jù)利益相關(guān)者的關(guān)注點(diǎn)(或主題）確定版本發(fā)布的計(jì)劃。如何排列出關(guān)注點(diǎn)(或主題)的優(yōu)先級呢？

這里推薦莫斯科規(guī)則（ MoSCoW ) 排列優(yōu)先級的方法，MoSCoW將功能分為四類：

1. 必須有（Must ) ：指系統(tǒng)的基本功能
2. 應(yīng)該有 ( Should ) ：很重要但短期內(nèi)有替代解決方法的功能
3. 可以有 ( Could ) ：如果沒有時間可以不予考慮
4. 這次不會有 ( Won’t have this time ) ：客戶期望擁有但同時承認(rèn)需要在后續(xù)發(fā)布中實(shí)現(xiàn)

本項(xiàng)目討論后確定的優(yōu)先級如下：

2. 選擇迭代長度

團(tuán)隊(duì)所有成員一起選擇一個適合的 Sprint 長度，一般建議1～4周。本項(xiàng)目的一個sprint的長度是2周時間，分成兩個sprint，共四周時間。

3. 任務(wù)估算

（1）史詩故事(Epic story)

史詩故事是故事的主干，相當(dāng)于用戶故事的大綱。本項(xiàng)目把按照MoSCoW排序的關(guān)注點(diǎn)分解為20個用戶場景，相當(dāng)于20個史詩故事，每個史詩故事包括2-3個用戶故事，一共是50個用戶故事。

（2）故事點(diǎn)數(shù)(Stroy Point）

項(xiàng)目需要估計(jì)預(yù)算，所以需要估計(jì)工作量，這里用到了敏捷中的故事點(diǎn)數(shù)。故事點(diǎn)數(shù)代表了開發(fā)用戶發(fā)故事所需的全部工作量，故事點(diǎn)通常用于評估交付產(chǎn)品的價值，也可以用于評估成本。

一般情況估算故事點(diǎn)是比較困難的事情，但本次項(xiàng)目比較特殊，由于只需要開發(fā)靜態(tài)頁面，所以工作量主要集中在設(shè)計(jì)和前端開發(fā)上。

團(tuán)隊(duì)很快確定了通過頁面數(shù)量確定故事點(diǎn)數(shù)的方式，也就是先估計(jì)開發(fā)頁面的數(shù)量，有個頁面數(shù)量開發(fā)量就很容易估算了。也就是：

故事點(diǎn)數(shù)=頁面數(shù)量*單個頁面的工作量（0.5天）

本項(xiàng)目中每個用戶故事分配了1個頁面，每個頁面分配了2個故事點(diǎn)，所以項(xiàng)目的規(guī)模在50個故事點(diǎn)數(shù)(相當(dāng)于25人天)。有了故事點(diǎn)數(shù)再乘上平均人工成本，就很容易估算出項(xiàng)目的費(fèi)用(主要是研發(fā)成本)。

4. 建立發(fā)布計(jì)劃

最后一步是將 Story 按照優(yōu)先級分別分配到每個 Sprint 中。有兩種發(fā)布Sprint的方式，一種是釘在墻上這樣可視化的方式讓團(tuán)隊(duì)成員每天能看見。

還有一種是Leangoo這樣的軟件發(fā)布電子版本的Sprint計(jì)劃(見用戶故事一篇)。

5. 迭代計(jì)劃

迭代計(jì)劃的目的就是確認(rèn)每個sprint階段的任務(wù)單（ticket）和優(yōu)先級。這里要引入一個敏捷里的重要實(shí)踐 – Spint 會議，整個團(tuán)隊(duì)通過舉行 Spint 會議來為下一輪 Sprint 做計(jì)劃，會議的內(nèi)容包括：

（1）討論故事

通常是對已經(jīng)排好優(yōu)先級的史詩故事和用戶故事進(jìn)行討論，以確保成員理解開發(fā)任務(wù)。

（2）從 用戶故事分解為任務(wù)單（ticket）

此步驟是將用戶故事分解為顆粒度更小的任務(wù)單(ticket），通常寫在一個人任務(wù)卡上。

（3）開發(fā)人員承擔(dān)每個任務(wù)的職責(zé)

開發(fā)人員可以在分解任務(wù)之后對任務(wù)進(jìn)行認(rèn)領(lǐng)，每個卡片都需要有一個責(zé)任人。

（4）討論所有故事，開發(fā)人員單獨(dú)估計(jì)承諾他們的任務(wù)

每個開發(fā)人員對認(rèn)領(lǐng)的任務(wù)進(jìn)行詳細(xì)估算，如果 Sprint 時間內(nèi)估算超過了開發(fā)人員所能承擔(dān)的工作量，有以下幾種選擇：請求團(tuán)隊(duì)其他成員接受一些任務(wù)；與 PO 討論，放棄其中一個 Story （或者是分解后的一部分）。

6. Sprint評審

Sprint評審的目的在于演示階段性成果，評審相關(guān)的 Backlog 中的問題，檢查是否已達(dá)到 Sprint 的目標(biāo)。Sprint評審在會議中向最終用戶展示工作成果，并獲得反饋，Sprint評審可邀請利益相關(guān)者參與。

本項(xiàng)目的Sprint評審在每一個Sprint發(fā)布后進(jìn)行，由PO主持，主要評審人為BOSS、事業(yè)部主管和銷售經(jīng)理。

7. 站立會議

站立會議是scrum中的一個重要實(shí)踐，也是筆者認(rèn)為最容易推廣和執(zhí)行的敏捷活動。會議需要敏捷小組全員參加，會上每個人輪流發(fā)言，就4個問題回答：

1. 我們上次開會后你都干了什么？
2. 每個你負(fù)責(zé)的、正在做的任務(wù)還剩下多少時間？
3. 下次開會之前你要做什么？
4. 你的工作被阻礙了嗎？

如果有人在會議上提出工作被阻礙，PO在會后要及時解決會議上提出的阻礙，發(fā)現(xiàn)并解決問題是站立會議的主要目的。

站立會議一般是封閉的，只有敏捷小組成員參加，如果非團(tuán)隊(duì)成員闖入并發(fā)言，他會背上一個不好聽的名字。

本項(xiàng)目的站立會議每天上午9點(diǎn)準(zhǔn)時進(jìn)行，效率很高，每次15分鐘就結(jié)束了。每次開會的時候總感覺有一雙眼睛在遠(yuǎn)處默默的注視著我們。

8. 回顧會議

回顧會議在每輪迭代結(jié)束后舉行的會議，目的是分享本輪迭代好的經(jīng)驗(yàn)和改進(jìn)點(diǎn)，促進(jìn)團(tuán)隊(duì)不斷進(jìn)步。一般圍繞著三個主題討論：本次迭代哪些做的最好，哪些能做的更好，下一次迭代準(zhǔn)備在哪些方面改進(jìn)。

寫在最后

本項(xiàng)目最終比預(yù)期完了三天結(jié)束，盡管還有很多不盡人意的地方，但大家都全力以赴，最終結(jié)果也得到了公司的認(rèn)可。回顧會上，大家也都表達(dá)了反思和收獲，我能看到每個人都在進(jìn)步和成長，我想這就也正是敏捷倡導(dǎo)的學(xué)習(xí)型組織的意義吧！

#相關(guān)閱讀#

B端產(chǎn)品經(jīng)理養(yǎng)成記（1）：業(yè)務(wù)場景

B端產(chǎn)品經(jīng)理養(yǎng)成記（2）：用戶故事

B端產(chǎn)品經(jīng)理養(yǎng)成記（3）：訪談

作者：濤哥，微信公眾號：濤哥筆談。前華為高級產(chǎn)品經(jīng)理，TOGAF認(rèn)證專家，PMP認(rèn)證專家，PPV課數(shù)據(jù)科學(xué)社區(qū)創(chuàng)始人，數(shù)字化轉(zhuǎn)型實(shí)踐者

本文由 @濤哥 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議