PM 文件指南 - 產品經理一定要掌握的 PRD/SPEC 心法與撰寫教學

產品經理的工作就是圍繞著溝通,在這裡作者整理了日常工作中溝通的技巧,包括文字和當面溝通、如何因應溝通對象來改變表達方式等秘訣。
評論
Shutterstock/達志影像
評論

作者 Ian Wu,產品經理。科技人。互聯網 | 熱衷社群、熱愛挑戰、享受生活,以持續提升自己為目標 | 保持好奇心與行動力,探索跨領域新事物。As Product Manager, Rich Our Life, Change Our World. Email

原文刊登於 medium,INSIDE 經授權轉載。

做為一個產品經理,撰寫需求文檔可說是產品經理 PM 無可避免的任務,同時要思考如何將產品規劃內容清楚表達給利害關係人 (Stakeholder) 了解並獲得支持。

在探討該問題時,我們回歸到人與人之間如何進行有效的資訊傳遞?口說與文字(文件)。

面對面溝通是最有效率傳遞資訊的方式,但隨著每天資訊爆炸與時間過去,我們 99% 已經忘記當時做某件事的時空背景與思緒;然而文字則是替我們保留了關鍵節點與脈絡,讓我們能夠回頭檢視與探討。

撰寫文件可說是產品經理最基本的工作。每個產業中,無論是產品經理、專案經理、產品負責人往往會被各式各樣的「會議溝通」填滿,為了有所考察與依據,許多文件需求與撰寫因此誕生了。舉個例子,軟體業常撰寫 PRD(Product Requirement Document),硬體業常寫 SPEC 文件(Product specifications),每個領域有不同的說詞,但其屬性與功用其實大同小異。

2019 年我在 #PM361° — PM 知識社群與大家分享過這個主題,這篇就回顧一下,來聊聊軟體領域常用的 PRD 以及概述他的兄弟好友們,BRD 與 MRD。

  • BRD: Business Requirement Document
  • MRD: Market Requirement Document
  • PRD: Product Requirement Document

說到這裡,大概有不少人對「PRD」是抱持各種疑問與是否有必要存在的眼神?常被討論的問題不外乎如下:

  • 開發過程中,一直變動,文件一直改,那不如不要寫,反正寫了還是改?
  • PRD 內容要寫到多細?要涵蓋什麼內容?什麼時候更新?
  • Roadmap 跟 PRD 有什麼不同,PRD 不就是 Roadmap 嗎?
  • RD 又不會仔細看,幹嘛寫?
Ian Wu
2019 分享會中與會者的提問

BRD、MRD、PRD 到底是什麼?

BRD 在告訴利害關係人目前要進行的專案的商業價值與商業策略,短小精簡,沒有太多產品細節,主要溝通對象是高階管理者 C-Level(eg:CEO、CTO、COO)。

為什麼要做這件事?商業價值是什麼?向 C-Level 闡明值得投入時間與金錢進行這項投資。

我將 BRD 文檔中主要項目概括整理如下:

Ian Wu
BRD 元素組成

MRD 在告訴我們市場概況,我們要前進的戰場的情報概覽與分析,強調市場各種現況以及趨勢,屬於承上啟下的文檔,承接 BRD 開啟 PRD 方向,主要溝通對象主管、產品、運營、研發等團隊。

市場現況是什麼?存在機會是什麼?產品價值定位與主張在市場的哪裡?向產品、運營、研發等團隊以及主管說明產品模式、業務模​​式、運營模式、市場模式等,明確客戶及市場方向!

我將 MRD 文檔中主要項目整理概括如下:

Ian Wu
MRD 元素組成

PRD 著重於產品實作方法與流程,涉及交互、文案、頁面邏輯等,具體將產品各個細節解釋清楚,向研發團隊、設計團隊、測試團隊、UX 團隊等說明產品規格

產品功能是什麼?邏輯流程是什麼?交互流程是什麼?use case 有哪些?錯誤態如何處理以及時間、人力、資源等配置,向開發團隊說明清楚。

我將 PRD 文檔中主要項目整理概括如下:

Ian Wu
PRD 元素組成

💡BRD — MRD — PRD是一個從高層次到低層次的關係,BRD從策略高度告訴我們做什麼產品,MRD從戰術的觀點告訴我們怎麼突圍,PRD非常細化的告訴我們產品做成什麼樣。

為什麼需要 PRD?需要知道的價值三部曲

溝通,對象是誰?為了什麼目的?什麼時候進行?如何進行?

先歸納 PRD 要面對的利害關係人,如工程師、設計師、UX 等,決定要對他們表明什麼目的,每個角色重視的點都不同;是分別說明或是集中說明;文件撰寫方式是協作或是單一人撰寫。別忘記我們的目的是推動產品開發,如何藉由這份文件跟各角色溝通,讓他們「清楚知道」目標(Goal),如何拆解進行任務(Task),產出產品才是最核心價值的地方。

文件本身格式是有彈性,需多方向的理解與更新,不會有最完美的文件範本,不斷嘗試找出適合團隊的文化,就是最有效的方式。

💡Tips:

  1. 釐清利害關係人 (Who)
  2. 了解開發流程與時長,此時此刻團隊成員需要的 PRD 粒度如何 (When)
  3. 觀察團隊協作的方式,彼此角色任務關聯性,重視項目是什麼 (What)
  4. 了解團隊過去對開發文件如何分工,如何撰寫 (How)
  5. 了解項目含義與功能,挑選適合團隊的方式來編制 (Idea & Action)
  6. 透過詢問閱讀人員,了解自我盲點,不斷嘗試疊代更新 (Iteration)

歷史紀錄,過去做了什麼?原因是什麼?邏輯方法是什麼?

紀錄是用來復盤與釐清走過的道路,產品會不斷的堆疊上去,債務會不斷的累積,良好的紀錄是幫助我們遇到問題時,可以知道從什麼地方切入與檢驗,同時可以檢視產品開發的過程脈絡,減少猜測與不確定性。另一個面向就是當產品交接給下一任產品經理時,該產品經理會比較容易上手,增加 onboarding 效率。保持善念,不要留黑盒子(屎)給接手的人。

自我保護,白紙黑字留底,別讓口說無憑困住你。

Ian Wu

遇到這樣的對話,大概悔恨自己當初怎麼不寫文件,然後被迫吃下去,同時還要扛下產品責任,在老闆面前丟失 credit。

💡Tips:

  1. 清楚寫下事項A、B、C與負責人(責任分配)
  2. 在眾人會議上討論與畫押,會後寄出會議記錄與該文件(責任歸屬)

溝通、歷史紀錄、自我保護,利大於弊,花點時間投資,長遠來看是有助益個人與組織發展。

問題:要寫多細節?什麼時候要完成?開發團隊不看,還是都直接跑來問我!

換位思考,站在閱讀者、實作者的角度來思考。

複習一下,PRD 有溝通、歷史紀錄、自我保護等主要三價值。先確認你的目標是什麼,探究問題,定義問題後再去嘗試解決。例如,是要拿來跟工程師溝通產品流程,但是寫完了他們都不看,一直跑來問我,那不如不要寫?

Step 1:確立目標,「工程師,產品流程闡述」

確立溝通對象是工程師,目的是讓他們清楚了解產品流程設計

Step 2:定義問題,他們不看文件,跑來問我!

那他們不看的理由是什麼?動機是什麼?分析一下可能原因

  1. 文件冗長不精準,看到天荒地老,重點在哪裡
  2. 文件需求、規格細節寫的不清楚,缺漏一堆
  3. 文件總是都一直改或沒更新
  4. 文件總是一堆文字,簡單一張圖可以說明吧

Step 3:可能解決方法

針對定義好的問題,站在對方角度來思考嘗試提出解決方案。

  1. 檢視自己的敘述方式並修正,是否用了太多形容詞。
    例如:使用者查閱多次後,不再跳出通知訊息;當使用者心情愉悅時,他們會滾動更多頁面,我們要讓頁面滾動更通順。
    「查閱多次」是幾次?
    「心情愉悅」開發團隊在乎嗎?
    「更多頁面」、「更通順」是要表達什麼?
  2. 規格不清楚,文字一大堆,請多跟相關人員討論後撰寫。
    RD 在乎的是規格方向,不要一天到晚要 RD 通靈,具體的將步驟節點記錄下來,或是用流程圖更讓人了解到思路與規則。
  3. 文件一直改卻沒更新
    當多次遇到照規格文件實作之後,事後卻發現文件過時,規格已經改了,RD 就會對文件感到沒有可信度,轉而直接問 PM 確認意圖。建議可以跟 RD 團隊溝通好文件 lock down 時間(階段性文件、完整文件)、更新的頻率以及更新後主動透過 IM 通知給相關人員。

文件只是一個溝通的方式,別忘記還要搭配口頭溝通

文件只是一個溝通的工具 ,跟自己溝通(釐清思緒)、跟團隊溝通(闡明任務)、跟未來交接同事溝通(Onboarding)。

文字,具有保存性與可傳遞性,在時間與空間轉換的情況下,能夠讓所有人得到一致的訊息,確保大家都在同一個溝通平面。從公司角度來看,文件也是提供知識資產的保存,員工來來去去,如何將公司特有知識傳遞下去,文件就是其中一種方式。

何不把 PRD 當作是小產品經營?

產品開發大概會經過,Understand、Define、Sketch、Prototype、Development、Validation 等,把 PRD 作為產品來展開,思路其實差不多。

  • Understand:探索、釐清並了解目標用戶對 PRD 的需求
  • Define:根據需求,定義 PRD 涵蓋項目元素
  • Sketch/Prototype:嘗試撰寫大綱版本,並透過訪談驗證可行性
  • Development:開工,寫起來
  • Validation:完整 PRD 與實際產品產出落差距離,有驗證有疊代

PRD 實作撰寫經驗分享

Step 1: 建立目錄、索引

涵蓋的欄位有版本號、項目、優先序、負責人、發布日期,相關文件連結等等,主要目的是幫助在看文件前可以清楚知道這份文件的基本資訊,幫助查找。

Ian Wu
簡單版

Step 2:需求闡述

涵蓋內容有目標、背景資訊、價值、方案、驗證指標、附件

  • 目標:展示形式例如使用 user story 或是直述,端看團隊偏好
    As I am ___, I want to ___, so that___
  • 背景資訊與來源:市場、用戶、趨勢、老闆等,需求有根據並非無中生有
  • 價值:營收、成本、市佔、使用者體驗、系統優化等,盡量將價值量化,提高感受度
  • 方案:邏輯流程圖、業務流程圖、頁面流程圖、動作邏輯、錯誤處理等
  • 驗證指標:定義可以衡量需求的量化指標,如預期提高營收多少 %、提高 DAU 多少 % 等等,來檢視執行前假設與實際落差多少,幫助團隊做下一次決策與疊代

Step 3:佐證需求

提供支持該需求的佐證,可能是數據、市調、競品分析等,強化需求可行性,同時是展現分析能力與洞察力的地方,提高團隊對我們的信任度。

Step 4:審查(優化內容)

  • 內容必要,正確,清晰,一致和明確,過多形容詞請省略
  • 區分段落結構,可輕鬆搜尋信息(錨點、URL)
  • 在正確的時間使用適當字體和顏色,但不要五花八門,三種顏色差不多
  • 視覺化、具象化複雜的流程與細節,搭配圖示可以讓人更容易理解

Step 5:回饋與疊代(訂模板,非第一次可跳過該步驟)

  • 這裡指的是如果初步撰寫 PRD,還不確定團隊想要看到什麼欄位資訊,可以按角色諮詢閱讀者,讓他們說明解讀到什麼資訊跟我們預期是否有差異,差異點是什麼?
  • 修正它,修正它,還是修正它,然後訂出 PRD 大原則模板

Step 6:更新(資訊補充或是補齊)

  • 定期更新與歸檔,可能是按照開發週期,可能是按照自己的節奏,但建議要讓團隊能隨時知道最新資訊,才能發揮文件最大公用。

There is no perfect standard for PRD.
Think about what PRD does and deliver it with empathy.

相關資源

網路上其實有很多 PRD 的範本資源與其他產品經理如何應用撰寫,可多搜尋,其中個人認為中國網路這部分很多大佬分享與分析,可多多參考培養自己的方式。

關鍵字:PRD、Product Requirement Document、Product SPEC、產品規格書、產品規格文件、產品開發文件、需求文檔、規格說明書、產品設計文件、PRD 撰寫、PRD 範本、PRD 範例等等。

責任編輯:Mia
核稿編輯:Chris


上雲猶如太空探險之旅,iKala Cloud AIOps Services協助企業輕鬆穿梭多雲環境

人類從上個世紀積極探索外太空,為了將太空人送上天際必須克服各式挑戰,而現代企業要從「地端」飛向「雲端」,困難程度有過之而無不及。iKala Cloud AIOps Services 提供多項關鍵服務,幫助 IT 團隊輕鬆悠遊多雲環境。
評論
評論

探索外太空,曾經是國際間的科技競賽,近年 Tesla 創辦人馬斯克更準備把太空旅行當成商業服務,預計 2026 年要帶著人類登陸火星。完成一趟星際旅行,需仰賴嶄新的科技及跨科學精密計算,但你知道嗎?現代企業要從「地端」飛上「雲端」,其實挑戰程度不亞於飛向太空。

對企業資訊管理者來說,有限的 IT 資源無法應付繁重的維運項目,加上同時管理公私有雲架構更顯困難、資安管理複雜,例如需要人工執行過濾警示,各種大大小小挑戰不勝枚舉。換言之,企業想航行雲端,就像打造火箭需要龐大資源及人力。不過,現在有更輕鬆穿梭雲端的方式,就是使用雲端技術服務商 iKala 所提供的 AIOps Services(自動化雲端託管服務)

火箭升空前的全盤規劃:iKala AIOps 擬定系統架構規劃、教育訓練

完成一趟太空之旅,必須做足各種研究,例如精準計算飛行軌道、降落定位點、燃料耗用數、與地球通訊設定…等。

對沒有雲端架構經驗的企業來說,就如同當時的科學家,必須用土法煉鋼的方式檢查數據是否有誤。換言之,企業 IT 在升級之前,就需要有經驗的「雲端顧問」來釐清需求、協助規劃「升雲」之旅。而 iKala 就是企業的最佳雲端顧問,旗下 iKala Cloud AIOps Services 會搭配一位專責的技術客戶經理,協助企業提供即時的技術服務與專業建議。

究竟 IT 升級之前,iKala Cloud AIOps Services 有哪些服務?首先是「系統設計規劃」,涵蓋系統架構規劃書、系統上線/遷移計畫書,可因應客戶產業需求,提供對應的解決方案以及顧問服務。而越來越多企業會使用到 Google 的雲端資源,iKala 也有提供 Google 雲端平台訓練服務。

GCP 教育訓練課程多元,包含 GCP 基礎架構(網路設定規劃、權限控管、計算資源等)、大數據與機器學習(大數據分析 Pipeline、BigQuery、ML 模型訓練與應用)、軟體開發技術與流程(容器化、CI/CD、DevOps)等。因為 iKala 團隊取得 10 多項 Google 專業技術證照,才能在企業規劃雲端轉型的前期就一步到位,規劃出整體藍圖,提供更全面的解決方案建議。

火箭升空中的精密操作:iKala AIOps 輔助即時技術維運、資安管理

當火箭準備就緒、升空倒數之際便是決定這趟太空之旅能否成功的關鍵時刻。從太空人的行前訓練與身體檢查,到火箭的引擎測試完成,如果有靜電或一點火花都可能引發爆炸事故。光是在升空階段,太空總部就要有結構、熱控、姿態控制、資料處理、電能、遙傳指令、推進以及飛行軟體等龐大的系統工程師在旁待命。

換言之,企業 IT 移轉雲端過程就像火箭發射的當下,需要有專業、經驗足夠的工程師,才能即時協助企業順利上雲,甚至快速排除緊急的狀況。對此,iKala Cloud AIOps Services 提供兩大關鍵的幫助:技術維運、資訊安全管理。

iKala Cloud AIOps Services 的技術維運服務內容,提供 7 x 24 的 Help Desk,像是緊急 GCP 問題報修、產品使用技術諮詢;或是事故管理,如搭建監控系統、設定規劃告警政策、規劃日誌收集與留存。每月也會提供企業維運報告,報告書有營運效率檢討、流程優化、新服務項目、營運系統建議等。

至於資訊安全管理方面,除了基本的 GCP 專案權限控管掃描、應用程式 OWASP(Open Web Application Security Project)前 10 大項目資安弱點掃描,同時也針對近年相當受重視的 DDoS 防護,iKala 可協助企業導入 GCP 平台的 DDOS 防禦機制。iKala 掌握多年軟體開發和雲端管理經驗,可分享給客戶 DevOps、AI 第一手實務的作法與經驗。

火箭升空後啟動自動導航:iKala AIOps 提供 AI 自動化監控、帳務管理

當火箭成功升空後,太空人為了執行下一階段任務,這時候火箭就需要轉換成自動駕駛模式,或在探索其他星球時,出動機器人來協助執行人力無法負荷的任務,讓太空人專心處理更關鍵的工作。換言之,上雲後的 IT 架構就像升空後的火箭,應該減少 IT 人員的負擔,甚至不需浪費例行時間,就能夠快速掌握整體資訊系統的運作狀況。

不過要讓 IT 架構像火箭具備自動駕駛功能,勢必需要相當高的技術門檻,而 iKala Cloud AIOps Services 正好有相對應的服務。如此一來,IT 人員的生產力就能投入在更具商業價值的研發專案,讓 IT 部門轉型成可創造產值的單位,而非單純的後勤支援角色。

盤點 iKala Cloud AIOps Services 在此環節共有三大類服務。其中一項是 AI 自動化監控與通報服務,幫助 IT 成員主動監控系統,掌握是否有異常操作狀況。其二是帳務方面的管理,幫助企業產出雲端服務月用量帳務分析報告,針對軟體授權需求,整合出帳至  Marketplace 與第三方服務商,自動化做到 License 採購管理。

第三項則是針對服務級別協定(SLA)iKala Cloud AIOps Services 提供 24 x 7、5 x 8 兩種模式,在重大 GCP 服務異常中斷服務時,提供電話、e-mail 聯繫。而且每月會舉辦 1 次月會(以 on-site 或遠端視訊會議方式)提交書面報告。目前 iKala 的企業客戶服務超過 400 多家、涵蓋數 10 種產業,可說是企業成功上雲,最能安心託付的合作夥伴。 

事實上,雲端託管服務(CMS)是目前最夯的新趨勢,根據市調公司 MarketsandMarkets Research 報告指出,全球雲端託管服務的市場規模,預計從 2020 年的 624 億美元,到 2025 年成長至 1,162 億美元,複合年增長率(CAGR)為 13.3%。代表未來有大量企業採用 CMS,以降低 IT 基礎設施的投資成本及風險,藉此提升企業營運的競爭力。

由此看來,企業的數位轉型,就像上個世紀的太空軍備競賽一樣。「時間就是決勝點」,越晚起步的公司與其他數位能力領先群的企業相比,差距只會越來越大。現在就攜手 iKala 嘗試 iKala Cloud AIOps Services,打造穩定的 IT 系統、邁向數據驅動的商業模式,讓企業在數位世代站穩腳步,輕鬆穿梭多雲之間。

了解更多 iKala Cloud AIOps Services