從UX/UI設計師成為PM，工作內容與核心能力哪裡不一樣？
成為UX/UI設計師一年半後，因為公司人力調動，我成了主要與客戶溝通的PM、並繼續著UX/UI的工作。從需求洽談、釐清問題、競品分析、資訊架構，到wireframe製作、介面設計，交給工程師開發後，還得進行專案進程的控管、開發後的測試、以及交付驗收，比一條龍還一條龍（笑
在與客戶有了更直接的接觸後，真的更深刻體會到身為乙方公司的難處，以及設計師與PM的工作內容及核心能力的差異，如果你也是從UX/UI設計師跨足PM，我想這邊文章多少能幫助你一些😉
一、 面對客戶修改，PM要踩住底線、善用籌碼
做Designer的時候，常常是透過PM得知客戶反饋，再合作進行修改。那時候覺得，PM好像只需要下指示就好，現在才發現原來每個異動的功能，都可能是PM用盡全力擋下來的最小幅度修改。
畢竟身為第一線處理客戶需求的人，在報價固定、資源、時程有限的狀況下，必須精準地拿捏功能與範圍，而不是被客戶予取予求。
道理看似簡單，但人在江湖，大部分的客戶需求，並不像線上課程舉例的那樣單純，更多的是參雜各方的情緒與壓力：捍衛己見的、固執的、各懷鬼胎想凹功能的（純UX研究可能比較沒這種狀況，因為受訪者大多是出於自願）
所以，身為接案顧問公司的乙方，在前期溝通後擬定的合約就是整個專案的底線。
PM在對客戶溝通時必須拿出原則：範圍內合理的、對使用者來說必要的調整，PM可以選擇協助修正，但那些超出資料庫架構的、屬新流程的，PM最好以「不在合約範圍內」的方式化解掉、或善用「驗收」作為籌碼，收到客戶尾款再另起專案，既不讓原有專案賠錢，又有新的專案收入。
二、PM不能沒有基本程式概念
其實，基本的「程式概念」在當UX/UI Designer的時候就很重要了，不僅是要了解原生、客製元件、還要理解資訊架構與邏輯，才不會設計出工程師做不來的介面或是流程。而PM「不能沒有程式概念」的原因有兩個：
1. 知道客戶需求如何轉化成工程邏輯
有了基本的程式概念，能讓PM在跟客戶溝通時，知道該問些什麼、或是必須婉拒什麼，否則PM很容易淪為工程師與客戶間的傳聲筒。
從保持團隊的生產力的角度切入，讓手下的工程師保持專注在「開發邏輯的心流上」是很重要的，因為每打斷一次工程師，他們都得再花額外的心力回到剛剛的開發邏輯上。身為PM，如果你多懂一些程式，就會知道該問清楚哪些東西，就可以很快跟工程師確定架構走向，也可以先把客戶過於天馬行空的需求在會議中先化解掉，讓專案進行更有效率。
2. 為了不被工程師矇
以前早就聽大家說「PM與工程師是相愛相殺的關係」，從Designer跨PM後真的特別有感觸（笑）
先說好，我很愛我團隊的工程師們！但很不幸的，我也被其中一位工程師矇了不只一次！
我們稱他為工程師Ｈ，最早一次是當設計師時，按鈕有肉眼可見的鋸齒邊緣，跟工程師Ｈ反應後，對方居然以每台手機解析度不同唐塞，我一想，誒不對啊！我已經照Android dpi分門別類出給你了，怎麼可能有這種事，搬出理論反駁後，Ｈ他只好摸摸鼻子將圖片放到正確的dpi中。
再來是成為PM後，有次網頁的區塊間有一條奇妙的白線，請工程師Ｈ處理，他卻堅持白線無法修改，我跟工程師Ｈ說一定是div margin或padding的問題，請他檢查，Ｈ依然不願意修改，最後我只好請他開啟網頁檢查讓我來修改。果然！被我找到多餘的程式碼，修一下就解決了。（事情傳開後，工程師Ｈ居然被其他工程師當面恥笑「你居然被PM發現程式碼問題！」）
最近一次是在做主機轉移的時候，我們提供給客戶的檔案出現亂碼，當時我請工程師H檢查一下編碼設定，誰知道原來工程師H在早年的專案中，並沒有做好編碼佈局，才導致現在要解決亂碼的話要逐筆調整。而這份技術債，工程師H自然又是不願意還了，但我仍堅持，即使要花時間，也應該要幫客戶處理好，跟工程師H曉以大義了一番，最後還是在其他工程師圍剿後，才終於妥協整理出一份沒有問題的檔案給我。
或許是我運氣好，遇到的這位工程師工作態度不佳，但我還是要提醒新人PM，不見得所有工程師都願意跟團隊一起為專案的最佳解努力。
職場上喜歡偷懶推託的工程師，都很擅長利用「資訊落差」來晃點別人。如果不會一點程式基礎作為自保或是據以力爭的武器，專案的進行只怕除了「外患」還有「內憂」。
三、 想結案？先處理好「利害關係人」！
能左右客戶需求的因素實在太多了，其中最主要、也最棘手的就是「利害關係人」的處理。
在市面上的課程或講座中，「利害關係人」常常只是一閃而過，我想就是因為情況太多元，很難用隻字片語去解釋。
當時我手上是一個工業協會的官方網站跟APP翻新整合專案，在所有利害關係人皆到場的線上會議中，表面上「協會總經理」是決定官網及APP功能走向的主要人物，而他提出的願景跟大方向，與會的協會秘書跟其他召集人也都一致贊同沒有異議，原以為這次的專案目標能快速聚焦，沒想到會後，秘書與軟體部召集人對功能的設計卻出現了歧見。
其實已協會的組織架構來說，真正執行協會大小事的是秘書，召集人則是在數位化的數據管理上必須跟總經理交代，兩人對其中一項「會員標籤功能」（可以想像是幫會員進行類似市場區隔的分類）有非常不同的看法。
召集人認為貼標籤屬於內部管理事宜，需要的標籤名稱與貼標的動作都應該由協會（秘書）進行，而秘書則認為，標籤的歸類應該讓協進會的會員自己決定，自己既不知道每個會員廠商的詳細屬性，也不願再負擔更多工作。
一方面是積極的軟體部召集人，另一邊則是擁有簽約生殺大權的秘書（你沒看錯，搞了半天總經理根本不管這事），兩人互不相讓，在來回致電協調下，好不容易在召集人願意分擔秘書管理貼標的工作下，雙方才達成了協議，但這齣程咬金也讓專案硬生生拖了近一個禮拜的時間，才決定好程式架構的走向。
其實在我們這行，技術都好解決，難的是利害關係人多時，要如何達成專案需求整合，才是考驗PM功力的時候。
結語：都是在處理人，但面向與深度大不同
UX/UI設計師與PM都要理解客戶需求並提出解方，但更多的，PM要處理的是關於人的事情：不論是對外的協調、對內的時程管理，絕對沒有表面上以為的悠閒啊！（笑）他們是專案進行的推手，也是保護團隊的第一道防線，同在這行的朋友們，我們一起加油吧！
如果覺得這篇文章不錯，歡迎Follow、拍手或分享給朋友們！
長按拍手 1~10次 代表還不錯，有學到新東西；
長按拍手 10~20次 代表這篇文章剛好幫助到你/妳，我會很開心的！
長按拍手 20次以上 代表想看更多「Kait | 從UX/UI設計師到PM」的故事！
