【SOP不藏私】系列＃EP1「連猴子也會的PRD指南」
寫在正文之前：誰適合這篇文章？
本文很”適合”很推薦在小團隊中UIUX兼PM角色的新手，透過這篇文可以讓您了解一份簡易的PRD架構為何，幫您工作溝通更順暢。
本文”不適合”中高階的PM，裡面沒有提到任何「需求排序」的評量方法，要如何衡量「需求的優先級」可以說是一門藝術。(我相信很多團隊都是BOSS說的需求一律優先往上調，正所謂隕石開發法，BX設計師我也當過RR)
本文”不適合”中高階的UIUX，裡面沒有提到任何UX原則，也沒有任何的UX Design的方法，也沒提到如何製定產品的各種指標。
本篇就十分狹窄的只談PRD這件小事(任性)。
第零章、為什麼身為一個UIUX要寫PRD？
為什麼一位UIUX設計師要學寫PRD？如果你看完下面我的情境描述，發現跟自己的工作狀況有87%像的話，那麼恭喜你可以試看看撰寫PRD釐清自己做產品的脈絡架構。
情境#1：筆者的前公司為機器人新創團隊，該設計中心因為沒有PM，所以必須UIUX Designer兼PM，正所謂逼上梁山，不得不做。
情境#2：在新創公司，因為要背的案子很多，所以對口的開發RD也相對多。公司設計團隊沒有撰寫設計文檔的習慣，故文檔散亂不統一，故必須建立團隊中的設計文件SOP制度。
情境#3：新創團隊通常人員流動率都會高，故此需要一份共同的設計文件面對很多RD輪流開發一直交接的狀況，故此一份好的文檔可以永流傳在團隊中，不只讓上級長官安心，菜鳥UIUX也可以學習如何建立自己的專案宏觀思維。
情境#4：對於畫圖來說，打字的成本又相較更低。故在開始動筆畫圖前先打打字，讓腦子建構出對於產品價值、功能以及更細節的流程，可以快速討論出可行的產品結構。
對於UIUX人員來說，PRD或許只是很多設計文檔的集合，但對當初的菜鳥如我而言，已經到了幫產品進行「功能需求排序」與「指標立定(數據探查)」的未知領域，也是一種額外的學習成長方式。
第一章、什麼是PRD？
PRD (Product Requirement Document)，中文全名叫做產品需求規格書。PRD的主要目的是幫助公司在開發產品時需要的規格書，不論是新產品開發或是舊產品疊加新功能進行產品迭代，都需要撰寫PRD。(PRD不是絕對，筆者知道很多公司根本就沒在寫PRD的XD)
由於PRD目標是將產品需求「描述清楚」，方便開發團隊或是相關利害關係人溝通使用。任何的設計文件都是輔助將「抽象化、形而上的功能」，用各種方式「具體化」，故此PRD只求清晰明瞭，詞必達意。
第二章、為什麼要寫PRD？
PRD在本質上是一種溝通協定(Protocal)，為一種統一PM、UIUX、RD間的溝通方式。寫PRD一定沒有口頭溝通快，但一定會比起口頭溝通來的準確。(即便我的交互設計稿件有時也會沒寫清楚，但還是相當認可文件化的溝通方式)
由於PRD有著「由大到小」的思考框架，必須從「開立功能、排程規劃、頁面流程、功能參數」一步一步的撰寫，故會逼自己開啟對於產品思路整理。逐步落實「由價值到細節、由近期到遠程」的思考模式。
我私自認為寫了PRD之後，在工作流程上有其二個優點：
1、降低「溝通阻力」：
正因為PRD一份白紙黑字，沒有含糊的字眼，可以讓產品從幻想的「價值論述」到實際的「功能落地」，收攏眾人對產品功能想像。
在前公司製作遊戲APP的過程，設計師必須老老實實的寫出「其提案會議中該APP中的對打刺激感該如何呈現？從首頁APP到遊戲開始，流程有幾步？一局時長可能為何？遊戲結束後輸家有沒有爆炸狀態？」
畢竟PRD是在說明產品怎麼實踐的文件，到了實作階段，一份好的施工文件可以承上起下，讓產品價值很「通暢」的落地。(怎麼感覺髒髒的XD)
2、統一「溝通媒介」：
在實際工作場域中，很少有一個APP的誕生，永遠只對口一位RD。當RD產生輪值的狀況。一個能總覽的所有文件的入口就相對的重要。
以前公司的機器人APP為例，一款APP會牽涉「用戶語意指令、機器人本地指令語句、機器人表演動作、遊戲背景音樂、遊戲開頭動畫」等複雜的外部文件清單資源。
所以「統一文件集中管理」，讓每個來跟您索取資源的人更有效率的拿到自己需要東西，優化溝通的效率是工作者要克服的題目。
第三章、除了PRD之外，還有什麼要寫？
在PRD之上還有MRD、BRD等文檔，但筆者今天只會對PRD進行比較詳細的解說。（怎麼突然跑出這麼多D？！）
3.1 除了PRD還有BRD跟MRD
BRD (Bussiness Requirement Document)，中文名稱叫商業需求文件。該文件大部分在聊市場中的商業趨勢。一份BRD可能不止一個產品，而是數個產品為主的切入商業鍊路。
BRD文件內會提到市場趨勢、商業模型等，故此BRD用來決定公司大戰略的方向，去看數個產品對於公司的「總體戰略」與「商業價值」。
MRD(Market Requirement Document)，中文名稱叫市場需求文件。該文件決定產品對於用戶的價值，一份MRD內需有該產品的市場分析、用戶分析、需求分析、競品策略、產品路線圖等，用來看公司現在醞釀的產品能提供哪些與其他競爭對手們，增加哪些不同的功能去切入這個市場。
PRD 產品需求文件，則決定產品該做成什麼樣子。如產品功能、功能流程邏輯、交互方式、產品原型…等，用以跟開發RD團隊溝通。
承上，BRD、MRD、PRD有著「由大到小」的相依關係，所以說不是文件寫完，產品就做完，你也就發大財了，這些文件都會經過很多內部的變動與外部的影響去不斷的迭代它。
3.2 用大白話了解BRD、MRD、PRD
讓我用更白話的方式，說明三者的關係
「BRD」就是在討論現在做什麼產品比較好？然後決定有沒有價值？那要不要做？「MRD」就是討論假如競爭對手很多人都做它，那我們公司要做出哪些不同特色？「PRD」就是既然决定做這個產品了，這個產品要做成什麼樣子？
3.3 工作中真的會寫這麼多的文件？
認真回答：「當然不會阿！！這位孩子！！」在真實的工作場景中，我們不可能很清晰的將BRD、PRD、MRD三者切開，在我的工作經驗中更多的狀況是PRD、MRD是揉和在一起撰寫成一份產品提案簡報，用來對上級老闆報告，這個產品要不要開案，然後預計的工作排程為何。
更何況，產品開發之路不會所有的產品roadmap跟feature開發都會非常順遂。當開發團隊不斷小增量的將功能釋出投入市場、測試市場反應，一定會影響原有的功能排序與產品路線圖。(正所謂計畫趕不上變化!?也比不上老闆的一句話!?)
如果你知道你規劃的功能做出來很少人用，你還會想要優化它嗎？還是會移除它呢？如果想要優化，是不是有其必要商業目標？跟Operation部門或是HelpDesk部門丟過來的需求，其需求排序優先級為何？這些都是在PRD中可以一目了然可以寫清楚的項目。
第四章、PRD的內容組成是？
4.1 第一部分「文件概況」
修訂紀錄與文件概況：其中包含日期、時間、專案負責人、平台版本、目前產品版號、利害關係人等。
4.2、第二部分「產品簡介與功能(Product Value)」
4.2.1 產品簡介與目標說明
第二部分主要在集中在產品功能的描述；如產品簡介(Overview)、產品價值論述(Value)、目標客群(Target User)、用戶故事(User Story)、功能條列(Feature)、開發排程(develop phase)、版本號(Release Version)、進版時間(Release Time)
其中筆者認為把「需求來源」寫清楚是對於設計師來說相對重要的事情，在畫圖前先把需求來源弄清楚。先確認該需求是從內部企劃部門來？還是從HelpDesk來？或是從老闆來？都可以先標記清楚。
根據筆者的工作經驗，有些需求不見得是優化新增產品功能就可以滿足需求，或許有些需求只要稍加釐清或許也用不到進RD開發了，但更多比較悲慘的是釐清需求之後，發現需求過大影響產品結構XD，這時就要去看需求後的商業利益大小(如何衡量需求的優先級，不在本文討論中)。
4.2.2 開發排程 (Priority)
將功能盤點出來，區分工作排程的先後順序，如Phase0、1、2、3。在P0部分則為該產品的MVP，先把最小可運行的產品功能定好，在依照開發資源切分等。
由於筆者的前公司都會先定好整體機器人系統的上版時間，通常來說我的工作習慣是會將第2、3點綜合寫在一起，將用戶故事、功能、發版時間做好表格排列，用以掌控產品當前狀況。
4.3 第三部分產品架構與流程
4.3.1 功能心智圖 (Function Map)
功能心智圖為產品功能模塊的集合，其顆粒度粗細必須RD對於該功能需求了解到何處，以及未來產品開發的路線圖。
如「會員資料」功能模塊中的「編輯會員資料、上傳會員頭像」或是更特別的「註銷會員帳號」子功能都可以寫上去。
相信UIUX入門者大家都寫過這份Map，你可以用Xmind寫，也可以用Miro寫，不管使用哪種心智圖工具，只要所有人能了解「現在」與「未來」要做的功能，都是好工具
如何寫FunctionMap，請看嫁給 RD 的 UI Designe這篇。https://blog.akanelee.me/posts/168560-functional-map/
4.3.2 產品資料結構圖 (IA)
IA圖主要是幫助設計師思考功能內的資料結構與相關定義，如果有更細節的定義要寫出來，這樣的表單可以幫助後端工程師在前期就開好DB儲存欄位。
如果以「會員頭像」功能為例：
有無預設頭像？如果有那你就要畫一張預設圖給前端RD；
需要限制多少KB的圖嗎？如果不限制，那用戶上傳的圖過大，要圖片壓縮就必須請後端RD串壓圖Lambda；
尺寸格式有限制嗎？可讓用戶上傳PNG甚至動態GIF嗎？如果都開放，要請後端RD定義資料格式。
(總之盡你知識範圍所能的寫清楚，即便你寫了清楚，根據工作經驗RD們也會問你沒想過的問題，去幫你完善你的功能定義XD)
4.3.3 全局、局部功能邏輯圖 (Flow Chart)
撰寫邏輯圖，不論全局或是局部功能的。例如產品會因為登入前後的關係會加多不同的功能需清楚寫下來。
4.4 第四部分「圖形化流程(flow)與原型(prototye)」
不管是高低保真原型、線框圖流程(Wireframe&flow)、精細圖流程(mockup&flow)。不管用任何工具做，只要呈現產品單一功能流程的樣貌都可以歸類在這邊。
你可以用sketch開一張大畫板傳到zepin，用超連結貼上給你的RD看圖面流程；也可以傳到invision慢慢拉hotspot，重點是要衡量「時間成本」盡可能的達到與RD「溝通清晰」的目標就可以。
如果有意識的讀者就會發現越上方的章節，在溝通概念時，都偏純「文字化」詮釋方式，越進入到mockup階段越接近「視覺化」詮釋方式。
4.5 第五部分「產品指標 (Metrics)」
在產品指標的部分，當每一個功能釋出時，您都會先想一下該功能需要達成的「商業目標」為何？然後根據Goal>Signal>Metric的思考方式(由大到小，也可以說是樹幹、樹枝、樹葉的思路)，去考該功能的評量方式，之後在與RD人員進行事件(Event)埋點。
但要小心，「商務指標」與「體驗指標」會隨著不同的產品會有不同側重方向。
如以優化遊戲功能的認知程度為例，該功能優化主要目的是更改功能中的文案敘述(Term)，進而減低用戶理解功能的負荷，進而降低執行任務的難度，增加執行任務的速度。
你可以用碼表去計時Task與Task之間的完成時間，但減低心智上的評量是你埋再多事件也感覺不出來的，故此我們可以抽取NASA-TLX或是QUIS量表中的「認知學習」構面，進行發版前的質性測試。
但話說回來，就算你降低了Tasks與Task間的速度，使用了精簡的文案減低了用戶的認知負擔，是否就能讓用戶更愛玩這個App呢？更願意長時間的待在這個App呢？進而達成遊戲App好玩，玩家長駐於此的商業目的呢？或這就是我們在定指標時需要再三提醒自己的地方，故此產品屬性的不同會影響我們看待指標的重要程度。
4.6 第六部分「字串表(Strings Table)」
若稿件進入開發，則定key與不同的value，該規則為湯六前公司的規定。每個APP在開發實需將字串填入表格，最後在某個時間點進版時間點，需將不同APP的字串表收集到字串管理軟件Poedit中納管。
4.7 第七部分「附件」
我會將不同平台的切圖鏈結與相關APP的工作時間表放在這邊，讓專案關係人進行查閱。
第五章、Q＆A
5.1、PRD有什麼固定的格式要遵守嗎？
我認為PRD沒有固定的格式，只要能讓開發團隊有脈絡的知道每個施工細節，能把產品做「好」就是好的PRD。
所謂的格式可以隨著公司的專案規模，個人需求，產品迭代的規模大小而定，千萬不要「墨守成規、墨守成規、墨守成規」(很重要所以說三次！！)
以前也沒有人跟我說PRD要放字串表，但在溝通的過程中經常發現RD們會需要拿字串，長久之後不如直接把字串直接納入PRD中，列為撰寫PRD的SOP，等到大更版時，再上繳到團隊中的字串管理工具Poedit。
5.2、我們公司的團隊是SRCUM跑法，所以不寫PRD可以嗎？
以前我也有錯覺，認為scrum開發跑法可以不寫文件。直到老師叫我回去看看敏捷宣言，我才恍然自己錯很大！！
在敏捷宣言中，從來沒有說過「不寫文件」，只是比對起「詳細的文件(施工圖)」來說，更著重在「可用的軟體」。所以啊～當有人說敏捷不寫PRD，請貼以下敏捷宣言網址給他，跟他說再看一次。以下為敏捷宣言鏈結。https://agilemanifesto.org/iso/zhcht/manifesto.html
5.3 在PRD中會有設計規範(design guideline)、去決定字級大小、元件命名等東西嗎？
以湯六本人的看法，我認為設計規範是UED設計團隊給「內外部設計師」、以及「RD人員」建立的元件庫規範，不見得要放在產品開發文檔中。
如果您們家的產品規模比較小，那我認為加開一個章節放進去也無妨，但由於筆者前公司屬於做遊戲性質高的APP產品，故每一款APP都會有不一樣的guildeline與美術風格。
所以老話一句「PRD沒有固定標準，只要達成與RD團隊的協定，盡量減少溝通阻力以及增加管理效率」即可。
5.4 寫PRD有什麼工具可以使用嗎？
許多人都推薦AXURE RP來撰寫PRD跟Wireframe，其優點是整合性高，內建流程圖工具並可以快速產出小小的html低保真原型。
但如果您是跟我之前的公司一樣，屬於沒什麼預算，且不想添購除了SKETCH以外的設計軟件的話，可以推薦您使用「Dropbox Paper」
優點是讓專案參與人可以線上共編筆記之外，滑鼠滑動到工作區域左側還有章節進入頁，可以讓相關的工作人員快速查找文件（GoogleDoc也可以拉）。只是你的心智圖(Xmind)、流程圖(Draw-io、Miro)就要用第三方的軟體做完之後再把鏈結貼上去PRD內，會比較小麻煩一點。
5.5 有其他人的PRD範例嗎？湯六你會推薦誰的？
我會推薦「人人都是產品經理」這個網站，在這個網站中你只要輸入「PRD」關鍵詞就可以發現中國大陸很多人逆推PRD練習文章，一開始我也是模仿他人的PRD寫法然後慢慢改良而來。還是重申，PRD這只是一個實作產品的溝通的優化方法，千萬不要被這個框架給拘泥了。
以下為該網站連結：www.woshipm.com
最後的最後，希望這篇文章能給任何的身兼多職者有所幫助，祝大家在工作中離苦得樂，當個開心的產品人😀
如果您還想再看到更多類似的文章，可以按按「拍手」👏👏👏不求拍好拍滿，只求隨喜功德(*´∀｀*)人(*´∀｀*)滑鼠按住拍手即可連拍！湯六感謝您的鼓勵！
