我發現很多PM都會有一種習慣。
只要開完一次需求會，
就會立刻打開文件(Figma, Axure,…等)，
開始畫流程、寫規格、列規則。
覺得這樣很像一個「專業」的 PM。
功能入口在哪裡、按鈕長什麼樣子、
哪一頁接哪一頁、
每個步驟要填哪些欄位，
都畫得飛快。
遇到不清楚的，就去網路上找一個競品，
嘴巴上說是「研究」，實際上是「複製」。
當時心裡應該只有個很單純的想法：
就是把流程畫得夠清楚，
研發、設計、客戶應該都會覺得很專業。
結果現實長什麼樣子？
畫了一張自己想像中的流程圖，
拿給團隊看，
工程師皺眉，設計困惑，
客戶看了一眼說：
「這樣的流程合理，但是我們公司不是這樣的…」
後來就進入大家都熟悉的狀況：
一改再改，越改越亂，
改到最後已經不知道這張流程圖到底在畫什麼。
其實，
問題不在於畫得不夠細，
而是在「根本還沒弄清楚這個需求是誰在用、怎麼用、要解決什麼問題」之前，
就急著把流程畫出來了。
◆ 還沒搞清楚「誰」在用，就開始規劃流程「怎麼走」
很多 PM 收到需求時，長得都很像這樣：
「我們想做一個退款功能。」
「這裡要加一個審核機制。」
「希望能調整一下報表查詢。」
話聽起來都很熟，
也都很合理。
於是你打開筆電，開始進行你熟悉的流程：
-先畫一條使用者流程
-想像他會在哪一個頁面點進來
-會看到哪些欄位
-填完之後按送出，跳到哪裡畫著畫著，你以為自己已經抓到重點了
但真正的問題，往往從來沒被問出口：
-這個需求，到底是誰在用？
-只有終端使用者嗎？還是財務、客服、行銷也會碰到？
-有沒有主管審核、後台維護的人？
-同一件事情，前台怎麼看？後台怎麼看？
-很多 PM 一開始只抓到「一個使用者」，
-卻忽略了「一群不同角色的人」。你畫的是「使用者流程」，
但現實世界裡，
還會有「管理者流程」、「後台維護流程」、「權限管理流程」。
結果你畫完一張自以為很完整的流程，
拿去跟客戶或內部單位確認時，
財務說：「那我們怎麼對帳？」
客服問：「那客訴進來時，我要去哪裡查？」
行銷補一句：「那活動期間的優惠碼怎麼設定？」
你才發現，自己畫出來的那條流程，
只涵蓋了整個需求的一小角。
◆ 你想的是「做完一個功能」，客戶要的是「一個完整的解決方案」
再舉個例子，
假設今天有個需求叫「新增退款流程」。
如果只用功能的角度去看，
你很容易會變成這種思考：
「在訂單明細裡加一個『申請退款』按鈕，
按下去跳一個表單，
讓使用者選擇原因，按確認送出，
後台顯示這筆單在退款中。」
聽起來沒錯。
但如果你拉高一點維度來看，
同樣是「退款」，會牽扯到的人突然變多了：
-使用者：提出申請、查狀態
-客服：接電話、處理抱怨、幫忙查詢
-財務：確認金額、對帳、實際匯款或刷退、發票單據、簡訊通知
-行銷：活動期間的退款比例可能不同
-主管：需要看到整體退款比例與原因統計這時候你就會發現，
畫一條「使用者按完就沒事的流程」，
其實解決不了整個團隊的問題。
你只完成了「做出一個功能按鈕」，
卻沒有完成「這家公司處理退款這件事」的需求目標。
同樣的事情也會發生在：
-權限管理
-匯出報表
-發送通知
-多國語言版本例如：客戶提了一句：
「我們的客戶有很多來自歐美和日本，所以要支援多國語言，至少要英文和日文。」
如果你只把它當成「畫面要有語系切換」，
那最後就會變成：
-介面文案有翻，但是產品說明沒有
-後台欄位名稱是中文，報表卻要英文
-客服看的是中文畫面，客人看到的是英文畫面，兩邊對不起來真正應該在需求階段被問出來的，是：
-哪些角色需要哪幾種語言
-哪些內容是固定文案，哪些是資料
-語言切換是跟著帳號，還是跟著裝置
-後台要不要可以針對不同語系調整文案如果這些一開始沒有被看見，
後面的流程圖再怎麼畫，
都只是在補「技術債」。
◆ 沒有拉高維度，流程圖只會變成「改不完的地圖」
很多 PM 的日常，長得很像這樣：
第一次版：
你畫了一條自己想像的流程路線，
拿去給客戶看，對方說：「我們實際上不是這樣做。」
第二次版：
你加了一些客戶剛剛講的細節，
工程師看完說：「這樣資料撈不到。」
第三次版：
你再補了一些欄位、加幾條註解，
內部營運參與進來，提出完全不同的期待。
每次你都在修那張圖，
但你修的其實只是「圖上的線」，
不是「背後的結構」。
原因只有一個：
你一開始就從太低的維度切入。
你先決定了「畫面長什麼樣子、流程怎麼走」，
才慢慢去補「誰會用、要解決什麼問題」。
順序整個倒了過來。
比較健康的做法，應該是反過來：
先問清楚「角色」：
誰會碰到這個功能？只有使用者嗎？還是有管理者、審核者、維護者？
再釐清「情境」：
是在什麼狀況下會用到？例行？例外？救火？補救？
再確認「目標」：
這個需求最後要被誰認定為「有用」？是客戶主管？營運？還是財務？
最後才是「流程」：
在這樣的角色和目標之下，
各個人要走的路線分別是什麼？
如果沒有前面這幾層，
流程圖只會變成一張「你腦袋裡的版本」，
不是「這個組織真的在運作的版本」。
◆ 把思考維度拉高一點，你才不會只是在「畫一個功能」
回過頭來看，其實需求這件事，
很容易被誤解成「講清楚畫面跟步驟就好」。
但對一個 PM 來說，
真正重要的其實比較接近這幾件事：
這個需求牽涉到哪些角色
-每個角色要完成的是什麼任務
-哪些人只需要看資料，哪些人可以改資料
-這件事情如果做錯，誰會受傷、成本在哪裡
-這個功能完成後，對整體流程的影響是什麼當你習慣從這個高度開始思考，
你就比較不會被一個按鈕、一個欄位、一個介面細節牽著走。
你會比較常問的是：
「除了這個使用者之外，還有誰會被影響？」
「這件事做完後，下一個接手的是哪個角色？」
「有沒有哪個單位的流程，會因為這個功能變得更麻煩？」
這時候你再去畫流程圖、寫規格、定規則，
圖上那條線就不再只是「做完一個功能」的路徑，
而是「讓整個需求目標被完成」的路徑。
◆ 畫流程之前，先把這幾個問題問完
如果你現在手上剛好有一個需求，
準備要開始畫圖、開會、拆任務，
你可以先停一下，
把這幾個問題寫在筆記本上：
-這個需求，有哪些單位的同仁也會接觸到？
-每個角色在這件事裡，要完成什麼任務？
-誰有權限改？誰只能看？誰只需要被通知？
-如果這件事做錯了，最麻煩的是誰？成本在哪裡？
-這個需求完成後，對現有流程是簡化還是變複雜？當你能夠先把這幾題回答出來，
你就比較不容易畫出那種：
客戶看不懂、團隊不認同、
畫了一整張，卻沒有人真的願意照著走，
單純只是自嗨的流程圖。
這樣做，其實也不會讓你變成什麼厲害的系統架構師，
更不會讓所有需求突然變得完美。
它做的，只是幫你把視角往上拉一點。
讓你在畫第一條線之前，
先看清楚整張地圖上，
想想到底有哪些人會在這張地圖上，你會遇到那些角色。
當你慢慢習慣用這樣的高度看需求時，
你會發現一件很微妙的變化：
團隊問你的問題變少了，
客戶說「不是這樣」的次數降低了，
改需求還是有，但不再是那種「方向整個錯掉」的改。
那時候，
你畫的就不再是一個「看起來很專業的流程」，
而是一個，「團隊會照著走的地圖」。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
留言