作者：Willem Gorisse，Mendix公司應用開發項目經理

本杰明·富蘭克林（Benjamin Franklin）曾說過：“沒有準備的人注定會失敗。”這句話在今天仍然非常有道理。

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

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

什么是產品畫布？

在開始研發任何新產品之前，需要了解該產品的用途、受眾和目標，這是產品畫布的意義所在。

產品畫布是一種結合敏捷方法和用戶體驗原則的規劃工具，能夠幫助團隊構建提供良好用戶體驗的產品。產品畫布的創造者Roman Pichler將其描述為“一個簡單而強大的工具，能夠幫助用戶創建具有良好用戶體驗和強大功能的產品。它結合了敏捷開發和用戶體驗設計，用角色、腳本、場景、設計草圖和其他用戶體驗縮影來補充用戶故事。”

如何根據產品愿景和產品畫布來應對變更

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

這里的“充分”指的是：

為提供業務價值做好準備

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

做好準確預測的足夠準備

有充分的細節來啟動第一次迭代

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

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

產品愿景板簡介

第一步是使用產品愿景板為項目創建一個高水平的愿景。

產品愿景板示例

產品愿景板需要解答以下基礎問題：

我們為什么要創建該應用？

誰是我們的目標用戶群？

目標用戶群的需求是什么？

我們如何設想出能夠滿足這些需求的產品？

我們這樣做是為了滿足哪些業務目標？

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

產品畫布及其布局

在定義了產品愿景之后，接下來就應該明確如何實現這個愿景，以便回答以下問題：

我們的用戶是誰？

用戶的任務是什么，將如何完成這些任務？

相關的高級別限制有哪些？

產品總體設計將會是什么樣？

我們可以使用哪些現成的Epics和用戶故事來實現這一設計？

產品畫布示例

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

產品畫布的時間順序布局示例

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

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

創建產品畫布的7個步驟

第1步：產品愿景和名稱

產品愿景盒是對產品愿景板的總結。創建產品愿景盒的一個好方法是用一兩句話描述愿景中最重要的部分。

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

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

第2步：創建用戶畫像

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

角色示例

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

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

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

第3步：創建用戶旅程

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

客戶旅程

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

客戶旅程示例

腳本

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

腳本示例

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

用戶流

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

用戶流示例

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

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

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

第4步：定義相關限制

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

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

第5步：設計

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

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

網站地圖（或應用地圖）

這個在網站設計和開發中被廣泛使用的工具在應用設計和開發中卻不那么常見，一般只要繪制出應用的頁面結構即可。

網站地圖示例

線框圖

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

線框圖及不同保真度示例

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

風格模板

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

風格模板示例

在實際應用還未被開發出來的情況下，風格模板的設計清晰地定義了應用的視覺語言和品牌形象，這個方法非常快速且有效。

設計/企業標識指南

大多數公司都有關于網站或應用設計方面的準則和資產。如果有的話，應該將它們加入到產品畫布的設計環節。

第6步：創建Epics

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

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

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

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

第7步：創建可用故事

產品畫布的最后一步是創建至少覆蓋前1-2次迭代的可用用戶故事。

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

西門子低代碼的豐富經驗

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

基于項目經理、Scrum 管理人員和開發人員所提供的反饋，我們實現了一些積極的效果：

以少量準備工作大幅提高最終結果的質量

通過產品畫布中的資產確定在更短時間內完成應用所需的重點

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

增強團隊溝通和效率

通過收獲這些經驗的成果，我們認為產品愿景和畫布方法是最佳實踐。

如何使用產品畫布

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

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

但最重要的是，無論一個項目的規模和復雜程度如何，適當的準備工作能更有效和更有針對性的展開開發工作，以提高實際應用的質量。