1.3 需求管理

文/章冀灶（晟遠）

我們將從需求的定義、規(guī)劃、澄清、拆分、進度管理這五個方面來介紹如何管理需求。

1.3.1 需求定義

1.什么是需求

我們經(jīng)常提到“需求”“用戶痛點”，那么到底什么才是“需求”呢？

我們可以將“需求”理解為用戶的需要，即產(chǎn)品現(xiàn)狀無法解決的用戶痛點。用戶之所以選擇一個產(chǎn)品，一定是為了解決某些痛點。接下來我們將舉例說明到底什么是需求。

示例一，淘寶直播是淘寶推出的一個導(dǎo)購產(chǎn)品。對于C端用戶來說，他們希望在看直播的同時能夠與主播互動，解決自己在收看直播的過程中對于商品所產(chǎn)生的疑問。

評論功能是與主播互動非常有效且直接的功能，用戶可以通過提問快速得到主播的回復(fù)，因此評論功能可以作為淘寶直播的一個功能需求。

示例二，小紅作為某社區(qū)App的高活用戶，粉絲數(shù)將近十萬。持續(xù)運營粉絲及商業(yè)化是KOL（Key Opinion Leader，關(guān)鍵意見領(lǐng)袖）的強訴求，那么對于社區(qū)平臺來說，應(yīng)該為KOL提供什么樣的功能呢？

自運營的功能是KOL的強訴求，例如，圈子自建、管理等能力就是KOL在自運營訴求中的基礎(chǔ)需求。

從某種程度上來說，未滿足的用戶的真實訴求、用戶的吐槽點都應(yīng)該是產(chǎn)品的需求，產(chǎn)品需求源自用戶，也服務(wù)于用戶。

2.需求結(jié)構(gòu)

需求因其層次的不同會具有不同的結(jié)構(gòu)，一般情況下，需求結(jié)構(gòu)主要分為三層，如圖1-9所示。

（1）業(yè)務(wù)場景層

業(yè)務(wù)場景層主要包含可發(fā)布、可運營的基本單元。對于明確的業(yè)務(wù)目標，業(yè)務(wù)場景可提供相對完整的業(yè)務(wù)能力，包含業(yè)務(wù)鏈路上的一個或多個產(chǎn)品功能。

（2）功能需求層

功能需求層主要包含可測試和可部署的基本單元。功能需求包含一個或多個開發(fā)任務(wù)，是用戶可以感知到的功能，服務(wù)于具體的業(yè)務(wù)場景。

（3）開發(fā)任務(wù)層

開發(fā)任務(wù)層主要包含基本的開發(fā)單元。開發(fā)任務(wù)既包括團隊的任務(wù)，也包括需要依賴其他團隊配合開發(fā)的任務(wù)。

從圖1-9上半部分可以看出，整個上層結(jié)構(gòu)都是基于產(chǎn)品規(guī)劃層面，將功能需求與業(yè)務(wù)場景對齊，快速交付業(yè)務(wù)場景，并形成業(yè)務(wù)目標的反饋閉環(huán)。當然，在某些情況下，功能需求也可以直接與迭代目標對齊，以保障迭代目標的達成，形成相應(yīng)的反饋閉環(huán)。

而圖1-9下半部分則主要是基于整個交付團隊層面，是將開發(fā)任務(wù)與功能需求對齊，以保障持續(xù)高質(zhì)量的需求交付為核心目標。

上面的描述可能比較抽象，下面我們通過一個實例來說明。

1）迭代目標。淘寶直播團隊在2020年上半年的某個迭代中希望能實現(xiàn)直播頻道留存的增長，次日留存從×××增長到×××。

2）業(yè)務(wù)場景。要想實現(xiàn)上述的迭代目標，核心的策略是用營銷活動、產(chǎn)品策略等方式留住用戶，提升用戶的活躍度。經(jīng)過業(yè)務(wù)、產(chǎn)品、開發(fā)等相關(guān)人員的協(xié)商，最終團隊決定采用簽到領(lǐng)紅包、秒殺等營銷方式來達成用戶留存的目標。在這個場景下，簽到領(lǐng)紅包、秒殺等營銷活動就屬于業(yè)務(wù)場景，在需求階段我們就應(yīng)該明確各種營銷方式，助力達成目標。

3）功能需求。這里我們以簽到領(lǐng)紅包的業(yè)務(wù)場景為例，從功能需求的維度來看，簽到領(lǐng)紅包一般可以分為簽到、紅包領(lǐng)取、紅包發(fā)放、紅包消費等功能，那么對于產(chǎn)品人員來說，應(yīng)該針對上述這些功能進行詳細的需求設(shè)計，以保障簽到領(lǐng)紅包的業(yè)務(wù)場景是可以實現(xiàn)功能閉環(huán)的。

4）開發(fā)任務(wù)。以上述的紅包領(lǐng)取業(yè)務(wù)場景為例，在淘寶天貓的場景下，該業(yè)務(wù)場景與登錄、卡券包等依賴方及內(nèi)部的一些開發(fā)任務(wù)相關(guān)，所以一般情況下，我們可以將開發(fā)任務(wù)拆解為卡券包、紅包發(fā)放接口聯(lián)調(diào)、淘寶天貓登錄接口開發(fā)及聯(lián)調(diào)等子任務(wù)。只有完成所有的開發(fā)任務(wù)及完成聯(lián)調(diào)部署之后，才算是實現(xiàn)了其中一個功能需求。

我們可以發(fā)現(xiàn)，需求包含了很多層不同的結(jié)構(gòu)。日常生活中，我們也需要拆分需求，最細的顆粒度就是開發(fā)任務(wù)，那么，如何進行有效的拆分呢？具體細節(jié)我們將在1.3.4節(jié)中展開講解。

3.需求來源

需求的來源是方方面面的。根據(jù)需求來源的不同，我們可以將需求分為內(nèi)部需求和外部需求。外部需求主要是指針對用戶研究、訪談等所產(chǎn)生的需求，內(nèi)部需求主要是指領(lǐng)導(dǎo)層的指示、業(yè)務(wù)方的需求等。

通常情況下，在淘寶天貓，我們一般會根據(jù)來源角色的不同將需求分為三類，分別是產(chǎn)品運營類需求、視覺交互類需求、技術(shù)類需求。下面我們就來分別看一下這些不同類型的需求。

（1）產(chǎn)品運營類需求

產(chǎn)品運營類需求一般由產(chǎn)品、運營人員提出，來源于產(chǎn)品的需求一般是基于整體產(chǎn)品架構(gòu)設(shè)計而產(chǎn)生的需求，而來源于運營的需求則一般都是運營人員在平臺使用、用戶調(diào)研等過程中產(chǎn)生的需求。無論是產(chǎn)品需求還是運營需求，所有的需求都應(yīng)該經(jīng)過可行性分析、優(yōu)先級定義、方案設(shè)計之后再進入到后續(xù)的評審等環(huán)節(jié)。

這里以躺平App為例進行說明。產(chǎn)品人員會定義整體產(chǎn)品的基礎(chǔ)架構(gòu)，例如，發(fā)布體系、消息體系、圈子互動體系、導(dǎo)購交易體系等，均是基于基礎(chǔ)產(chǎn)品架構(gòu)功能而定義的產(chǎn)品類需求。運營類需求與之類似，例如，社區(qū)希望刺激用戶生產(chǎn)優(yōu)質(zhì)的內(nèi)容，那么運營就會針對該目標提出相應(yīng)的營銷活動需求，然后產(chǎn)品人員將基于運營的活動需求進行可行性分析等，直至產(chǎn)出PRD（產(chǎn)品需求文檔）。

（2）視覺交互類需求

視覺交互類需求一般由UED（交互視覺設(shè)計）人員提出，主要是基于產(chǎn)品交互體驗的一致性、便捷性、友好度及視覺品牌的認知提出的需求，該類需求一般會從用戶體驗的角度出發(fā)，通過交互優(yōu)化、視覺升級等方式為用戶提供體驗更好的產(chǎn)品。

（3）技術(shù)類需求

技術(shù)類需求一般由技術(shù)、測試等相關(guān)人員提出，主要是為了構(gòu)建高可用、安全、順暢的產(chǎn)品，通常會分為安全性需求、性能需求、穩(wěn)定性需求等。安全性需求主要是為了保障用戶在產(chǎn)品體系中的信息安全、支付安全等，保障的是用戶的基本權(quán)益。性能需求則主要是為了保障用戶的使用體驗，能夠為用戶提供流暢的操作體驗，性能需求的指標一般會包括幀率、CPU等。穩(wěn)定性需求主要是為了保障產(chǎn)品在使用過程中各項功能的穩(wěn)定性，尤其是對于移動端App的使用，大家會更多地關(guān)注崩潰、卡頓等問題。

從本質(zhì)上來講，無論是什么樣的需求，或者是來源于誰的需求，首先都應(yīng)該從用戶訴求、用戶痛點出發(fā)，服務(wù)好我們自己的用戶。用戶是產(chǎn)品的核心，你所服務(wù)的群體將是未來用戶增長的核心目標群體。

1.3.2 需求規(guī)劃

1.需求目標

戰(zhàn)略目標可拆解為四層：戰(zhàn)略、戰(zhàn)役、項目集（項目組合）、項目。項目目標對于戰(zhàn)略來說是最小的單元，但對于小團隊或項目組而言，其又變成了一個核心的方向，我們需要將項目目標繼續(xù)往下拆解，以方便項目的落地，即項目/團隊目標→迭代目標→需求目標。下面我們來看一個具體的實例。

（1）項目/團隊目標

阿里巴巴躺平App的定位是好物分享推薦社區(qū)。該團隊2019年上半年的目標主要分為如下幾點：DAU達到×××，次日留存/第30日留存達到×××，互動率達到×××。

（2）迭代目標

該項目組采用雙周迭代（指從業(yè)務(wù)需求的產(chǎn)出到最終發(fā)布上線的時間為兩周）的方式來保證產(chǎn)品的持續(xù)交付。項目經(jīng)理將上半年的6個月分成了12個迭代，并且針對每一個迭代對相應(yīng)的目標進行了拆解，例如，2019年上半年第一次迭代中，DAU為×××，次日留存/第30日留存為×××，互動率為×××。

（3）需求目標

一個迭代的目標需要通過該迭代中的所有需求來實現(xiàn)，所以需求也需要有相應(yīng)的目標。例如，分享的需求，主要是用于幫助拉新回流，那么從目標的角度來衡量，我們可以將分享的需求定位在對于拉新的增長刺激。

上述的例子可以說明各層級間目標的相互依賴關(guān)系，但是部分讀者可能還會產(chǎn)生這樣一個問題，即我們已經(jīng)有了項目目標、迭代目標，為什么還要為需求設(shè)定目標呢？

我們可以清楚地看到，在項目的運轉(zhuǎn)過程中，需求是助力項目目標達成的最小單元，如果過程中我們沒有對需求目標進行設(shè)定及衡量，那么極有可能會出現(xiàn)的一種現(xiàn)象就是，我們做了一堆未經(jīng)深入思考和論證的需求，做了很多可能無法助力項目目標達成的需求，這就很容易導(dǎo)致整個項目組走彎路、偏離正道行駛。下面，我們簡單總結(jié)一下設(shè)定需求目標的好處。

? 需求目標可以更好地幫助衡量需求的實現(xiàn)與項目目標的關(guān)系，減少未經(jīng)思考論證的需求的產(chǎn)出。

? 需求評審（下文將提到）能夠根據(jù)不同的視角針對需求的目標進行討論，多維度判斷需求目標設(shè)定的合理性。

? 需求上線后有助于通過線上數(shù)據(jù)的反饋與之前設(shè)定的目標值進行對比，分析超出預(yù)期或者未達到預(yù)期的原因，為后續(xù)的持續(xù)迭代做好相應(yīng)的分析及輸入。

總而言之，前期的目標設(shè)定在項目運轉(zhuǎn)過程中起到了非常重要的作用，PM（項目經(jīng)理）應(yīng)該持續(xù)關(guān)注目標的設(shè)定、目標的合理性及上線后的數(shù)據(jù)反饋等，幫助整個項目組在需求實現(xiàn)上建立相應(yīng)的閉環(huán)，持續(xù)驅(qū)動大家朝著正確的方向前進。

2.需求優(yōu)先級定義

當需求目標明確之后，接下來就是需求分析的階段。任何一個項目組的研發(fā)、測試、設(shè)計等資源都是有限的，我們需要在有限的時間內(nèi)盡快交付需求，同時為了使ROI（投資回報率）更高，需要更早地交付優(yōu)先級高的需求。那么到底應(yīng)該如何確定需求的優(yōu)先級呢？

需求優(yōu)先級=（（企業(yè)收益-企業(yè)成本）/企業(yè)成本）×用戶獲利值×目標用戶占比

當然在很多場景下，尤其是在互聯(lián)網(wǎng)行業(yè)中，我們通常很少以上述公式分析需求的優(yōu)先級，而是借助一些工具來對優(yōu)先級進行分析和判斷，通常采用的是KANO（卡農(nóng)）模型。

KANO模型是東京理工大學教授狩野紀昭發(fā)明的用來對用戶需求進行分類和優(yōu)先級排序的有效工具，以分析用戶需求對用戶滿意度的影響為基礎(chǔ)，體現(xiàn)了產(chǎn)品滿意度和用戶滿意度之間的非線性關(guān)系（引自百度百科）。KANO模型一共包含五類影響因素，具體說明如下。

? 必備因素：滿足此基礎(chǔ)需求時，用戶才會使用產(chǎn)品。如果不提供此需求，那么用戶滿意度會大幅降低，甚至流失。比如說，社區(qū)類App沒有發(fā)布器。

? 期望因素（線性因素）：KANO模型是從線性需求模型演變而來的，線性需求在產(chǎn)品中實現(xiàn)得越多，用戶就越滿意，如果不提供此需求，那么用戶滿意度會降低。例如，社區(qū)類App中的圈子自建、圈子管理功能。

? 興奮因素：用戶意想不到的因素。不提供此需求，用戶滿意度也不會降低，但是在提供此需求后，用戶滿意度會有很大的提升。例如，短視頻App中的視頻瘦身功能。

? 無差異因素：無論是否提供此需求，用戶滿意度都不會變。

? 反向因素：用戶根本沒有此項需求，提供后用戶滿意度反而會下降。

基于KANO模型，同時結(jié)合業(yè)務(wù)目標，我們更容易得出需求的優(yōu)先級。在實操中，我們通常會對上述三類因素分配一定比例的資源投入，常規(guī)資源配比為“必備因素‥期望因素‥興奮因素=6‥3‥1”（也可視項目組具體情況而定）。

3.需求負責人機制

我們的項目管理團隊面臨的現(xiàn)狀是，對接大淘寶上千名技術(shù)開發(fā)人員的PM只有十幾個人。顯而易見，每個人的精力有限，只能關(guān)注重點的戰(zhàn)役、項目集，對于參與人數(shù)在幾百甚至上千的大型戰(zhàn)役、項目集PM無法完全深入到每一個項目的細節(jié)中，但又必須統(tǒng)籌整體的進度、風險、目標達成情況等。那么，如何才能做好統(tǒng)籌呢？

這時候就需要有一個縱向的PM梯隊，也就是說，很多技術(shù)人員將兼職PM，騰出一些精力負責其項目的交付情況、關(guān)注項目的細節(jié)等。

位于整個梯隊最底層的其實就是所謂的需求負責人。需求負責人對需求目標的實現(xiàn)負責，包含前期需求價值評估、可行性分析、需求排期、進度跟蹤、風險把控、保障穩(wěn)定發(fā)布等一系列流程。簡而言之，需求負責人就是需求的第一負責人，如圖1-10所示。

需求負責人的核心職責具體說明如下。

? 需求價值評估階段：負責人要盡可能地深入理解需求，做好價值判斷，明確需求的目標。

? 可行性評估階段：確認方案的可行性，明確上下游依賴，排除項目潛在風險。

? 項目排期階段：明確技術(shù)方案，組織技術(shù)方案評審，對項目進行排期。

? 項目開發(fā)測試階段：做好進度跟蹤，把控風險，推動解決關(guān)鍵問題，每日同步項目進展，監(jiān)控關(guān)鍵風險點。

? 項目上線階段：做好穩(wěn)定性觀察、輿情觀察，上線后跟蹤數(shù)據(jù)效果。

在實操過程中，我們將負責此需求的最主要的開發(fā)人員任命為需求負責人，由該開發(fā)人員統(tǒng)籌全局。因為該開發(fā)人員對于整個需求的實現(xiàn)、可能產(chǎn)生的風險、開發(fā)的成本預(yù)估等會更準確。

在需求落地的過程中，需求負責人一定要注意，不僅要關(guān)注需求的交付及系統(tǒng)的設(shè)計，而且還要關(guān)注需求價值、可行性評估等。很多時候我們會發(fā)現(xiàn)，風險的引入從需求階段就已經(jīng)開始了，需求的邏輯不清、價值不明導(dǎo)致了上線后未能達到預(yù)期。需求的交付僅僅是需求全生命周期中很小的一個環(huán)節(jié)，要想保障需求價值的高效交付，需求負責人更應(yīng)該關(guān)注端到端的鏈路。

4.需求計劃管理

需求計劃管理是指管理需求端到端全生命周期的計劃，即明確需求各關(guān)鍵節(jié)點的時間，例如，定義需求目標、需求/交互/視覺評審時間、開發(fā)聯(lián)調(diào)時間、提測時間、發(fā)布部署時間等。需求負責人應(yīng)按照實際、客觀的情況制定相應(yīng)的詳細計劃。在計劃的制定過程中，需要綜合考慮可能影響到時間計劃的因素。可能產(chǎn)生影響的因素包括需求優(yōu)先級、資源投入情況、工時評估、封網(wǎng)計劃等。

在制定需求計劃的過程中，為了更高效地產(chǎn)出及提升可視化，我們一般會借助工具來進行相應(yīng)計劃的制定及管理。例如，在淘寶天貓內(nèi)部，我們通常會使用Aone（阿里內(nèi)部的項目管理工具）進行計劃的制定、管理及持續(xù)跟蹤，市場上使用較多的還有研發(fā)效能工具Teambition等。當然，也可以使用一些線下的工具來制定相應(yīng)的計劃，需求負責人可根據(jù)自己的習慣來選擇。但在一個項目組中，PM應(yīng)盡量使大家通過同一種工具來進行管理，以方便對項目進行長期的管理，以及與項目組成員查看項目計劃的習慣保持一致。

甘特圖或Excel表都是用于制定計劃的輔助工具。如果在制定需求計劃時，發(fā)現(xiàn)該需求的上下游依賴特別強、依賴關(guān)系非常復(fù)雜，那么我們建議需求計劃的制定最好是采用甘特圖來進行，其余的情況借助于Excel表應(yīng)該就可以滿足需求了。圖1-11為Excel計劃圖。

從圖1-11中我們可以發(fā)現(xiàn)，需求計劃必須要包含一些元素，如需求描述、需求優(yōu)先級、PM（即需求負責人）、開發(fā)人員等。下面分別解釋一下各元素的定義。

? 需求描述：明確展示該需求，方便所有項目成員對需求情況一目了然。

? 需求優(yōu)先級：通過卡農(nóng)模型等方式明確需求的優(yōu)先級，并將其標注到需求計劃表中。

? 需求負責人：提前定義好所有需求的負責人，負責該需求端到端的交付。

? 開發(fā)人員：列出該需求涉及的所有相關(guān)開發(fā)人員，只要是有依賴關(guān)系的人都應(yīng)該列出來。

? 工期：評估實現(xiàn)需求各依賴模塊所需要的工時。

? 聯(lián)調(diào)、提測等時間：明確定義好涉及開發(fā)的各端的聯(lián)調(diào)、提測的時間點，包括測試介入、測試發(fā)布等時間點。

在需求計劃的制定過程中，我們應(yīng)該優(yōu)先關(guān)注高價值、高優(yōu)先級需求的排期，將核心的資源重點部署在該類需求上。

這里需要強調(diào)的一點是，對于涉及橫向依賴的需求，PM一定要梳理好彼此之間的依賴關(guān)系，上下游的交付節(jié)點至關(guān)重要，因為一旦出現(xiàn)依賴關(guān)系梳理不清、交付節(jié)點不明確的情況，就極有可能會出現(xiàn)最終交付延遲的問題。

項目計劃得到最終確認之后，PM應(yīng)第一時間同步給項目組成員，讓所有項目相關(guān)方確認排期的合理性，如有異議再線下重新對焦，直至確認最終的排期計劃。

1.3.3 需求澄清

需求的澄清通常通過撰寫PRD或舉辦評審活動。

1. PRD

PRD（Product Requirements Document，產(chǎn)品需求文檔）一般由產(chǎn)品經(jīng)理根據(jù)需求撰寫，是需求進入交付環(huán)節(jié)之前非常重要的產(chǎn)物，也是產(chǎn)品經(jīng)理將業(yè)務(wù)需求、用戶需求翻譯成產(chǎn)品語言的產(chǎn)物。PRD的作用具體如下。

? 降低項目成員溝通成本：項目成員可以通過文檔理解和查看邏輯問題，而無須線下找產(chǎn)品經(jīng)理確認。

? 梳理邏輯，避免遺漏：PRD會梳理所有的產(chǎn)品邏輯。

? 信息存檔：方便后來的產(chǎn)品經(jīng)理對于過往需求有更全面的了解，同時也可以作為團隊沉淀的資產(chǎn)。PRD可以算作對產(chǎn)品的注釋。

但是實際上，每個產(chǎn)品經(jīng)理都有自己的風格，所寫的PRD也千差萬別。為了更好地統(tǒng)一大家的認知、提升其他成員的瀏覽效率，應(yīng)該針對需求模板對PRD進行相應(yīng)的統(tǒng)一。淘寶天貓常見的需求模板包括如下幾個方面。

? 需求背景：填寫需求來源、需要解決的問題和達成的目標等，用于描述需求的重要性等。

? 需求方案：填寫需求的詳細邏輯，業(yè)務(wù)流程（正常還是異常）和業(yè)務(wù)規(guī)則等。

? 需求驗收標準：填寫需求的詳細邏輯和內(nèi)容，數(shù)據(jù)類需求需要增加明確的指標定義。

? 依賴方：填寫需求所要依賴的業(yè)務(wù)和模塊。

? 數(shù)據(jù)埋點：確認數(shù)據(jù)埋點的需求，以方便后續(xù)進行數(shù)據(jù)分析。

利用上述統(tǒng)一的需求模板，一方面可以統(tǒng)一大家的PRD格式，另一方面也會督促PM在寫PRD之前考慮清楚需求的價值和目標，這在一定程度上可以避免一些沒有經(jīng)過深入思考和論證的需求直接進入開發(fā)過程，從而導(dǎo)致開發(fā)資源的浪費。

2.評審活動

（1）需求評審的意義

需求評審是產(chǎn)品經(jīng)理闡述需求設(shè)計思路的重點環(huán)節(jié)，也是從需求設(shè)想到開發(fā)階段的必經(jīng)之路。需求評審一般扮演著非常重要的承上啟下的作用，需要在需求評審會上讓各參與方都明白產(chǎn)品的設(shè)計思路、產(chǎn)品價值、背景、目標及可能需要的依賴。如果評審會上還有不明確的點，那么在會后還需要繼續(xù)討論，直至明確敲定所有的細節(jié)。下面簡單總結(jié)一下需求評審的幾個目的。

? 明確業(yè)務(wù)和產(chǎn)品價值。需求是為提高用戶體驗、解決用戶痛點等服務(wù)的，那么我們做需求也要明確其最終實現(xiàn)的業(yè)務(wù)或產(chǎn)品價值到底是什么，需要通過需求評審會議做一次全方位的傳達。

? 達成一致意見。現(xiàn)實中一個需求的實現(xiàn)往往需要項目組各端成員的協(xié)同，那么拉齊大家對于需求理解的一致性是非常有必要的，同時也能了解大家對于需求的疑問以及讓成員明晰所要面臨的挑戰(zhàn)。

? 明確最終需求。評審會的各參與方可以從不同的角度思辨需求的真?zhèn)巍⑼晟贫燃昂侠硇裕瑥亩Ｕ献罱K得出的是真正的需求。

（2）需求評審的參與人

需求評審會需要所有決定需求實現(xiàn)的相關(guān)人員都參加，包括業(yè)務(wù)方、產(chǎn)品經(jīng)理、UED（交互視覺設(shè)計師）、項目經(jīng)理、開發(fā)人員、測試人員、相關(guān)依賴方等，只要是會影響到需求按時上線的相關(guān)人員都需要參加。

? 業(yè)務(wù)方：運營人員往往也會提出一些需求，需要產(chǎn)品經(jīng)理翻譯為產(chǎn)品預(yù)演并結(jié)合整體的產(chǎn)品設(shè)計給出合理的解決方案。

? UED：產(chǎn)品人員一般會在需求評審會之前就準備好產(chǎn)品的原型，UED需要實現(xiàn)整體的交互流程、頁面展現(xiàn)等，并最終向開發(fā)人員提供交互稿或視覺稿。

? PM：如果項目組有專門的項目管理人員，那么一定要參與評審，幫助落地整體需求。

? 開發(fā)人員：包括客戶端、前端、服務(wù)端等所有與需求實現(xiàn)相關(guān)的開發(fā)人員都需要參與，同時建議技術(shù)總監(jiān)一同參與需求評審會。

? 測試人員：測試是對需求質(zhì)量進行把控的重要一環(huán)，因此測試人員必須參與需求評審會。

? 依賴方：如果該需求的實現(xiàn)需要依賴其他團隊的上下游鏈路，那么依賴方的產(chǎn)品人員和開發(fā)人員也要參加需求評審會。

（3）需求評審流程

需求評審的流程一般分為三個階段，分別是評審前、評審中、評審后，如圖1-12所示。在各個評審階段，我們都要提前做一些準備工作。

1）評審前。準備好需求之后，產(chǎn)品經(jīng)理或項目經(jīng)理應(yīng)至少提前2～3天向參與方發(fā)送需求評審會議，明確評審會議的時間、地點，同時附上PRD，讓參與方能夠提前了解需求細節(jié)。

2）評審中。需求評審會上，主要由產(chǎn)品經(jīng)理講解需求的背景和價值、功能模塊及整體的優(yōu)先級，同時如果提前準備好了交互流程，那么交互視覺設(shè)計師也可以在會上講解交互流程。評審會上參與方應(yīng)對所有不明確、依賴邊界情況、技術(shù)實現(xiàn)困難點等問題提出自己的疑義，盡量在會議中明確敲定各個問題，如需進行線下討論，那么產(chǎn)品人員應(yīng)與所有相關(guān)方將存在疑義的問題點全部討論清楚。為了保證需求評審會的高效，需要特別注意如下列舉事項。

? 評審過程中要確保PRD與交互稿保持一致。

? 產(chǎn)品經(jīng)理或項目經(jīng)理一定要控制好整體會議的流程及進度，避免大家在討論的過程中跑題，組織者應(yīng)盡量控制會議的效率及討論的方向。

? 如果會議中出現(xiàn)大的歧義或疑義點，應(yīng)記錄下來，在會后進行小范圍討論，評審會上先明確敲定大家一致認同的需求點。

? 切忌在會上討論技術(shù)方案，技術(shù)方案應(yīng)通過單獨的會議進行對焦，評審會上開發(fā)人員可以根據(jù)自己的經(jīng)驗提供一些建議和反饋，但不要展開對細節(jié)的討論。

3）評審后。評審會議結(jié)束后，如果會上所有的邏輯都已明確，那么產(chǎn)品經(jīng)理應(yīng)將最終版本的PRD明確后，提交給項目組的相關(guān)人員，同時設(shè)計師開始介入進行UI設(shè)計，開發(fā)人員設(shè)計技術(shù)方案并評估工作量。

如果會議中還存在有待明確的點，那么會后產(chǎn)品經(jīng)理或項目經(jīng)理應(yīng)連同相關(guān)人員明確敲定這些有疑問的點，并且在得出明確結(jié)論后，及時同步給所有的相關(guān)人員，建議通過當面溝通、郵件、群溝通等各種形式同步最終結(jié)論，以防部分人員因信息不齊而導(dǎo)致需求遺留，或者造成開發(fā)資源的浪費。

1.3.4 需求拆分

軟件開發(fā)過程中，需要回答兩個最本質(zhì)的問題，即做什么和怎么做。在這兩個問題中，做什么無疑是最重要的。然而，軟件開發(fā)中普遍面臨需求不夠清晰或者需求過大的問題，這些都成為限制軟件持續(xù)交付的主要原因。那么，是否有一種實用的方法實踐，能夠快速地完成需求分析，理清需求背后的問題，并使需求得到合理的拆分呢？

1.需求拆分的原因

（1）需求的拆分方式直接決定了研發(fā)的模式

在傳統(tǒng)軟件交付過程中，一個大的需求不會在問題域拆分，而是由架構(gòu)師主導(dǎo)在實現(xiàn)域從實現(xiàn)的角度按模塊拆分，再由不同模塊的開發(fā)人員負責具體模塊的開發(fā)工作。這種拆分方式下，只有當所有的模塊全部開發(fā)完成之后，才能進行一次批量的集成測試。這就是傳統(tǒng)意義上的瀑布模式。在這樣的交付方式中，開發(fā)團隊與業(yè)務(wù)方缺少有效的互動。對開發(fā)團隊而言，產(chǎn)品交付只是完成手頭上的一件工作，交付團隊無法在業(yè)務(wù)上建立真正的心智連接。

如果需求是在問題域進行拆分，即將一個大的問題（需求）拆解成若干個小問題（需求），那么每一個小的需求便可以獨立交付給開發(fā)團隊進行開發(fā)，因為需求相對較小，各開發(fā)職能人員很容易協(xié)作并完成需求的實現(xiàn)，同時因為拆出來的每個子需求都是獨立可交付的，這樣就實現(xiàn)了持續(xù)交付。

兩種需求拆分方式的對比見圖1-13。

所以，需求的拆分方式直接決定了團隊的研發(fā)模式，而研發(fā)模式又直接決定了交付的效率。

（2）過大的需求會隱藏細節(jié)，而問題就在細節(jié)里

細節(jié)是魔鬼。軟件開發(fā)中隱藏的細節(jié)，足夠摧毀一切看似有序的計劃。當用戶故事只停留在宏觀層面討論時，需求看起來往往是很清楚的，或者雖然覺得有哪里不清楚，但是卻說不出具體問題。如“支持二手商品交易中提供貨物擔保”，這個看似簡單的需求，實則背后隱藏著大量的細節(jié)。

? 需要提供什么樣的擔保服務(wù)？

? 誰可以提供擔保服務(wù)？服務(wù)商的資質(zhì)需要審核嗎？

? 哪種品類的商品可以提供擔保服務(wù)？

? 非標品如何提供擔保服務(wù)？

? 擔保服務(wù)的服務(wù)費用如何結(jié)算？

? ……

如果細節(jié)沒有得到澄清，就會為軟件交付帶來問題和風險。那么，既然需求拆分如此重要，為什么又很難做好呢？需求拆分的本質(zhì)究竟是什么？

2.需求拆分所面臨的挑戰(zhàn)

并不是大家不知道需求拆分很重要而不做需求拆分，而是因為要想做好需求拆分非常困難，因為需求拆分必須符合以下幾項原則。

? 足夠小：只有足夠小才能保證足夠的靈活性，選擇價值高的部分先交付，并保證在迭代內(nèi)交付，以做到持續(xù)交付。

? 端到端：只有端到端地進行交付，才能保證所交付的價值是有意義的。

? 獨立性：獨立性有助于集成，以及靈活安排開發(fā)實踐。

? 完整性：拆分完之后，我們需要能夠看到整體的結(jié)構(gòu)。需求在拆分完之后，應(yīng)該還是一個需求，這就意味著它能獨立測試，實現(xiàn)一個獨立的功能。

沒做需求拆分并不是因為沒有足夠的技巧來對需求進行拆分，而是因為缺少足夠多的信息，也就是本身對需求的闡述不清楚，比如沒有明確清晰的目標、沒有具體的用戶操作流程及步驟、沒有明確定義的業(yè)務(wù)規(guī)則……需求除了是產(chǎn)品交付的單元，還是溝通的載體，需求的拆分過程實質(zhì)上就是需求溝通的過程。

需求拆分如此重要，卻又如此難，那么，我們應(yīng)該如何處理呢？

3.如何做好需求拆分

要想做好需求拆分，首先需要了解需求的信息組織結(jié)構(gòu)。芭芭拉·明托（Barbara Minto）在《金字塔原理》一書里提到過，任何信息的組織，都應(yīng)該是結(jié)構(gòu)化的。需求的信息組織呈現(xiàn)的是金字塔結(jié)構(gòu)，金字塔的最頂端是需求的目標，中間為用戶操作流程，底部為基本業(yè)務(wù)規(guī)則，可以達到以上統(tǒng)下、歸類分組的效果。三個層次，自頂向下，逐漸明晰，如圖1-14所示。

需求分析的澄清過程，本質(zhì)上是收集和梳理需求信息的過程，即回答目標是什么、支持這個目標的操作流程有哪些、每個操作流程中又有什么樣的業(yè)務(wù)規(guī)則等問題的過程。

4.實施步驟

下面我們試著通過一個實際的例子來講解需求拆分的實施步驟。首先來看具體的需求及其細節(jié)。

躺平App引流需求

項目背景：計劃通過發(fā)放紅包的方式從站外引流，提升躺平App的DAU。

項目目標：拉新用戶×××，目標用戶為×××，促進躺平App DAU增長×××。

項目方案：引流入口的曝光和營銷邏輯由導(dǎo)流端實現(xiàn)，用戶觸發(fā)后會記錄用戶信息和引流商品信息，嘗試拉起躺平App客戶端或者引導(dǎo)至下載頁；此方案為躺平App被拉起后，或者通過用戶自主下載安裝并打開后的承接。

需求細節(jié)

1）領(lǐng)取紅包的觸發(fā)條件：導(dǎo)流端拉起App時，會彈出紅包領(lǐng)取卡片窗口，紅包卡片彈出時間為用戶登錄后，具體如下。用戶自行下載App、打開后主動登錄，經(jīng)校驗如果是符合紅包領(lǐng)取條件的用戶，就彈出紅包領(lǐng)取卡片。如果用戶不符合領(lǐng)取條件（比如已經(jīng)領(lǐng)取過），不會再彈出紅包領(lǐng)取卡片窗口。

2）拆紅包：用戶在登錄狀態(tài)下點擊領(lǐng)取，即完成拆紅包的動作。

3）如用戶未領(lǐng)取紅包而是主動關(guān)閉紅包領(lǐng)取卡片，或者用戶通過導(dǎo)流端二次觸發(fā)打開App，都不再彈出紅包領(lǐng)取卡片窗口。

4）領(lǐng)取后展示領(lǐng)取結(jié)果頁面，可能存在“領(lǐng)取成功”“不符合領(lǐng)取條件”“已領(lǐng)取過”“已領(lǐng)完”幾種狀態(tài)，具體詳情請見交互稿。

5）領(lǐng)取紅包調(diào)用資金平臺的紅包發(fā)放接口。

6）成功領(lǐng)取紅包頁面，點擊“去查看”前往紅包卡券頁，點擊“去使用”前往購買引流商品詳情頁。

7）紅包卡券頁中，本次需求使用卡券包的H5頁面。

實施步驟如下。

（1）澄清目標，明晰場景

從上述躺平App引流需求案例中，我們可以明確的一點是，該需求的核心目標是為了拉新。考慮到數(shù)據(jù)保密的原因，此處沒有直接透露該拉新需求的核心目標，在實際操作過程中，我們需要在需求提出的時候就明確本次需求的數(shù)據(jù)化目標，即該需求需要實現(xiàn)的拉新DAU等一系列數(shù)據(jù)化目標。

很多項目組在落地需求的過程中經(jīng)常會偏離方向，實現(xiàn)一堆沒有價值、并非項目真正目標的需求，但并沒有做出一個好的產(chǎn)品，無法滿足用戶需求。

當然，如果不了解真正的目標，沒有目標驅(qū)動，會難以保證產(chǎn)出的效果，因為自己都搞不清楚為何而做、將去向何方。當接到一個需求時，我們要問的第一個問題就是，這個需求的目標是什么。即第一步就應(yīng)該澄清以下幾個問題。

? 目標用戶是誰？

? 需求需要解決什么問題？

? 現(xiàn)存的解決方案是什么？

以下目標都是錯誤的，也比較常見。

? 籠統(tǒng)的目標。如“為了獲得GMV 1000萬”這樣不具體的業(yè)務(wù)目標，或者是“為了讓用戶用得爽”這樣無法度量的用戶目標。

? 編造的目標。不清楚目標是什么，于是從需求功能倒推進行猜測。可能是為了什么？猜測是為了什么？

如果很難搞清楚目標，那么可以試試這樣一個小竅門，就是向小朋友學習，不斷地提出問題，如下所示。

? 為什么×××？為什么×××？為什么×××？

? 不做這個需求會怎么樣？

澄清需求的目標，同時也是對需求的目標進行拆分的過程，一個大的需求目標，可以拆分成多個子目標。目標的拆分，也是對需求的拆分。

有了明確的目標，我們需要知道基于該目標的用戶場景有哪些。用例可以幫助我們描述用戶場景。

與此同時，還需要通過系統(tǒng)上下文，明確需求的各參與方。系統(tǒng)上下文會將需求的各參與方（用戶或系統(tǒng)）列舉出來，并將它們之間的關(guān)系用相對簡單的模型進行呈現(xiàn)，對業(yè)務(wù)團隊而言，這個系統(tǒng)上下文，就是業(yè)務(wù)上下文，開發(fā)團隊也非常容易與具體的實現(xiàn)模型相關(guān)聯(lián)。

系統(tǒng)上下文只需要列出簡單的模型即可，而不需要是一個完整的精確模型，模型的演進細化是逐步的。從上面列舉的躺平App引流需求的表述中，我們可以簡單列出如圖1-15所示的對象模型。

接著我們再從目標出發(fā)，列出相應(yīng)用戶的使用場景（即用例），這樣對用戶場景也做了分解（如圖1-16所示）。用戶只關(guān)心系統(tǒng)所能提供的服務(wù)，即開發(fā)出來的系統(tǒng)如何使用，并不關(guān)心系統(tǒng)內(nèi)部的結(jié)構(gòu)和設(shè)計，這就是用例的基本思路。在這個階段，我們也只關(guān)心這個層次。

（2）用戶操作，理清流程

列出具體的用戶使用場景，由多個場景一起完成某個業(yè)務(wù)目標，這樣的需求分析依然沒有結(jié)束。接下來我們再就某個用戶的使用場景做更深入的分析。例如，如何實現(xiàn)這樣的場景？用戶會進行哪些操作？操作如何與系統(tǒng)進行交互？系統(tǒng)與其他外部系統(tǒng)是否也有交互？它們之間的交互過程又是怎樣的？順著這些問題深入到具體的細節(jié)，每個用例都可以產(chǎn)生相應(yīng)的用戶操作流程及系統(tǒng)交互過程，如圖1-17所示。

隨著信息的逐層細化，我們又會有新的發(fā)現(xiàn)，例如，在該用戶交互工作流中，會引入新的參與者、新的對象，我們可以基于之前的系統(tǒng)上下文進行更深入的細化，打開更多的細節(jié)，從而形成新的領(lǐng)域模型，并逐漸演進。

下面就來說明一下這個階段常見的兩個誤區(qū)，希望能夠引起大家注意。

1）在做交互圖或?qū)ο竽Ｐ蜁r，不是從業(yè)務(wù)操作和業(yè)務(wù)領(lǐng)域?qū)ο蟮囊暯沁M行描述，而是直接進入實現(xiàn)的細節(jié)。這個誤區(qū)在技術(shù)開發(fā)團隊中很常見。而且我們在這里用到的圖表，很可能會被技術(shù)人員理解為技術(shù)時序圖。圖1-18中結(jié)合了用戶的交互路徑圖及技術(shù)時序圖，是為了方便大家理解，在實際操作中用戶的交互路徑圖和技術(shù)時序圖是解耦的，路徑圖在前，技術(shù)時序圖在后。

2）追求完美，擔心出錯。在構(gòu)建用戶操作過程和領(lǐng)域模型的過程中，追求完美會使得我們遲遲不敢有所動作。其實大可不必，有比沒有好。先打一個草稿，然后基于草稿，不斷討論和演進，這才是正確的分析過程。

（3）列出規(guī)則，逐步細化

完成以上兩個步驟之后，流程的主要操作步驟、交互過程就都梳理出來了，這個時候，就需要進一步明確業(yè)務(wù)規(guī)則。例如，用戶領(lǐng)取紅包的規(guī)則、發(fā)放紅包金額的計算規(guī)則、個性化商品推薦規(guī)則，等等。將規(guī)則列舉出來之后，我們需要對規(guī)則做一個更具體的描述。例如，領(lǐng)取紅包的規(guī)則為需要符合淘寶天貓用戶人群畫像，紅包發(fā)放規(guī)則為××用戶的金額為5元紅包、××用戶的金額為10元紅包，等等。

這個階段常見的兩個誤區(qū)如下。

1）業(yè)務(wù)規(guī)則定義過于復(fù)雜，難以列舉窮盡。例如，“小于10的數(shù)”，這種定義方式就無法列舉窮盡。具體的表述應(yīng)該是“0到9的整數(shù)”。舉例的方式可以幫助我們走出這樣的誤區(qū)。

2）另一個誤區(qū)，則是完全窮舉。有的規(guī)則組合非常復(fù)雜，很難窮舉，這個時候，我們應(yīng)該看看在操作步驟上是否可以進行再拆分。比如，一個四個變量的規(guī)則組合，可以拆分成串聯(lián)的兩個變量的規(guī)則組合。

綜上所述，我們可以發(fā)現(xiàn)，需求的拆分過程是從目標出發(fā)，到相應(yīng)的業(yè)務(wù)場景，再到具體的用戶操作和系統(tǒng)交互，最后落實到交互過程中的業(yè)務(wù)規(guī)則并進行逐層分解。從目標獲取需求的范圍，操作交互過程獲得需求說明，而規(guī)則是對需求說明業(yè)務(wù)規(guī)則的提煉，在以上實踐中，我們分別獲取了基本上下文、用例圖、工作流圖及業(yè)務(wù)規(guī)則。需求拆解金字塔圖示見圖1-18。

（4）總結(jié)：由外而內(nèi)，動靜結(jié)合的需求拆分方法

以上分析過程，是一個由外而內(nèi)、逐步分解的過程，從用例到用戶的操作流程，由上下文到領(lǐng)域模型，是一個逐步打開細節(jié)的過程。用戶的操作流程代表場景，是一個動態(tài)的過程，而領(lǐng)域模型作為可視化的術(shù)語表，是一個靜態(tài)的模型，場景結(jié)合模型，可以達到動靜結(jié)合的效果。

這里還有兩點建議，具體如下。

1）信息可視化。字不如表，表不如圖。溝通過程中，文字的還原度是很差的。圖表的溝通方式具有如下優(yōu)勢。

? 可以快速理清內(nèi)在邏輯，找到不足之處或矛盾之處。

? 可以通過少量必需要素傳達大量信息。

? 可以將復(fù)雜關(guān)聯(lián)性可視化。

圖表的繪制過程就是一次需求分析過程。

2）分析協(xié)作化。所謂一人計短，二人計長，一個人或單一職能的思考難免會存在局限。在軟件開發(fā)中，需求評審的過程需要多個角色共同參與進來。業(yè)務(wù)角色可以提供業(yè)務(wù)目標、業(yè)務(wù)場景和視覺交互，開發(fā)角色可以確認需求的影響范圍以及實現(xiàn)的可行性，而測試角色則可以站在用戶操作和系統(tǒng)行為的視角提供更多的輸入，所以，需求分析拆分是團隊協(xié)作的過程。

1.3.5 需求進度管理

拆解完需求任務(wù)及確認完詳細的計劃之后，接下來就要進入開發(fā)、測試等環(huán)節(jié)。在前期制定出一個合理的項目計劃，只是為項目進度的科學管理提供一個可靠的前提，并不等于項目進度不存在問題。在項目的實施過程中，外部環(huán)境和條件的變化往往會造成實際進度與計劃進度發(fā)生偏差。如果不能及時發(fā)現(xiàn)這些偏差并加以糾正，那么項目進度管理目標的實現(xiàn)就一定會受到影響。所以，必須實行項目進度計劃控制。

很多公司一般都會用相應(yīng)的項目管理工具來做項目的全流程管控，因此進度控制是項目管理工具一定要具備的功能。通常情況下，項目組會借助于電子看板來管理需求進度，同時還會配合一些類似于風險管理等之類的功能。下面詳細介紹常見的站會機制和看板實踐。

1.站會機制

站會，相信熟悉互聯(lián)網(wǎng)行業(yè)項目運作方式的人都耳熟能詳。該詞經(jīng)常出現(xiàn)于敏捷項目管理相關(guān)書籍中，描述上雖然各有差異，但是它是項目運作不可或缺的重要一環(huán)。

站會最大的意義在于，基于面對面溝通的前提，將項目相關(guān)人員聚集到一起，快速、高效地對焦項目的進展和風險。站會對于信息同步、問題暴露及進度的把控都具有非常重要的影響。為了更高效地實現(xiàn)站會的意義，站會的組織形式及開展流程等會采取一些套路。下面就結(jié)合筆者項目管理過程中的經(jīng)驗，以每日晨會為例來說明。

（1）明確站會議程

站會主要是評審前一天項目的進展，同步今日的計劃。在同步進展的同時，需要重點同步項目是否存在風險等問題，任何可能影響到需求延遲交付的風險均應(yīng)及時進行同步。PM一定要及時記錄問題點，但不是在會上展開討論，而是于會后找相關(guān)人員進行線下對焦。如果是需要項目組相關(guān)人員支持的點，也應(yīng)該在站會中及時提出以獲取支持，以便彼此之間更好地配合。

（2）固定時間

開站會的時間一般是在一天工作的開始時或者結(jié)束時。比如，每天的上班時間或者是吃晚飯前的時間，在這兩個時間點開站會，效率一般都會比較高。同時固定開站會的時長。站會的持續(xù)時間應(yīng)盡量控制在15分鐘之內(nèi)，時間過長容易導(dǎo)致大家分神，同時會議的效率也不高，但核心還是要將該明確的事情明確。

（3）適當鼓勵

尤其是在團隊整體氛圍比較緊張、士氣低落的情況下，PM應(yīng)借助于站會的場子鼓舞一下士氣，同時提升項目組的氛圍，讓項目組成員在更為輕松的氛圍下工作。

2.看板實踐

在敏捷Scrum團隊中，看板的使用非常頻繁，可以說整個團隊與看板形影不離。

從價值層面來說，看板主要是保障價值交付、提升可視化及保障過程透明。相信在Scrum模型下工作的大多數(shù)團隊都會有一個典型的Sprint BACKLOG（迭代待辦事項），上面列著TODO、DOING、DONE，如圖1-19所示。

BACKLOG的問題是上面只有任務(wù)，任務(wù)除了表示誰在做什么之外，是無法提供更多信息的，那就會帶來如下幾個問題。

1）純粹的交付任務(wù)無法直接體現(xiàn)價值。上文中曾提到過，需求是交付價值的最小單元，而需求又會包含一個或多個開發(fā)任務(wù)，因此如果在看板中僅體現(xiàn)開發(fā)任務(wù)是無法明確業(yè)務(wù)價值的。我們應(yīng)該多關(guān)注需求而不是任務(wù)。

2）任務(wù)之間的耦合等待，會導(dǎo)致交付效率低下。各個角色應(yīng)該跳出自己的任務(wù)視角，多關(guān)注需求，通過需求交付來對齊任務(wù)之間的耦合關(guān)系，從而有效地減少任務(wù)之間的等待時間。這樣的改變可以讓我們關(guān)注真正的價值，即產(chǎn)品需求，而不是任務(wù)。但是，需求的交付需要經(jīng)過從產(chǎn)品設(shè)計、開發(fā)到測試的完整過程，需求項目真正進行到了哪里、是否有阻塞、上下游應(yīng)該在哪個時間點對齊等問題依然存在。

要想解決問題，首先得看見問題，否則需求交付各階段的各個職能之間就像是盲人摸象一樣，這時候我們需要能夠看到需求的全貌。

全局看板可以打通各職能之間的協(xié)作，用每張卡片代表一個需求，將從“選擇”到“發(fā)布”的幾個階段串起來，清楚展示需求端到端的交付過程。這就像一幅作戰(zhàn)地圖一樣（如圖1-20所示），讓整個需求交付團隊有了一個整體的視角。我們可以看到需求項目進行到了哪里，出現(xiàn)了什么問題，是什么原因?qū)е滦枨笞枞磺埃鹊取?/p>

解釋一下圖1-20中的看板。

1）從“已選擇”到“已發(fā)布”是一個需求的完整生命周期，從“開發(fā)中”到“已發(fā)布”屬于需求的交付周期。

2）已選擇：由業(yè)務(wù)方和開發(fā)團隊代表共同完成，明確要解決的問題和達到的目標之后，通過需求分析按優(yōu)先級將需求放入該隊列。

3）就緒待開發(fā)：開發(fā)、測試和產(chǎn)品共同澄清需求，并明確定義交互過程和澄清標準。

4）待測試：對于所有移交測試的需求，開發(fā)人員對照冒煙用例驗收標準進行自測并通過Show Case演示環(huán)節(jié)。

5）已發(fā)布：按照業(yè)務(wù)規(guī)劃和版本計劃上線。

接下來，我們用一個實例來說明如何通過看板模板來提升可視化。圖1-21所示是我司某團隊的實物看板。

看板的中的深色卡片代表需求，對應(yīng)于可交付的用戶價值。需求在看板上從左至右流動，經(jīng)過看板上的每個階段，直至交付。從最左的“選擇”列決定做一個需求開始，直到上線結(jié)束。這是一個端到端的過程，拉通了產(chǎn)品、開發(fā)、測試、運維等各個環(huán)節(jié)。

在“開發(fā)中”這個階段，需求被分解成了各項任務(wù)，圖中淺色便簽紙條即代表任務(wù)。任務(wù)與其所屬的需求處于同一行，我們稱之為泳道。泳道的首列（深色卡片）是需求，下屬任務(wù)（淺色便簽）按模塊不同放在各自的列內(nèi)，如前端、后端、依賴等。運行過程中，同一需求下屬的任務(wù)應(yīng)盡量對齊進度，快速完成需求。所屬的任務(wù)全部完成后，需求進入待測試階段，泳道清空，下一個需求就可以進入了。

以端到端的價值流動過程為基礎(chǔ)，團隊能夠即時看到問題，例如，需求是否順暢流動，在哪里發(fā)生了停滯和積壓，是否存在瓶頸等。

在這個案例中，我們可以看到，有效的可視化需要做到如下四點。

? 用戶價值驅(qū)動：需求反映用戶價值，是流動的主線索。

? 前后職能拉通：以端到端的需求交付為線索，連接各個職能和環(huán)節(jié)。

? 左右模塊對齊：保證任務(wù)向需求對齊，以快速交付需求。

? 即時暴露問題。

其中，第四點是前三點的結(jié)果，它們共同作用，提升了整體項目交付過程的可視化。看板就像一面鏡子，讓我們看到需求在流動過程中的狀態(tài)、問題和瓶頸，從而打造持續(xù)快速的交付價值，奠定持續(xù)改進的基礎(chǔ)。