產品思維:身為產品經理PM必懂的基礎文件撰寫 — PRD? Proposal? Spec?

Tian
Tian
Nov 23, 2019 · 8 min read

什麼? PRD是什麼?能吃嗎? 那不是軟體產業PM才有的東西?

PRD可謂是產品經理最基礎的工作「文件」之一,每個產業只要是身為產品規劃者的必經之路,只是名詞的不同。說到「文書處理」很多人嗤之以鼻,畢竟可是吃力不討好的工作,那…還有存在的必要性嗎?

無論是產品經理、專案經理、產品負責人往往會被排山倒海的「溝通」淹沒,為了不被淹沒或是假性失憶,那只好白紙黑字寫下來,畫押!?但文件的畫押又充滿各種妖魔鬼怪的名詞,每個圈子的不同造就名詞的不一,但其實本質都相同。

你可能聽過這些名詞:Roadmap、Proposal、Release Plan、PRD/MRD/BRD、SRS。之所以寫這篇文,也是常被詢問幾個類似問題

  • 在軟體開發裡面 SRS撰寫通常是誰的工作?目前公司職責劃分有問題。
  • prd跟roadmap怎麼切?尤其當在實際工作執行時,很可能都是同一人(pm)製作,超容易混淆。
  • roadmap 跟prd也是因為我現在的公司其實在文件編輯還沒有很健全,正在跟主管討論這件事案子跟產品多了,覺得更需要文件管理。

每個文件要落地生成都很不簡單,每個產出過程都是血與淚的故事

Image for post
Image for post

Product Roadmap 與 PRD (Product Requirement Document) 的基本要素與異同

Product Roadmap 產品路線圖,描述的是產品策略的時間路徑。

描述1年到5年的產品策略方向,基本上以「粗略時間」為區間,規劃的「產品願景的策略方向」。再詳細的內容與時程就會成為「Release Plan」而非「Product Roadmap」。若欲知詳情可以看參考下列文章。

PRD 產品需求文件,描述的是產品功能規格與實現方式。

規格文件!那就是產品誕生出來的組成要素與緣由。千萬別問要寫得多細節或多粗略,摸摸你的良心,拿捏你的時間,這真沒有標準答案。

太抽象了嗎?想像你要跟朋友描述一杯咖啡製作內容。你可以說

  • Step1: 喔,它包含了咖啡豆、熱水。

(等等…這不是廢話嗎,於是你又補充了)

  • Step2 這回韻的淺培咖啡,帶有回運的柑橘香,喝完不傷胃又能體會多層次的味道。

(嗯,好像又多瞭解點,所以呢,於是你又多補充)

  • Step3: : 這耶加雪非的咖啡豆產自衣索比亞,我們用92度C沖泡而成。
Image for post
Image for post

在使用前後,需要知道的原則 — 溝通、歷史紀錄、自我保護

溝通、溝通、溝通。認清楚誰是Stakeholder (利害關係人),他們需要什麼,為何需要,以及想要達到什麼目的

設計人員、測試人員、開發人員,每個角色在乎的重點不一樣,而組織中的分工怎麼進行,大家如何推動產品往前進,才是重點!如果為了寫文件造成開發失焦、產品延後上市、錯估使用者需求,那才是本末倒置。

  • 寫得太粗略,沒人看得懂,甚至連自己都要消化。
  • 寫得太詳盡,沒人會想看,光找重點就要花費一番功夫。

但真的是這樣嗎?

  • 粗略,是為了建立索引,一眼望去找到想看的特定內容。
  • 詳細,是為了記錄細節,過幾個月後,每個角色都能「回憶」起製作要素與起因。設計師要的是目的、功能、資訊;工程師要的是畫面、流程、實現方法;測試員要的是功能與Bug之間的界線,什麼是該被定義的。

始於溝通,終於溝通。文件是多方向的理解與更新,不會有最詳細的文件,也不會有最完美的文件。

Image for post
Image for post

使用、使用、使用。用什麼呈現方式不是重點,重點是真的有被派上用場

到底該用WORD? PPT? EXCEL? 還是用線上工具? 又或是不同文件怎麼整合?

我們該重視的是什麼?應該是內容與協作吧!既然如此,應該朝向大家都看得懂、啃得下去、願意去看的方向。格式固然重要,但有時當所有內容都定義完成,要全部翻新「格式」與「文件呈現方式」時,那可是大工程,中間的時間不但不能去做日常產品開發,更有可能最後成效不如預期。除非…找新人做或是加班製作。

精細規劃寫的多麽完美,沒人看,或是敷衍地看有什麼用?即使再怎麼道德勸說,不是每個人都願意說出「不願意使用的原因」。

視優先程度更新文件格式與呈現方式,有人看、省時間的協作,比自以為的完美呈現有有用。

歷史紀錄與自我保護:何時撰寫,誰該撰寫,該如何分工比較好

最常遇到的問題:「不是啊!這干我什麼事情,我負責開發/設計就好,PM不就是為了產生文件而存在的嗎」、「你開的規格你最瞭解,不是你寫那會是誰寫啊」。

有的PM甚至要寫技術文件,但有的又會有專項的工程師自行撰寫與相互協調,這就看組織分工的藝術。至此可以先拆分幾個環節參考。

平行的協作模式

  • 一人撰寫,一人負責。
  • 一人撰寫,一人審核。
  • 共同撰寫,共同審核。

垂直的協作模式

  • 設計/開發文件放在不同檔案:達到即時更新,但必須參考各樣的文件屬性。(例如Zeplin, Database Model, API doc, Function list, Flow chart)
  • 設計/開發文件放在相同檔案:格式不符合,必須額外再複製過去。未來更新必須確切保持「一致性」。

踢皮球大賽不好玩,PM跳出來玩政治議題的同時,把各自的遊戲規則講清楚

Image for post
Image for post

個人撰寫經驗

以下簡易分享兩個個人習慣,但這就未必通用於每個組織,必須隨著當下文化而調整。

建目錄、設編號:

如同「圖書管理系統標籤」、「資訊架構的階層設計」,都有助於我們在查找資料時更有效率,這也是為了在不同跨文件格式時,很好的索引。

Image for post
Image for post
source: PIXNET

拆用途、建連結

適合Roadmap, Flowchart, Mockup製作的文件各有不同,分別可能有PPT, Draw.io, Sketch/Zeplin。當每個各自的負責人皆有其團隊時,要把做好的文件「再度」統合又是大工程,那可以參考用網頁連結或是文件連結方式,可以達到幾個效果

  • 好分工:各自團隊各自負責。
  • 即時性:修改時能更最快速完成,不用再去查找且又重新copy-paste。

當然也會有缺點

  • 太多不同格式文件,無法一站式完成。
  • 當某個工具不再適用,如何轉移。


結論

溝通與使用、功能歷史紀錄、自我保護。這三者都是我們撰寫PRD的重要目的

.

Tian • 塵思產品人

產品思維、閱讀見解、生活創作

Tian

Written by

Tian

Someone who loves technology, design, business trend. To be a well-rounded person. Mail: tianchen.tw@gmail.com

Tian • 塵思產品人

You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.

Tian

Written by

Tian

Someone who loves technology, design, business trend. To be a well-rounded person. Mail: tianchen.tw@gmail.com

Tian • 塵思產品人

You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store