敏捷產(chǎn)品畫(huà)布實(shí)用指南

本杰明·富蘭克林（Benjamin Franklin）曾說(shuō)過(guò)：“沒(méi)有準備的人注定會(huì )失敗?！边@句話(huà)在今天仍然非常有道理。

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

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

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

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

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

如何根據產(chǎn)品愿景和產(chǎn)品畫(huà)布來(lái)應對變更

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

這里的“充分”指的是：

●   為提供業(yè)務(wù)價(jià)值做好準備

●   為項目制定一個(gè)清晰的愿景

●   做好準確預測的足夠準備

●   有充分的細節來(lái)啟動(dòng)第一次迭代

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

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

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

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

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

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

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

●   誰(shuí)是我們的目標用戶(hù)群？

●   目標用戶(hù)群的需求是什么？

●   我們如何設想出能夠滿(mǎn)足這些需求的產(chǎn)品？

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

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

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

在定義了產(chǎn)品愿景之后，接下來(lái)就應該明確如何實(shí)現這個(gè)愿景，以便回答以下問(wèn)題：

●   我們的用戶(hù)是誰(shuí)？

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

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

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

●   我們可以使用哪些現成的Epics和用戶(hù)故事來(lái)實(shí)現這一設計？

產(chǎn)品畫(huà)布示例

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

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

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

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

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

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

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

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

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

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

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

角色示例

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

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

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

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

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

o    客戶(hù)旅程

這在市場(chǎng)營(yíng)銷(xiāo)層面很常見(jiàn)，即描繪出包含應用程序在內的整體體驗。當有了客戶(hù)旅程之后，接下來(lái)就可以將其用于準備工作。

客戶(hù)旅程示例

o    腳本

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

腳本示例

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

o    用戶(hù)流

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

用戶(hù)流示例

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

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

建議不要對每一個(gè)具體的用戶(hù)旅程都進(jìn)行繪制，而是專(zhuān)注于最重要的。畢竟我們采用的是敏捷工作方式。

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

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

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

●   第5步：設計

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

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

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

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

網(wǎng)站地圖示例

o    線(xiàn)框圖

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

線(xiàn)框圖及不同保真度示例

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

o    風(fēng)格模板

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

風(fēng)格模板示例

在實(shí)際應用還未被開(kāi)發(fā)出來(lái)的情況下，風(fēng)格模板的設計清晰地定義了應用的視覺(jué)語(yǔ)言和品牌形象，這個(gè)方法非?？焖偾矣行?。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

●   通過(guò)產(chǎn)品畫(huà)布中的資產(chǎn)確定在更短時(shí)間內完成應用所需的重點(diǎn)

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

●   增強團隊溝通和效率

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

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

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

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

但最重要的是，無(wú)論一個(gè)項目的規模和復雜程度如何，適當的準備工作能更有效和更有針對性的展開(kāi)開(kāi)發(fā)工作，以提高實(shí)際應用的質(zhì)量。