朕在coding

為何想分享這篇主題?

相信大家在職場工作時，都有很多會議要參加。畢竟，會議是凝聚共識，溝通想法很好的一個方式，但相信在現實生活中，最常聽到的抱怨，就是唉，又要去開一堆沒有意義的會。

所以開會真的是浪費時間嗎？其實不見得，有很多好想法，是透過腦力激盪會議想出來的，也有很多風險，是因為在會議中透過檢視整體流程而規避的。所以，開會不是無用，而是常常開會時沒有聚焦、開會後又沒有把結論和共識具體記錄下來，也許有人會說，我們都有指派會議記錄呀！但會議記錄通常只有1人並是最菜的那個(小聲)。而與會成員七嘴八舌過後，大家會期待所有東西真的都有被寫下來？你覺得有可能嗎？這裡我也不是說會議記錄不認真唷，而是大家忽略了大腦擁有自動填補空缺區塊的功能，甚麼意思呢？各位應該都有看過連環漫畫吧，有沒有發現漫畫只需畫出重點，不需把所有細節都畫出來，但你在看漫畫的過程，會覺得所有整個故事是連貫的還是一格一格的呢？應該都是連貫的吧，這就是大腦神奇的地方。好，那回到正題，所以會議紀錄會利用他的想像力去填補大家想法的空缺，但並不是每個人想法都一樣，可當下又沒辦法馬上確認，所以等會議結束之後，單憑著純文字的會議紀錄去回想當下開會的場景就會困難許多。

但假如我們換一個開會的方式，透過使用者故事對應，大家一起來說故事，草繪手稿，相信一定會比純文字的會議紀錄文件要來得生動活潑，而且，你會發現大家討論會變得更熱絡，接下來就是要簡單分享一下甚麼叫做使用者故事對應。

從前從前．．．

使用者故事對應，聽起來好像很困難，但可別忘了，我們從小到大都一直在聽故事、說故事，還記不記得小時候媽媽說的枕邊故事，從前從前，有一個英勇的王子.....為了拯救公主.....展開了一場神奇的冒險旅程。我們就從這個簡單的小故事來入門吧。

這趟旅程的主角是王子，所以，我們當然要把主角的形象和背景在更加具體一點，這就是人物素描在做的事情。而旅程目標是解救公主，但在解救公主的過程中，一定會遭遇到的各個關卡，這些關卡就是我們的流程，而我們的系統就是要幫助王子解決各項難關，最後達到他的目標，救出公主。這就是簡單版的使用者故事對應，一點都不難 ，對吧 ?

既然了解甚麼是故事對應的話，那我們來稍微深入看一下名詞解釋

旅程目標

每個使用者情境，都可視為一趟旅程，而使用者為何要進行這趟旅程，一定是為了要完成某項任務。

所以，我們透過旅程目標，來確認出系統的核心價值，否則，以王子的故事來說，如果不知道這趟冒險的核心價值是要拯救公主，那王子會不知道為何要進行這場冒險。 

人物素描

人物誌的分析是使用者故事最要的一環，人物誌分析要有效，一定得明確定義使用者的特性，不可含糊概括。

而使用者故事對應可在使用者旅程上方擺放人物素描，讓我們在思考旅程的過程中，可以很輕易地戴上使用者的面具，站在使用者的角度思考他的旅程。

下圖為 使用者旅程 + 人物素描 的範例，要盡量描繪出王子的形象，就會讓整個冒險旅程的輪廓愈來愈清晰，比如說，王子是富二代，那我們在解決穿越森林的關卡時，說不定可以配給他一台直升機之類的....

聚焦討論

當我們的使用者地圖都完備的時候，開始自我驗證是否該想的都已經想到了嗎。

1. 討論使用者在旅程中會具體做甚麼事情
2. 討論使用者會做甚麼替代的事情
3. 討論甚麼能讓整個流程變得更棒
4. 討論萬一事情出錯了該怎麼辦

以上述的例子來看，我們在穿越森林的關卡，配備了阿帕契給王子。所以，王子會如何具體的操作阿帕契，那如何能讓王子體驗更佳呢？適不是再配給王子一個阿帕契飛行員會更好？萬一阿帕契壞掉了，那王子是否有別的方式穿越森林。透過自我的問題詢問，我們能在釋出產品給使用者之前，先盡量將可能的問題點揪出來。

 

原型製作

無論是圖像還是文字，其實都無法讓使用者明白是否就是他們想要的東西，即使他們確認這是他們要的，仍然會存在著些許的誤差，因為人腦很擅長填補細節。因此，唯有請使用者操作看看，它們才可以知道所有細節是不是跟它們想像的一樣，但我們不可能實際把程式撰寫完才請使用者測試，這樣曠日廢時，所以透過Axure原型製作軟體，可快速拉出畫面，並且產生成html檔案，供使用者操作，以期在原型模式就能盡量貼近使用者所想的功能。

 

MVP(最小可行性方案)評估

聚焦預期結果

絕美的藝術從未被完成，只有被放棄。請細細體會其中的奧義。

舉例來講，如果我對你說，達文西的作品"蒙娜麗莎的微笑"其實是未完成品，應該沒人相信，因為觀賞者從達文西想要表現出來的預期成果來說(也許就是那個微笑)，它的確是完美的作品，所以不會有人關心達文西是否因為時間壓力而放棄了哪些部分沒有完成(也許達文西本來是打算畫全身人像)。

在軟體界也是一樣，當能夠聚焦出預期的輸出成果時，MVP的概念就會出現。

我曾經有問過同仁一個問題，現在有三個專案，分別是資料庫權限控管、資料表建置系統、資料庫還原系統，大家覺得哪個優先性高，三個同仁的答案都不一樣，而且每個人說的都很有道理。但是當我聚焦一下預期的結果，我說，假設稽核人員下個月要來稽核資料庫權限，那哪個專案優先性高?所有人都回答資料庫權限控管。

切割故事

當聚焦了預期結果，我們就能夠開始決定故事的優先順序，那些故事該先做，那些該後做，合理的切割故事，定義出釋出策略，透過漸進式的軟體增長，可以讓使用者快速使用到產品，並提供回饋。每次產品的釋出，我們都能從使用者身上學習到一些東西，透過這樣的循環，最終便能得到使用者需要的產品。

 

總結

使用者故事對應的重點強調在溝通。在溝通方面，人腦對圖像的記憶和理解，是勝過文字描述，再搭配敘事流勾勒出每項細節的先後順序，輔以便利貼的高移動性，會讓整體的溝通非常順暢。所以，使用者故事對應無需太在意是否寫出正確且完美的故事，而是要在意你是否說出你想要表達的故事，並且讓你的團隊成員也能融入你的情境當中。如果能善用這種開會模式，會慢慢不自覺的發現，開會也可以很有趣，也有高產值唷。