profile

Soking

Soking 來信:產品需求文件 PRD 的應用難題

Published about 2 months ago • 1 min read

哈囉,朋友

今天想與你聊聊產品需求文件(Product Requirement Document,簡稱 PRD)這是一個軟體開發工作中的「房間裡的大象」,大家都知道有這麼一回事,但這件事情太痛苦了,以致於大多數情況下沒什麼好印象。

其實我是一個很喜歡寫文件的人,一方面是我不信任自己的記憶力,另一方面是透過寫作可以更深度的思考,所以通常我會盡可能的建立各式各樣文件,這不是為了別人而寫,而是為了與其他人溝通的過程,我可以幫自己準備好。

但坦白說,在我擔任產品經理的時期,即使以我自己的標準來看,我的產品需求文件 PRD 還是經常處於一塌糊塗的狀態。

這是因為擔任產品經理的時候,最重要的職責與大多數的時間,都花在溝通上面,換句話說就是開不完的會議。

在一整天的會議上,要處理客戶意見、蒐集跨部門需求、整合利害關係人意見、為懸而未決的事項找出推進辦法、調整排程與資源、對齊中短期目標、提議下階段的產品策略等等等一萬件大小事。

往往到了晚上八九點的時候,好不容易有獨處時間,才能坐下來打開軟體,將各式各樣的想法梳理寫成文件。

但是人的認知資源是有限的,一整天的會議消耗下來,晚上寫文件的時候狀態處於低谷,此時產出的文件品質可想而知極度糟糕。

接手 PRD 的設計師或工程師打開文件一看,自然會頭痛萬分,因為文件中會有各種的漏洞與矛盾沒有仔細評估過,甚至有些功能機制部分描述的很徹底,有些部分乾脆只有標題以及兩三句描述。

到頭來,與其閱讀這麼一份不知道可不可信的 PRD 文件,設計師與工程師會覺得還不如把 PM 抓來開會,討論清楚才開始工作,這樣才不會浪費一堆時間在沒有用的地方。

近日與朋友討論到關於 PRD 的議題之後,我也在個人臉書上發起了游擊訪談,蒐集到不少同業朋友的回饋,大家紛紛的與我分享他們在工作上關於 PRD 的痛苦經驗,這包括了:

  • 文件可讀性差,用字語意不清或排版令閱讀體驗不舒適
  • 文件冗長,難以掌握重點
  • 不同的人各行其是,一間公司有 N 種版本的 PRD,每次閱讀都很痛苦
  • 外行人套用 PRD 模版改寫,每個段落都在換句話說
  • 文件內容偏離現狀,不具參考價值
  • 即使花費心力撰寫,開發時依然發現許多沒有考慮清楚的地方,一直修改
  • 開發相關的文件散落在各處,新功能與舊檔案連動,經常漏掉東西
  • 不確定什麼情況要用什麼格式或流程圖來表達
  • 沒有寫出驗收情境,對交付沒有產生實用意義
  • 寫了對工程師有用的驗收情境,但老闆看不懂

除了負面的痛苦經驗之外,有軟體開發經驗的朋友們也分享了許多覺得 PRD 有積極意義的方面,這包括了:

  1. 有明確的依據來開發
  2. 討論比較容易對焦
  3. 產品團隊知識資產管理

不論是設計師或者工程師,如果沒有明確的需求依據,就很難規劃工作項目,更何況經常都要評估時程與難度,這個時候有一份需求描述明確的文件在,可以幫助開發團隊迅速對齊目標,有足夠清楚的情境,用來判斷工作的範圍,發想合理的解決方案。

軟體需求的溝通經常是討論很抽象或複雜邏輯的議題,這個時候如果有一目了然的可視化文件來輔助討論,能夠幫助開發團隊迅速對焦,也能降低非技術人員參與討論的難度。

專業工作者經常熱衷於解決問題,但也很容易迷失在細節當中。

產品發展的過程除了「為什麼要做」的事情之外,那些「經過思考決定不做」的事情也很重要。

有時候當初決定不做的事,只是因為階段性的考量,等到條件成熟、水到渠成的那天就會納入產品路線當中,但如果不記得這樣的理由,以訛傳訛形成了錯誤的認知,可能後面反而變成「一開始就說好不做,為什麼現在又要考慮」的矛盾問題。

因此從積極意義的面向來看,PRD 文件所扮演的角色都是為了輔助溝通,讓開發團隊能提昇確定性,快速聚焦目標,以及能了解過去的決策經過哪些評估。

回到我自己的經驗中,我是在開始接手大型專案,需要同時跟三、四個不同團隊一起協作的情境中,才意識到自己需要跟超多人時時對齊認知。

如果每個人有一個問題就跑來打斷我一次作討論,那我一整天不就什麼事情都不用幹了?

但如果身為產品經理又找不到人,沒辦法解決開發團隊的疑惑,一樣也會耽擱進度。

這個時候花費時間維護 PRD 文件的好處就凸顯了出來,當我把已經達成共識的部分有條理、視覺化的記錄下來,往後每次有人詢問,我就可以快速丟出線上連結,告知對方他需要的情報怎麼尋找。

如果這樣不能解決對方的問題,那可能是發現了新問題,那就應該列為追蹤事項找時間解決。

如果文件上的描述與現況不符合,那通常是兩種情形,一個是我自己假掰寫了太詳細的規格,以致於成為幻想文,等到有人要實作才發現不合理。

另一個是需求已經變更,但我沒有更新到被影響的其他部分,這就屬於要找時間局部更新的例行巡邏事項。

需求文件的更新維護也是需求變動的成本之一,只是我們經常貪圖方便而忽略這件工作,就像煮完飯之後廚房髒亂放著不管,這些代價只是當下可以逃避,但依然存在。

舉個例子,例如你招待一大群人去餐廳宴會請客,但點餐時店員完全不作任何記錄,也沒有給你任何菜單作為討論依據,往往你點了某個菜,過了十幾分鐘才出來告知你沒辦法作,要換一個方式。

大家吃吃喝喝一面改菜單,一片混亂之後經過兩三個小時用餐結束,才發現你點了八道菜卻來了十二道,然後大部分的菜都跟你一開始點的不一樣。

你付錢的時候會覺得滿肚子氣,廚房也覺得委屈,認為是經過討論才發生的結果。

軟體開發過程的時間跨度少則數個月,多則以年為單位,許多利害關係人也不在開發團隊裡面,這意味著與開發團隊討論需求時,只是把他們從百忙之中撈出來諮詢,此時的溝通對於開發團隊來說,難度是很高的。

開發團隊會發現每一件事情都要從很基礎的概念說起,而利害關係人也會覺得很多議題都去脈絡化,搞不懂為什麼要討論,就被迫要做出選擇,因此防衛心態就會迅速升起。

像這類情境,我們需要的就是可視化的資料,用來幫助溝通的雙方降低認知落差。

最後簡單作個結論,關於 PRD 文件的難題與應用情境如下:

  • 重視文件可讀性,要讓人易懂、好查找、好理解,才會有人願意花時間讀
  • 維護與管理,PRD 的維護也是開發成本之一,忽視只是延後代償
  • 產品發展路線,幫助團隊記得決策歷程
  • 溝通可視化,輔助與開發團隊內外溝通時可以迅速對焦,降低認知落差

如果你對於產品需求文件 PRD 有什麼希望討論的議題,歡迎來信,我們可以一起聊聊。

by Soking

Soking

千綺創意設計 Co-Founder / 產品設計總監,目前經營軟體領域的體驗設計顧問公司,也從事 UX 教學,喜歡以工作坊形式,引導你體驗 UX 領域的專業知識。 工作聯絡:service@soking.cc

Read more from Soking

A 提供某種資訊給 B 在特定情境下使用,軟體服務往往長成這副德性。 B2B 軟體的設計情境中,通常可以找到對應領域的專家,與專家一起協作進行知識萃取,將任務步驟解析出來。 by Soking

4 days ago • 1 min read

PRD 模版可以照填就好?」、「我又不會寫程式,要怎麼樣才能讓工程師看懂?」等等。 SPEC 規格文件,就像是在寫一道菜的食譜,你要描述輸入哪些原料、使用什麼工具、按照什麼順序、注意哪些狀況,最後輸出什麼結果。 UX writing 撰寫 CTA 時的參考。 2024/2/12」,最大的問題在於別人可能猜測不出來你指的是什麼日期? 2024/2/12」 更好的寫法是「發佈日期:2024/2/12」 spec 就像在寫食譜,因此順序很重要。 Edge case),就是那些發生概率低,但可能造成機制出問題的事情。 9點之前不能預約」 9點」並不是鐵律。 9點之前不能預約」(快速實現,但不容易改動) 8 個 SPEC 書寫原則分享給你,也歡迎你轉寄分享給其他你覺得需要的朋友。 by Soking

18 days ago • 1 min read
Share this post