圖、文/ UX 四神湯 Shandy Tsai
上次的文章，我們瞭解了產品開發的流程，許多讀者詢問什麼是產品規格，以及怎麼寫出有效的大綱。為了更深入了解產品開發流程，此文章會說明：
- 產品規格簡介 Product Spec Introduction
- 產品規格包含的內容 Product Spec Guideline
- 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，在與不同團隊溝通時的建議：
- 「非常清楚」產品目的與使用者的需求
我們是產品經理，我們必須是最了解產品內容的人。這個新開發的項目要解決使用者的什麼困難、用什麼方法解決、評估這項目的成功與否的指標，我們必須牢記在心。不論是設計師、專案經理、工程團隊、行銷部門、銷售人員詢問你，你都必須清楚堅定的表達。 - 團隊合作溝通、尊重他人想法
開發一個項目並不是產品經理說了就算，衝突是無可避免的。設計師的立場是為了最佳化使用者經驗；工程部門的想法是用最快的時間、最少的資源把功能開發出來，這兩者很少情況會是完全相同。所以，除了清楚產品內容與目的，我們也必須聆聽不同部門的看法，有時候他們往往有很不錯的想法建議可以作為參考。同時也要記得，你是做最終決定的人，千萬不要搖擺不定、猶豫不決，這會讓人失去對你專業能力的信任。 - 邏輯、邏輯，還是邏輯
由於產品很大一部分是跟工程團隊合作，我們必須有邏輯性的表達、說服及溝通。如果不想要任工程部門宰割的話，請務必非常清楚了解產品邏輯『工程部門跟我說做不到，要花太多資源與時間』，這是 PM 常面臨到的問題，難道我們就這麼妥協了嗎？在此舉兩個工作實例，是我與工程部門溝通的方式：
第一，用數字說話：「根據 5 位使用者的訪談，5 位使用者都選擇設計 A；簡化版本的設計 B，雖然容易達成，但這 5 位使用者都表達不明白設計 B 的目的。另外，我們已做了 A/B Testing，85% 的使用者選擇設計 A。假如我們推出設計 B，不但會讓使用者困惑、離開了我們的產品，也會造成客服極大的工作量，因此，我們應該追求設計 A。」雖然我們最後因資源的考量選擇先開發設計 B，但在溝通的過程中，我們的工程師更加了解設計背後的考量，也更重視我的意見。
第二，實際行動：詢問更有經驗的工程師，這樣的設計該怎麼實現，或是上網查詢，可以實踐的方法。有一次工程師跟我說他不會做這樣的功能，於是我去詢問資深的工程師，另外也找到網路資源，我跟他說「這個問題是可以解決的，我給你以下的 links，都有解決方式；另外，XXX 是資深的前端工程師，你有問題都可以詢問他。」大部分的人其實都怕麻煩，假如你能找到對的人、對的資源協助開發，可以讓工程團隊對你更加信服。
希望大家看完這篇，能夠更加了解產品規格 Product Spec 的內容與重要性，有什麼問題也歡迎詢問。
