文/ Iris Chen
在我數位產品經理 PM 職涯中，少說帶過數十個數位產品開發專案，其中九成都是網站平台改版。
打造一個全新數位產品和針對既有產品進行改版，專案的啟動（project kick-off）方式有所不同。
一個全新的數位產品規劃，需要更往前思考，分析目標的市場/競爭者/使用者等不確定因素，思考全新的商業模式的各種可能性，會花較多的前期評估企劃。當然也可能採取精實創業 lean startup 模式：直接做就是了，上線撞牆後再來調整。
改版專案通常有較明確的方向以及待解決的問題。原因可能是系統老舊、UX 使用者體驗設計不良、公司業務調整擴張或打造新功能整合等。
以目前產品設計潮流以及因應技術更新快速，約略 3~5 年就會進行翻修大改。當然市面上也有許多知名網站已經存活 10 多年未曾改版，往往是因為系統架構過於龐大、程式邏輯複雜、加上開發的工程團隊已經不知道換過幾輪，改版茲事體大、牽一髮而動全身所以沒人敢動（我曾接過這種案子），所以就還是繼續撐著疊床架屋吧。
在剛接改版專案時，我所做的第一件事情，便是依照 產品經理 PM 第 2 講：從頁面拆解練習 IA 資訊架構（Information Architecture），把既有網站平台拆解後列出資訊架構與主要功能。有些客戶會提供數年前的規劃文件參考，但通常既有版本上線後，數年間也會不斷進行功能調整，許多功能已經和原本的規劃設計不符，因此我通常不會參考這些文件。
列出既有網站的資訊架構後，會對網站全貌有清楚的認識。在同時以外部人員視同一般使用者的身份來看，過頁面時也會發現許多 UX 上的問題。此時可以一一記錄下來。
接下來，進行需求訪談。通常會有幾種狀況：
A：解決既有問題類型
有些客戶非常熟悉數位產品經營，能有條理的列出改版目標與所需修改的問題。但這種客戶可遇不可求，大部分是客戶敘述的非常模糊或者只有概念性的問題。這時候產品經理需要一些技巧來引導發掘問題。我通常把它稱為「聊天」階段：
「我們使用者反應網站很難用，會迷路 」
「是那邊難用呢？可以示範一下嗎？」
「搜尋找資料都找不到… 」
「通常是輸入哪些關鍵字呢？你期待的搜尋結果是什麼呢？」
這其實是基本的用戶訪談技巧，目的是把許多抽象的描述轉化成具體的問題/流程/邏輯敘述。這個概念有點類似敏捷式開發裡的 User Story 自然語言敘述：
身為一個家長，我想要找住家附近的學校，這樣我可以瀏覽這些學校的評價。
（但我們這篇不談敏捷式等開發流程）
因為時間關係通常不會寫這麼多字，而且如果可能，我會嘗試把模糊字詞當場討論確認，例如：「什麼叫做附近的學校？」也許程式邏輯是 GPS 定位住家附近 20 公里，或者輸入設定同一行政區。只是這樣直接列出解法通常有風險，所以只當筆記附註參考。因為對使用者而言，所謂的「附近」往往只是一種感覺，有人的附近是希望走路可到、有人覺得開車可到、有些人要比較學區限制…等。如果有需要，還要做進一步的用戶訪談或測試釐清，這些可列為後續的「待辦事項：釐清住家附近學校的定義」。
而由於先前已經先把資訊結構列出，所以很容易依序引導客戶提出並立刻歸類各種需求描述。這樣的訪談過程約 1 小時至半天不等。
B：目標導向類型
除了上述直指需求問題外，有的改版專案會清楚列出欲達到的目標。例如我遇過這幾種：
「增加新會員註冊 2 倍成長 」
「推出讓 SaaS 客戶覺得 WOW（驚艷）的功能 」
這些目標往往意指新功能的推出或者既有功能優化，需要廣泛創新思考各種作法可能性。
假設我們的目標為「增加註冊 2 倍成長」，從產品經理角度來看，我們會先把新會員獲得（acquisition）等行銷宣傳策略放一旁，而專注於產品設計本身，此時可使用 HMW 發問技巧來思考：（How might we）我們如何將導入的流量轉化成新會員註冊？
在數年前規劃親子天下改版時，我們就設定了媒體網站上幾個會員轉換門檻：投票、測驗、文章兌換，以及觸發動機：遊戲化機制 Gamification 親子幣點數累積。從這樣的想法出發再延續到完整的互動流程動線、CTA（call-to-action）UI設計，會員數據定義與收集、點數換算與後台管理等一連串的機制設計。
C：不知道問題在哪裡的類型
這樣的改版出發點也滿有趣的。客戶覺得好像應該要改版、隱約覺得應該有問題要解決、應該可以做得更好，但又不知道要改什麼、或者怎麼做比較好。
這時候會有比較全面性的訪談。包含公司各相關部門（stakeholders）、外部使用者訪談等，從中彙整出需求列表，設定改版目標，並配合公司策略方向排定優先次序等。
數據分析以及使用者訪談
在改版專案進行前後，也需檢視既有數據資料、並視需要安排各種使用者研究。而在進行大改版之前，如果時間充裕狀況下，有時我會建議幾個重要頁面或使用流程先做幾輪小優化、將數據調至滿意後，再以此為基礎進行大改版。
有時既有版本的數據追蹤碼埋設不夠完整，能提供的分析資訊不夠，會建議先將既有版本的埋碼補上，等有清楚的數據資料再進行改版。
當然如果既有網站問題非常明顯，例如有些功能流程使用者早已抱怨連連，就直接對症下藥進行，簡化數據分析以及使用者訪談階段。
特別一提的是，既有數據分析僅能分析既有使用行為、從中發掘目前遭遇的問題。如果新改版的目標在於擴大市場或是創造新使用行為，既有數據較難以反映出此方向。
專案 Kick-off meeting簡報項目
有些公司會從 BRD（Business Requirement Document）、PRD（Product Requirement Document）、Business plan 著手一步步進行，但我個人覺得如果目標方向已經很清楚，可以儘量精實簡單處理，不要為了製作文件而努力去產出一堆文件。
當前述分析都取得初步共識後，通常會召集專案相關人員舉行 Kick-off meeting，產品經理簡報以下訊息：
- 既有版本的問題
- 改版目標
- 改版重點功能介紹
- （長程）Product Roadmap
- （近程）專案時程
- 專案成員 R&R（Role & Responsibility 角色與權責）
- 風險與問題分析（Risk management & Issues）
- 其他待議問題
當然有時還會視狀況附上以下分析：
- 市場分析
- 競爭者分析
- 使用者分析
- 數據分析
- 商業模式描述
- 成本與收益分析
接下來就進入專案規劃開發流程。
§ 產品經理系列文章
產品經理 PM 第 1 講：專業能力
產品經理 PM 第 2 講：從頁面拆解練習 IA 資訊架構（Information Architecture）
產品經理 PM 第 3 講：如何開始一個改版專案
數位產品經理的一天 — 在雲端管理跨國產品開發團隊
數位產品經理的一天 — 以美國大型證券商交易網站為例（奶爸老喬的矽谷觀察 Silicon Valley Old Joe）
§ 如果您對數位產品經理相關內容有興趣，歡迎加入Facebook【數位產品經理不想公開的秘密 】私密社團
※ 與作者面對面交流討論，歡迎參加 2018/08/
31 產品經理實務研討：
http://edu.userxper.com/pm2018/
