什麼是產品規格?給 UX 背景 PM 的注意事項

0

圖、文/ UX 四神湯 Shandy Tsai

上次的文章,我們瞭解了產品開發的流程,許多讀者詢問什麼是產品規格,以及怎麼寫出有效的大綱。為了更深入了解產品開發流程,此文章會說明:

  1. 產品規格簡介 Product Spec Introduction
  2. 產品規格包含的內容 Product Spec Guideline
  3. UX 背景的 PM 應注意事項 Transitioning from UX to Product Management

▲ 一個好的產品規格,讓團隊有一致的目標,減少不必要的溝通,如同讓產品團隊都能吃到一樣美味的壽司!

1. 產品規格簡介 Product Spec Introduction

What 什麼是產品規格

產品規格是用來說明一個新項目的大綱,包含這個 feature 解決什麼問題、主要用戶、解決方法、設計說明等。

例如:今天要幫小明辦生日派對,召集了一群好朋友,而這份活動大綱必須讓每個人都了解生日派對的內容策劃、時間及地點等。

Who 誰負責撰寫產品規格?誰會看到此文件?

負責此項目開發的產品經理負責編輯、完成此文件。

整個產品項目團隊都會看過此文件,包含產品經理、設計師、專案經理以及工程團隊。

When 什麼時候會用到產品規格?

項目開發期間,都會使用到產品規格。

在決定要開發什麼新項目後,產品經理會完成產品規格;設計師根據此文件進行設計;工程部門動工前,會看產品規格來了解此項目的主旨。理想狀況下產品規格是固定不變的,但實際上隨時會因為內外部需求、資源限制、團隊變動而必須即時更新。

How 產品規格為什麼重要?適合什麼團隊

一個好的產品規格,可以減少不必要的溝通、讓人一目了然地理解此項目的需求及目的。

產品規格如同項目開發的房子架構。要建造一個實用又美觀的房子,必須有清楚的說明、堅固的結構,建設團隊才能了解更有效率的運作。

基本上,個人認為每個團隊最好都要有產品規格,不論團隊的大小,但詳細程度皆可斟酌。為什麼呢?

  • 小團隊:雖然團隊人數少,溝通相對容易。不過產品規格像是一個操場的跑道,你希望團隊能夠跑得快、跑得穩健,但不希望團隊跑出了跑道,這樣不僅浪費體力、也增加了記錄時間。
  • 大團隊:人數多,溝通更容易誤解,有一個清楚的產品規格,在團隊交接時,能夠依此文件作為依據。
  • 遠距合作的團隊:由於有地理位置、時間的差異,當這些限制讓溝通變得更加困難時,更需要此文件作為參考。

▲ 產品規格如同房子的架構、食譜,定義基本項目架構,產品團隊才能依此進行設計及開發

2. 產品規格包含的內容 Product Spec Guideline

首先,我們必須注意的是,「產品規格的目的是讓產品團隊有能夠清楚理解此項目目的、有共識。」

由於產品團隊的每個人都會看到這份文件,這代表什麼呢?

千千萬萬記住:不要寫的太詳細!!!這只是大綱,只是大綱,只是大綱

我的意思是說,不論是在設計、工程方面,都不要描寫地過於繁瑣,因為這份文件只是大綱(再度強調)。如果要再深入,我們會連結到 Prototype 的 link(Sketch, Invision, Zeplin, etc.),以及 Project management 的link(JIRA, github, etc.),去闡述設計的細節,以及工程的步驟,讓負責的設計師與工程師去鑽研詳細內容。

至於要用什麼軟體,我們公司很簡單就用 Google Doc 記錄,只要能夠達到讓團隊裡的每個人都理解就好。像我自己覺得如果有些觀念用文字難敘述,我會作圖說明,因為圖像相對文字更容易吸收。

▲ 產品規格基本架構,目的是讓產品團隊了解此項目大綱,細節則會連結到其他輔助軟體

以下產品規格架構,是 Demandforce 內部定義的,每個公司不近相同,可以斟酌參考。基本上我們主要分成五大部分:

2.1 One-page summary 一頁大綱

字面上而言,就是能讓人看這一頁,就可以基本掌握此項目的內容。或是開發中途時、結束後,再回頭看這一頁,就可以聯想到是那一個項目。所以必需切中要點、簡短清楚。(不要冗言贅詞就對了!)

  • Problem Statement 問題定義
    我們發現了什麼問題,盡量以使用者的角度出發,內容必須 Human 人性、Simple 簡單、Straightforward直白。
  • Solution 解決方法
    我們怎麼解決這問題,用什麼方法,基本架構及機制。
  • Target Customer 目標使用者
    此項目主要針對的使用者。
  • Essentials 基本要素(表格形式)
    負責聯絡人:產品經理、設計師、專案經理。
    時程追蹤:文件建立時間、著手開發時間、預計完成時間、實際完成時間。

2.2 Specification 基本要件

這裡開始帶到項目的基本需求條件,及判斷成功的指標。

  • Requirements 元素
    這項目包括的基本條件,Feature 內至少要涵括的功能。例如:通訊軟件必須包含編輯對話、傳送對話、觀看聯絡人、編輯聯絡人
  • Visual Representation 重點設計(建議使用一張圖就好)
    一張最代表性的圖,這目的只是讓人一目了然。可以讓人一看就覺得「喔!原來如此!」,那你就成功了!
  • Success Criteria 成功指標(必須數據化)
    必須定義一個實際指標,給一個明確的數字,什麼樣的數據可以評斷這項目成功與否,在哪裡可以追蹤到。
    例如:點擊 App 的次數、傳送對話的次數、顧客滿意度

2.3 Functionality 功能性

這部分就再深入點解說,但不要太細節,必須有連結到 prototype, project management 的 link,讓負責的設計師、工程師可以點進去觀看,連結也必須隨時更新。

  • Overall Flow 整體流程 ( IA Diagram 資訊架構圖)
    頁面與頁面之間的關係、會影響的頁面是什麼。
  • Epics 項目分解(必須有連結到設計、工程細節)
    這大項目裡可以分成幾個最重要的步驟,建議使用 User Story 形式。例如:首頁及對話視窗。

2.4 Go to Market Timeline 時程計畫預計完成時間、實際完成時間

一旦完成了前面的文件內容,這部分會跟專案經理討論預計完成的時間,產品經理也必須記錄實際完成的時間,以方便追蹤與紀錄。
那我們公司主要會討論下列主要時程:

→ Staging 系統環境
→ Production 產品環境
→ Beta 測試使用者
→ Full Availability 全部使用者

2.5 Others 其他(斟酌加入)

其他並不代表不重要,端看各公司需要這產品規格文件到多詳細完整,可以自由加入。就像食譜一樣,你要多加點調味料、或是自己加食材,都沒有硬性規定。基本上可以提及:

  • Known Issues 已知問題
  • Risks / Assumptions 風險、前提假設
  • Additional Files 附加檔案、參考資料
  • For Future Consideration 未來規劃
  • User Pain Points / Goal 使用者痛處、目的
  • Supporting Data 支持數據

▲ 產品規格是一個必須經由討論、即時更新的過程

看到這裡,大家就知道開發一個產品,並不是這麼容易的!寫產品規格也是門很大的學問,而每家公司都有不同的標準架構。

3. UX 背景的 PM 應注意事項 Transitioning from UX to Product Management

最後,想要來聊聊UX背景出身的產品經理,應該注意些什麼事項。

由於我們公司其他兩個 PM,還有我的直屬上司 Director of Product 都是 Software Engineer 背景出身。一開始,我擔心程式設計不足的背景,可能會影響擔任 PM 的職責,但其實只要抱持著正確開放的態度,其實並沒想像中的困難。所以我列了以下三個重點,希望能夠給予 UX、設計背景,甚是是商業背景出身的 PM,在與不同團隊溝通時的建議:

  1. 「非常清楚」產品目的與使用者的需求
    我們是產品經理,我們必須是最了解產品內容的人。
    這個新開發的項目要解決使用者的什麼困難、用什麼方法解決、評估這項目的成功與否的指標,我們必須牢記在心。不論是設計師、專案經理、工程團隊、行銷部門、銷售人員詢問你,你都必須清楚堅定的表達。
  2. 團隊合作溝通、尊重他人想法
    開發一個項目並不是產品經理說了就算
    衝突是無可避免的。設計師的立場是為了最佳化使用者經驗;工程部門的想法是用最快的時間、最少的資源把功能開發出來,這兩者很少情況會是完全相同。所以,除了清楚產品內容與目的,我們也必須聆聽不同部門的看法,有時候他們往往有很不錯的想法建議可以作為參考。同時也要記得,你是做最終決定的人,千萬不要搖擺不定、猶豫不決,這會讓人失去對你專業能力的信任
  3. 邏輯、邏輯,還是邏輯
    由於產品很大一部分是跟工程團隊合作,我們必須有邏輯性的表達、說服及溝通。如果不想要任工程部門宰割的話,請務必非常清楚了解產品邏輯『工程部門跟我說做不到,要花太多資源與時間』,這是 PM 常面臨到的問題,難道我們就這麼妥協了嗎?在此舉兩個工作實例,是我與工程部門溝通的方式:

第一,用數字說話「根據 5 位使用者的訪談,5 位使用者都選擇設計 A;簡化版本的設計 B,雖然容易達成,但這 5 位使用者都表達不明白設計 B 的目的。另外,我們已做了 A/B Testing,85% 的使用者選擇設計 A。假如我們推出設計 B,不但會讓使用者困惑、離開了我們的產品,也會造成客服極大的工作量,因此,我們應該追求設計 A。」雖然我們最後因資源的考量選擇先開發設計 B,但在溝通的過程中,我們的工程師更加了解設計背後的考量,也更重視我的意見。
第二,實際行動詢問更有經驗的工程師,這樣的設計該怎麼實現,或是上網查詢,可以實踐的方法。有一次工程師跟我說他不會做這樣的功能,於是我去詢問資深的工程師,另外也找到網路資源,我跟他說「這個問題是可以解決的,我給你以下的 links,都有解決方式;另外,XXX 是資深的前端工程師,你有問題都可以詢問他。」大部分的人其實都怕麻煩,假如你能找到對的人、對的資源協助開發,可以讓工程團隊對你更加信服。

希望大家看完這篇,能夠更加了解產品規格 Product Spec 的內容與重要性,有什麼問題也歡迎詢問。

▲ 一個完整清楚的 Product Spec,可以讓團隊更有效率的合作!蓋好房子、吃到好吃的壽司!!!

授權來源:UX 四神湯 〈什麼是產品規格?UX背景的PM注意事項〉

Share.

About Author

vide 編輯群

Leave A Reply