PM必備技能: 產品需求/規格文件(下)
PM成長之路:產品經理訓練營#8
1.關於溝通這件事
2.我從失敗中不斷修正的文件溝通經驗
3.總結:沒有一定的文件撰寫公式, 唯有取得共識的文件才是成功的文字溝通還沒有閱讀上篇的朋友可點此:
1.關於溝通這件事
首先我們先來討論”溝通”是甚麼?
維基百科對於溝通的解釋:
溝通的過程主要是資訊發送者把思想內的資訊內容以可交換或共同認可的表示方式編碼，以某個渠道來傳遞，有效及良好的溝通應該是雙向溝通。
因此, 在無法用口頭溝通的情況下, PM必須把交付給他人執行的文件
2.我從失敗中不斷修正的文件溝通經驗
→關於我製作wireframe的迭代史:
分享以下文章可以了解wireframe的應用及wireframe普遍在UX/UI/PM間的責任歸屬與配合方式:
我之前負責網站建置專案的經驗,當時公司剛建立新的營運模式, 業務簽訂報價單/合約後, 請外包配合做網頁前端設計,交由公司後端工程師串接(利害關係人沒有UX), 當時第一次負責專案的我,外加UI也是第一次接case的情況下,我深受”不知道自己不知道甚麼”所苦, 在溝通上常遇到認知落差不斷的反覆溝通修改,當時我花大量的時間以PPT剪貼方式不斷來回和客戶及UI確認調整方向,結案後被檢討花太多工時在協助UI確認修改方向,應該是請UI產出線框搞確認文件對細節。
於是我開始思考並查詢用甚麼方式/工具能夠快速地產出東西,讓UI能在無法接觸客戶的狀況下可以馬上了解客戶的需求,在專案起始前先和客戶/UI/後端工程師取得共識,減少後續不斷製作示意圖反覆的確認。我嘗試過一些軟體, 過程中經歷過內部同事看不懂覺得架構太複雜, 不斷迭代後, 終於找到取得利害關係人共識的工具:googlesite(操作非常簡易快速、可初步確認整體網站的架構、每個頁面串接後台功能, 沒有細緻的icon細節功能,焦在網站重要功能上)。
目前比較多人推薦wireframe軟體為figma(也有人推薦axure),但我覺得還是依照專案利害關係人的共識/習慣(主要是這些人要看的懂且理解),及專案成本是否能承擔製作精美的wireframe的工時?沒有一定得用哪個軟體,但PM得因應不同的利害關係人快速調整最有效率的溝通工具/方式。
→關於我製作PRD的迭代史:
老實說我之前的工作經驗還真不知道PRD是甚麼…之前都是做好googlesite並標註會串接後台的功能, 工程師有問題會再來跟我確認, 但了解PRD之後,我才了解之前工程師反映看wireframe/報價單看不出來後台要怎麼寫了(當時都是冷處理一一回覆工程師的我實在深感抱歉…)。
UI/老闆/客戶端都偏好看wireframe覺得清楚一目瞭然, 但工程師以串接程式的角度, 會希望有更多的資訊, 例如:時間格式/新增文字限制/圖片比例/新增數量限制…等,這些都是wireframe/報價單有極大可能都看不出來的(佛心的工程師會自己猜想後跟PM確認, 照文件寫程式的工程師可能就會做出有很多bug的網站)。
運用所學到的PRD文件的核心宗旨, 套用在MOS APP點餐功能製作一份PRD文件→點我下載。
3.總結:
文件最大的目的為讓所有利害關係人了解專案的脈絡發展, 並讓knowhow永流傳, 我覺得最主要是要讓大家都看得懂(並非各自論述)非常重要, 沒有一定的撰寫公式(當然公司本來就有文件格式規範的話就能省去和利害關係人取得共識的時間)。
至於繪製wireframe/架構圖使用的工具都各自有擁護者, 我還是一樣秉持能讓利害關係人看得懂即可, 依照團隊專案屬性甚至可以用簡單快速的非主流工具, 就能達到大家的共識。
沒有一定的文件撰寫公式, 唯有取得共識的文件才是成功的文字溝通
感謝你的閱讀及支持，任何問題都歡迎來信和Elaine交流｜ela71930@gmail.com
如果喜歡這篇文章，請給我1–10個拍手(越喜歡當然可以拍越多，甚至按住不放!這也是我持續寫作的動力！)此外還可以動動手指「Follow」Elaine ☺