敏捷產(chǎn)品畫布實用指南

本杰明·富蘭克林（Benjamin Franklin）曾說過：“沒有準(zhǔn)備的人注定會失敗?！边@句話在今天仍然非常有道理。

大多數(shù)人都熟悉Scrum與西門子低代碼平臺的組合，大家應(yīng)該也知道Scrum對產(chǎn)品準(zhǔn)備階段的指導(dǎo)起不了作用。但在敏捷開發(fā)中，良好的準(zhǔn)備仍然是成功的關(guān)鍵。

西門子低代碼在產(chǎn)品愿景和產(chǎn)品畫布方法論方面的豐富經(jīng)驗，可以為項目和第一次迭代做更好的準(zhǔn)備。下面就讓我們來深入了解產(chǎn)品畫布以及使用方法吧！

什么是產(chǎn)品畫布？

在開始研發(fā)任何新產(chǎn)品之前，需要了解該產(chǎn)品的用途、受眾和目標(biāo)，這是產(chǎn)品畫布的意義所在。

產(chǎn)品畫布是一種結(jié)合敏捷方法和用戶體驗原則的規(guī)劃工具，能夠幫助團隊構(gòu)建提供良好用戶體驗的產(chǎn)品。產(chǎn)品畫布的創(chuàng)造者Roman Pichler將其描述為“一個簡單而強大的工具，能夠幫助用戶創(chuàng)建具有良好用戶體驗和強大功能的產(chǎn)品。它結(jié)合了敏捷開發(fā)和用戶體驗設(shè)計，用角色、腳本、場景、設(shè)計草圖和其他用戶體驗縮影來補充用戶故事?！?/p>

如何根據(jù)產(chǎn)品愿景和產(chǎn)品畫布來應(yīng)對變更

人們對敏捷方法存有一個常見誤解，認(rèn)為每一次迭代的結(jié)果和反饋都會有效地自主引導(dǎo)流程推進，并不需要準(zhǔn)備工作或書面文檔。而事實絕非如此。敏捷宣言（Agile Manifesto）中的正確定義是“與其謹(jǐn)遵計劃，不如應(yīng)對變化”。也就是說應(yīng)該有一個易于調(diào)整的計劃，以便能夠做好充分的準(zhǔn)備。

這里的“充分”指的是：

●   為提供業(yè)務(wù)價值做好準(zhǔn)備

●   為項目制定一個清晰的愿景

●   做好準(zhǔn)確預(yù)測的足夠準(zhǔn)備

●   有充分的細(xì)節(jié)來啟動第一次迭代

任何超出這個范圍的準(zhǔn)備都是過度準(zhǔn)備。請記住，我們正在努力創(chuàng)建一個易于調(diào)整的“計劃”。計劃越大、越詳細(xì)，就越僵化、越難改變。

雖然西門子低代碼提倡產(chǎn)品愿景和產(chǎn)品畫布，但這不是唯一的方法。即便您希望采取“零迭代”等其他方法，這篇文章也有很大的價值，它包含了為項目做準(zhǔn)備時需要解決的各類問題。

產(chǎn)品愿景板簡介

第一步是使用產(chǎn)品愿景板為項目創(chuàng)建一個高水平的愿景。

產(chǎn)品愿景板示例

產(chǎn)品愿景板需要解答以下基礎(chǔ)問題：

●   我們?yōu)槭裁匆獎?chuàng)建該應(yīng)用？

●   誰是我們的目標(biāo)用戶群？

●   目標(biāo)用戶群的需求是什么？

●   我們?nèi)绾卧O(shè)想出能夠滿足這些需求的產(chǎn)品？

●  我們這樣做是為了滿足哪些業(yè)務(wù)目標(biāo)？

產(chǎn)品愿景板也是產(chǎn)品畫布的信息來源。這兩個部分都由產(chǎn)品負(fù)責(zé)人負(fù)責(zé)，但這并不代表所有工作都必須歸屬他們。強烈建議在有需要的情況下讓Scrum團隊和專家加入。

產(chǎn)品畫布及其布局

在定義了產(chǎn)品愿景之后，接下來就應(yīng)該明確如何實現(xiàn)這個愿景，以便回答以下問題：

●   我們的用戶是誰？

●   用戶的任務(wù)是什么，將如何完成這些任務(wù)？

●   相關(guān)的高級別限制有哪些？

●   產(chǎn)品總體設(shè)計將會是什么樣？

●   我們可以使用哪些現(xiàn)成的Epics和用戶故事來實現(xiàn)這一設(shè)計？

產(chǎn)品畫布示例

如果把待回答的問題與產(chǎn)品畫布相比較，就會發(fā)現(xiàn)產(chǎn)品畫布的實際布局并沒有按照時間順序來進行。但要理解和掌握產(chǎn)品畫布的創(chuàng)建，時間順序非常重要。

產(chǎn)品畫布的時間順序布局示例

上圖顯示了創(chuàng)建產(chǎn)品畫布的邏輯步驟。從回顧產(chǎn)品愿景（Product Vision）開始，到研究產(chǎn)品的實際用戶和創(chuàng)建角色（Personas），一直到為第一次迭代創(chuàng)建可用故事（Ready Stories），每完成一個步驟才能開始下一個步驟。

請注意，對“限制”的描述與“用戶旅程”的創(chuàng)建應(yīng)同時進行。而有些限制不一定會影響用戶旅程，因此也可以提前完成該步驟。

創(chuàng)建產(chǎn)品畫布的7個步驟

●   第1步：產(chǎn)品愿景和名稱

產(chǎn)品愿景盒是對產(chǎn)品愿景板的總結(jié)。創(chuàng)建產(chǎn)品愿景盒的一個好方法是用一兩句話描述愿景中最重要的部分。

在應(yīng)用開發(fā)過程中，應(yīng)用本身的名稱往往被忽視。我們很少會在項目的第一次迭代階段就想好應(yīng)用的名稱，應(yīng)用名稱既要朗朗上口，又要體現(xiàn)應(yīng)用的作用，不是一件容易的事情。

一個好的名稱對參與項目的每個人都能帶來積極的影響，增強對項目的歸屬感。就像角色一樣，參與者將開始與他們正在或幫助創(chuàng)建的應(yīng)用產(chǎn)生情感上的聯(lián)系。如果在一開始不對產(chǎn)品命名，且該應(yīng)用不是外部應(yīng)用，那對它的命名將永遠不會被優(yōu)先處理。

●   第2步：創(chuàng)建用戶畫像

在我們開始考慮如何開發(fā)功能之前，了解為誰以及為什么要開發(fā)這些功能是至關(guān)重要的。為此，我們可以開展一些便于創(chuàng)建用戶畫像的研究。

角色示例

用戶畫像基本上可以歸結(jié)為一個以研究為依據(jù)的用戶原型。使用角色來模擬一組用戶的方法同樣以科學(xué)研究為依據(jù)，并非營銷人員和用戶體驗設(shè)計師所使用的那種不需要證實的創(chuàng)作技巧。無論是其內(nèi)容還是使用效果，都有助于建立共鳴、確定項目焦點、促進溝通和在項目團隊中形成共識，幫助項目團隊做出并捍衛(wèi)決策。

除此之外，這個步驟中的研究部分將有助于驗證在創(chuàng)建項目愿景時做出的所有假設(shè)。請記住，我們已經(jīng)在項目愿景中說明了誰是目標(biāo)用戶群，以及他們的需求是什么，所以這個步驟可以在不與任何用戶交流的情況下完成。另外，還是需要對已經(jīng)做出的假設(shè)進行檢查。就像解決程序漏洞一樣，在項目開始時更改應(yīng)用所需投入的時間和精力，是進入到生產(chǎn)階段后的10到100倍。

在處理快節(jié)奏的西門子低代碼項目時的挑戰(zhàn)之一是缺乏時間，因而無法創(chuàng)建以定量科學(xué)研究為依據(jù)的傳統(tǒng)角色。幸運的是，“臨時角色”提供了一個解決方案——通過極少的訪談來完成研究。雖然其價值不如傳統(tǒng)角色，但由于可以在一兩天內(nèi)創(chuàng)建，因此對項目來說是非常值得考慮的。

●   第3步：創(chuàng)建用戶旅程

此時我們和團隊已經(jīng)清楚地知道用戶是誰、需求是什么，以及希望通過構(gòu)建的應(yīng)用完成什么目標(biāo)。接下來，就是要在角色、任務(wù)以及應(yīng)用的工作方式之間搭建“橋梁”。用戶旅程提供了一個實現(xiàn)這一目標(biāo)的有效方法。

o    客戶旅程

這在市場營銷層面很常見，即描繪出包含應(yīng)用程序在內(nèi)的整體體驗。當(dāng)有了客戶旅程之后，接下來就可以將其用于準(zhǔn)備工作。

客戶旅程示例

o    腳本

腳本是一種更加具體的方法。該方法非常類似于漫畫小說或電影腳本，不僅可以定義用戶與應(yīng)用之間的交互方式，還可以根據(jù)需要添加背景。

腳本示例

通過詳細(xì)的腳本或是粗略地勾勒出草圖并添加文字和箭頭來講述故事，都是可行的。另外需要注意的是腳本不一定要“漂亮”，只需要有助于旅程的設(shè)計和團隊內(nèi)部想法的溝通即可。

o    用戶流

抽象的最低級別是用戶流，與微流程非常相似。用戶流示意性地描繪出用戶完成一項任務(wù)的流程。

用戶流示例

用戶流創(chuàng)建起來十分容易（甚至完全可以使用PowerPoint創(chuàng)建），其在設(shè)計體驗和調(diào)整整個團隊如何達成目標(biāo)方面起到非常大的作用，因此被認(rèn)為是一項最基本的工作。

我們推薦通過腳本去提供更多的背景，讓設(shè)計體驗變得更容易，也可以忽略一些不太相關(guān)的細(xì)節(jié)。這些細(xì)節(jié)能在后面的階段使用用戶流來繪制。

建議不要對每一個具體的用戶旅程都進行繪制，而是專注于最重要的。畢竟我們采用的是敏捷工作方式。

●   第4步：定義相關(guān)限制

正如上文提到的，定義限制的時間并不是一成不變的。只是要記住有些限制會影響用戶旅程，因此應(yīng)該在之前或與用戶旅程同步定義，比如只能在實體辦公室內(nèi)使用網(wǎng)絡(luò)功能這一限制，讓用戶位置成為用戶旅程中的一個關(guān)鍵部分。

在定義限制時要注意它們與項目的相關(guān)性。一個有一百條限制的列表不但無法成為有效的準(zhǔn)備工具，而且還會適得其反。在實際迭代階段需要有足夠的時間來定義和處理限制。

●   第5步：設(shè)計

設(shè)計環(huán)節(jié)是將“用戶旅程”轉(zhuǎn)化為需要構(gòu)建的應(yīng)用的第一步。根據(jù)應(yīng)用的類型、客戶的類型，以及客戶在使用西門子低代碼平臺方面的成熟度，該環(huán)節(jié)中的實際應(yīng)用可能會有很大的不同。

在一般情況下，有至少四種非常有效的工具。

o    網(wǎng)站地圖（或應(yīng)用地圖）

這個在網(wǎng)站設(shè)計和開發(fā)中被廣泛使用的工具在應(yīng)用設(shè)計和開發(fā)中卻不那么常見，一般只要繪制出應(yīng)用的頁面結(jié)構(gòu)即可。

網(wǎng)站地圖示例

o    線框圖

實際屏幕設(shè)計草圖的保真度和抽象程度各不相同。由于該階段是項目的準(zhǔn)備階段，所以不宜過度。應(yīng)將重點放在設(shè)計整個系統(tǒng)而不是單個頁面上，并在整個用戶體驗框架的設(shè)計與準(zhǔn)備第一次迭代之間找到平衡。低保真、中保真和高保真這三個級別的保真度，每個級別都有自己的優(yōu)勢和劣勢。

線框圖及不同保真度示例

和用戶旅程一樣，線框圖至少要達到低保真度，也建議至少準(zhǔn)備幾個中保真度的線框圖。最好由用戶界面或用戶體驗設(shè)計師來完成這項工作，但其實每個人都可以創(chuàng)建低保真線框圖，用筆和紙或者白板也可以。使用線框圖來嘗試不同的設(shè)計和解決方案比到完成建模后再去改變要來得快。除此之外，好的線框圖能夠準(zhǔn)確地引導(dǎo)如何對一組特定的頁面進行建模。

o    風(fēng)格模板

用戶界面的視覺語言對于應(yīng)用的可用性和品牌形象非常重要。要在應(yīng)用中將這種視覺語言與最佳用戶體驗相結(jié)合可能有一定的難度，無論是在設(shè)計階段還是在與團隊成員或相關(guān)方交流和討論設(shè)計時。在應(yīng)用尚不存在的情況下，可以基于應(yīng)用的視覺語言進行設(shè)計，這是使用風(fēng)格模板的技巧關(guān)鍵點。

風(fēng)格模板示例

在實際應(yīng)用還未被開發(fā)出來的情況下，風(fēng)格模板的設(shè)計清晰地定義了應(yīng)用的視覺語言和品牌形象，這個方法非?？焖偾矣行А?/p>

o    設(shè)計/企業(yè)標(biāo)識指南

大多數(shù)公司都有關(guān)于網(wǎng)站或應(yīng)用設(shè)計方面的準(zhǔn)則和資產(chǎn)。如果有的話，應(yīng)該將它們加入到產(chǎn)品畫布的設(shè)計環(huán)節(jié)。

●   第6步：創(chuàng)建Epics

到了這一步，我們已經(jīng)了解并研究了用戶，知道他們想要完成什么目標(biāo)，并且已經(jīng)設(shè)計出讓他們使用應(yīng)用來實現(xiàn)目標(biāo)的方式，甚至創(chuàng)建了一個設(shè)計框架。這時我們已經(jīng)得到了創(chuàng)建Epics所需的所有信息，這是將應(yīng)用設(shè)計轉(zhuǎn)化為用戶故事的第一步。

Epics指的是超大型用戶故事，其無法在一次迭代期間完成，或者需要劃分成獨立用戶故事以便從中創(chuàng)建“可用”的用戶故事。大多數(shù)時候，Epics描述的是一個需要分成幾個部分才能實現(xiàn)的大型功能。

比如“使用戶能夠在線購物”這個Epics可以分成多個用戶故事，包括在網(wǎng)店里挑選貨品、設(shè)置送貨地址、使用在線支付選項為商品付款等。

在創(chuàng)建用戶故事的同時創(chuàng)建Epics，可以節(jié)省大量時間并添加項目重點。創(chuàng)建可用的用戶故事本身就會占用大量時間。處理一個由500個用戶故事組成的大型文件并不容易，所以最好是10個Epics故事加20個用戶故事。

●   第7步：創(chuàng)建可用故事

產(chǎn)品畫布的最后一步是創(chuàng)建至少覆蓋前1-2次迭代的可用用戶故事。

請注意，可用用戶故事指的是符合“可用”這一定義的故事。由于這是第一次交付可用用戶故事，所以最好能讓整個Scrum團隊參與到這一步驟。

西門子低代碼的豐富經(jīng)驗

西門子低代碼在產(chǎn)品愿景和畫布方面積累了非常豐富的經(jīng)驗。我們在各種項目中使用過這種方法來啟動項目，甚至曾經(jīng)在一個僅持續(xù)一周的概念驗證項目中，使用了由腳本、應(yīng)用地圖、線框圖和風(fēng)格模板組成的“微縮版”產(chǎn)品畫布。

基于項目經(jīng)理、Scrum 管理人員和開發(fā)人員所提供的反饋，我們實現(xiàn)了一些積極的效果：

●   以少量準(zhǔn)備工作大幅提高最終結(jié)果的質(zhì)量

●   通過產(chǎn)品畫布中的資產(chǎn)確定在更短時間內(nèi)完成應(yīng)用所需的重點

●   一次即實現(xiàn)正確的效果：畫布的每一個步驟都包含研究、實驗、設(shè)計和反思。對開發(fā)階段的起始部分進行改進，避免項目期間的返工

●   增強團隊溝通和效率

通過收獲這些經(jīng)驗的成果，我們認(rèn)為產(chǎn)品愿景和畫布方法是最佳實踐。

如何使用產(chǎn)品畫布

本文在詳細(xì)描述產(chǎn)品畫布的同時，也明確了在開始第一次迭代之前進行準(zhǔn)備的好處?，F(xiàn)成的方法在西門子低代碼項目中很有效，但最終還是關(guān)乎內(nèi)容、準(zhǔn)備階段所解決的問題，以及給項目帶來的額外好處。另一個有趣的細(xì)節(jié)則是一些團隊選擇繼續(xù)在整個項目中或部分環(huán)節(jié)使用產(chǎn)品畫布，而不局限于準(zhǔn)備階段。

西門子低代碼團隊將用戶流作為可用用戶故事定義的一部分。相比用戶故事的文字內(nèi)容，用戶流的線框圖能夠更快、更有效地讓團隊充分理解用戶故事。

但最重要的是，無論一個項目的規(guī)模和復(fù)雜程度如何，適當(dāng)?shù)臏?zhǔn)備工作能更有效和更有針對性的展開開發(fā)工作，以提高實際應(yīng)用的質(zhì)量。