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


Akamai 服務上新,於邊緣處推動快速創新

Akamai EdgeWorkers 為開發團隊提供豐富功能和工具來創建新的微服務,利用 Akamai 提供的 25 萬台分佈式服務器組成的網絡,在邊緣執行安全而快速的計算,並在邊緣暫存內容,以實現快速交付。
評論
評論

在雲計算技術還沒有大規模普及前,絕大部分企業和組織都需要自建數據中心,或通過託管的方式來部署自己的硬體基礎架構,並在此基礎上為員工和客戶提供服務。取決於業務或其他方面的諸多要求,此時需要部署的數據中心可能有很多個,並廣泛分佈在不同地區,藉此為客戶提供流暢的體驗,並透過多個數據中心保障連續性。在發展的過程中,隨著「雲端」的出現,讓各個組織的計算開始集中。

而當在線直播、無人駕駛、智能家電、物聯網等應用開始陸續深入我們的工作和生活,情況又不同了。以往透過雲平台集中運行和服務的模式,因為距離導致的網絡延遲已經對用戶的使用體驗產生極大影響。為了提供更敏捷、靈活、快速、可靠的體驗,企業需要從最貼近用戶的地方提供服務。因此,邊緣計算就成為最有效的解決方法。

透過將數據的收集、分析和處理等工作,由「雲中心」重新分散到最接近用戶的邊緣位置,企業可以就近為用戶提供服務,通過延遲更低的響應打造更出色的用戶體驗。

「無服務器」的出現,帶來計算方式的革新

以前,當組織需要上線一套業務系統時,首先需要採購並部署相應的服務器硬體,並且要負擔服務器日常運維過程中的管理、維護、補丁安裝、配置等繁瑣任務。

上雲前,組織需要在自己的數據中心,以硬體服務器的方式執行這一系列工作;上雲後雖然簡單許多,但依然需要面對雲服務商提供的虛擬服務器,從本質上來看相關負擔仍相當繁重。

無服務器(Serverless)技術的出現,讓組織可以在不需要考慮服務器的情況下,構建並運行由微服務構成的創新式應用程式與和服務。藉此不僅可以省略基礎架構管理任務,還能為幾乎任何類型的應用程式或後端服務構建無服務器應用程序,更方便、靈活地構建出具備極高可用性的應用。

Akamai EdgeWorkers :為創新賦能

Akamai EdgeWorkers 為開發團隊提供豐富功能和工具來創建新的微服務,利用Akamai 超過 25 萬台分佈式服務器組成的網絡,在邊緣執行安全而快速的計算,並在邊緣暫存內容,以實現快速交付。

當開發團隊在邊緣開啟代碼時,他們會將數據、見解和邏輯推送到更靠近最終用戶的位置。Akamai 的高性能、可擴展式實施模型,可確保數據和計算不會被延遲問題困擾,進而避免對數字化體驗產生負面影響。

在該服務幫助下,開發者可直接在 Akamai 的全球分佈式平台上快速、迭代地創建和部署新服務,以解決問題和自定義交付。

長期以來,Akamai 在邊緣計算的創新和成功實施皆具有優勢。自 1998 年起,便開始為 Akamai 內容交付網絡(CDN)的客戶推出自定義交付邏輯,其他里程碑還包括 2001 年的 Edge Site Includes 、2002 年的 Edge Java 以及 2014 年的 cloudlet 應用程式。

目前, Akamai 在全球擁有超過 4100 個入網點,為 EdgeWorkers 用戶提供出色的邊緣基礎架構規模和範圍,開發人員可以在靠近最終用戶和他們的數字化接觸點的地方部署代碼,以實現盡可能低的延遲。EdgeWorkers 同樣獨立於雲,客戶可以選擇利用 CDN 供應商或雲供應商平台上的無服務器計算功能。在 Akamai 幫助下,客戶可以在整個混合雲或多雲環境中部署單一的無服務器計算平台。

更多相關資訊:https://www.akamai.com/solutions/edge

本文章內容由「猿聲串動」提供,經關鍵評論網媒體集團廣編企劃編審。