前言
會想寫這個題目，是因為先前和朋友聊天，覺得他們都對數位產品經理 （digital product manager） 的工作內容很感興趣。本文是根據我先前在美國某大型券商交易網站擔任產品經理 (PM) 的親身經歷寫成。
背景
- 產品名稱：新「帳戶結餘」功能
公司大約在17個月前決定重新設計「帳戶結餘」，並且將這個產品／專案交付給我。除了翻新這項公司交易網站內的重要功能外，我同時也負責帳戶「庫存證券」功能的日常維護工作。「庫存證券」功能網頁位居這個網站的流量之冠，「帳戶結餘」也排在前15名。
- 產品預定發表日期：8月26日（星期三）
我的開發團隊是一個非典型的敏捷產品團隊 (Agile product team)，大多數成員都位於不同的城市：我在舊金山的公司總部，程式設計工程師領導人 (Tech Lead) 和軟體測試工程師領導人 (QA Lead) 在德州奧斯汀，所有程式和QA工程師（各五名）在印度，使用者介面 (UI) 設計師則在芝加哥。就我所知，美國某些大型金融服務公司的產品開發團隊，也是以類似的遠距方式運作，例如Wells Fargo富國銀行。
正文
時間快轉約一個半月 — 我的 7月14日（星期二）
- 上午6點半 — 離家等候跨灣巴士進舊金山上班
通常我會在車上用平板電腦讀Kindle電子書、看新聞，或聽聽有聲書。搭公車上下班的通勤時間，一般我都用來吸收PM及其他新知，或是閉眼冥想休息。
- 上午7點半 — 進辦公室，在吃早餐的同時對QA前一天發現的軟體缺陷 (bug) 逐一進行優先級排序 (prioritization)
在TFS系統裡檢視每一個bug，就它們對使用者可能造成的負面影響核定商業優先級 (business priority)，然後分派給Tech Lead檢查成因並且加以修正。
當bug內容比較複雜，或是我無法在測試網站內重現 (reproduce) 某些bug時，通常我會用電話或公司內部通訊軟體與奧斯汀的QA Lead討論，然後才做優先級排序。
此外，我自己的習慣是在TFS的產品待辦清單 (product backlog) 裡將使用者故事 (user story) 由上往下按照優先級排列，然後把每個user story下面找到的bug也一樣自上而下依優先級排序。
這樣整個產品團隊在每個為期兩周的工作週期 (sprint) 裡，實際執行每項產品開發任務時，就有明確的目標依循。成員對哪些產品功能最重要，務必優先完成，以及哪些問題最嚴重，需要優先解決，隨時都會有清楚的概念。
我認為「迅速釐定工作的優先順序」是產品經理最重要的技能之一。因為外在環境隨時在變，資源永遠不夠。有了這項能力PM才能在遇到困難時立刻反應，調整產品待辦清單，化危機為轉機。
我時常說，相較於以往的「瀑布式開發」 (waterfall method ology) ，這正是「敏捷產品管理的美麗之處」 (The beauty of Agile)。
- 上午8點 — 第一次瀏覽與回覆電郵
無可諱言，在大公司上班的一個特徵，就是每天得收一狗票電郵。個人的經驗是，如果可能，最好限制自己每天收發電郵的時間，並且控制次數在三次以內，這樣可以大幅提高工作效率。
附帶一提，我加入這公司初期時常在請了兩、三個禮拜假之後，發現信箱裡積了幾百封電郵。剛開始我還真的會花一、兩天時間，回去閱讀每一封，深怕遺漏了重要訊息。
但成為老鳥之後，我找到了更好的解決之道，第一放假前就先在Outlook裡設定好「不在辦公室通知」(out of office notification)，昭告所有人我正在休假中，無法在假期裡處理公務，並附上職務代理人聯絡方式。第二、收假後基本上不去在意那些先前積下的電郵。因為若真的是緊急事項，應該早在之前就已經被別人解決了；至於那些不迫切、但卻重要的電郵，寄件人若未得回覆通常也會再回來follow up。
- 上午8點半 — 檢查過去一周的網站使用者問卷結果
這是我每周了解使用者最新需求和回饋的固定方式。本來我都在星期一做這事，但昨天有EVP大老闆的兩個小時季會，所以拖到今天。
除了網路問卷和每月固定從客服部門轉來的相關CRM案例之外，我還會視情況不定期採用焦點訪談、系統測試等其他方式，了解使用者的其他需求及痛點 (pain point) 所在，這也是所有產品經理最關鍵的任務之一。
- 上午9點 — 和客戶經驗 (Client Experience) 及行銷部門開會，討論一個多月後的產品發表及行銷計畫
會議內容包括各種不同宣傳管道的利弊分析，以及預定使用的實際文案等。這類會議說明了產品經理的另一個的重要職能，那就是確實扮演產品的福音傳播者 (evangelist)，宣導與溝通產品的願景，並回答來自公司內外所有相關利害關係人 (stakeholders) 的問題。
- 上午10點 — 以電郵送出先前 9點的會議記錄摘要給所有與會人；第二次閱讀及回覆電郵
因為經費有限，公司並未指派專案經理 (project manager) 給我們這個產品團隊。不過好歹自己是PMP®（國際專案管理師）出身，所以像會議紀錄、追蹤任務進度這些基本工作，我跳下來做也是非常OK的。
產品經理美其名是產品的CEO，但其實並沒有任何真正的下屬可供使喚或是授權。因此在產品發表前，一個稱職的PM必須可以隨時接手那些沒有其他人願意做、或能夠做的任務。不排斥在任何情況下校長兼撞鐘，只求達成最終目標、成功推出產品的積極心態，對PM來說非常重要。
- 上午11點 — 準備下午的工作週期規劃會議 (sprint planning)，調整產品待辦清單，新增、修改或撰寫之後幾個sprint的 user story，同時大略檢視產品發表計畫 (release plan)
在敏捷產品開發的規劃層級裡，由上而下分別是產品願景 (product vision)、產品發展藍圖 (product road map)、 產品發表計畫、工作週期計畫 (sprint plan)，以及每日立會 (daily standup/scrum)。這五者當中，愈往上愈是屬於戰略層面的規劃工具，愈往下則愈是戰術層面的執行工作。
根據個人這些年的經驗，我在不同規模的公司服務時，也採用不同的方式來撰寫user story。
先前在這個大型券商上班時，我的user story都儘量寫得比較詳細。這是因為團隊成員都在不同的時區，相互溝通交流並不方便，較完整的user story可以減少不必要的疑惑，以及往來問答時間。
我現在服務的公司所有人都在同一層樓，而且是一個規模小得多的產品團隊，所以我的 user story 就比較簡短。因為我時常有機會和整個團隊面對面溝通、發想產品概念，然後視需要機動修正商業需求及user story內容。
- 中午12點半 — 跟其他PM午餐
除了會議、電郵等正式溝通管道之外，共進午餐和茶水間閒談這些非正式交流，也是我和其他PM用以交換訊息與工作上問題的重要工具。
- 下午1點半 — 參加今天合併舉行的每日立會 + 工作週期規劃會議
每日立會(standup meeting)的目的，是讓產品開發團隊每天在固定的時間和地點，以快速有效率的形式交流任務進度，以提早發現可能的阻礙。
我們公司的產品開發工作週期 (sprint) 是兩周，在每個sprint開始前一天舉行的工作週期規劃會議，顧名思義是針對未來兩個星期的工作做規劃，產品團隊在會中檢視並確認要執行的user story。
一般我都會在這個規劃會議前，把未來兩、三個sprint 裡可能進行開發的user story，以及相應的商業需求準備好，這樣才不會因為臨時發現的外在阻礙 (external dependencies/blockers)，導致沒有足夠的user story可以選擇。
敏捷開發流程裡的另一個重頭戲，是待辦清單精煉會議 (backlog refinement)。我們選擇在工作週期規劃會議的前一周做待辦清單精煉，且此事較為耗時。不過通常團隊在待辦清單精煉上花愈久時間將商業需求規定討論得愈清楚、可能的解決方案設想得愈周全，以及可能遇到的困難分析得愈仔細，等到sprint正式開始以後，工程師們寫程式的效能就愈高 ，所以先前所花的時間是相當值得的投資。
註：為了避免同一批人在一天內開太多次電話會議，我的產品團隊先前開會決定，凡是在有工作週期規劃會議或待辦清單精煉會議的日子裡，就將每日立會合併舉行，以節省大家的時間。
- 下午2點半 — 和奧斯汀的Tech 及 QA lead，以及芝加哥的UI設計師，以電話會議討論某個user story裡困難度較高的功能
我們打算做的「可客製化帳戶結餘模組」，是這個網站以前從來沒有提供過的功能，再加上產品商業規定較為複雜，對使用者介面上的要求也較高，所以在上週的待辦清單精煉會議裡，團隊決定針對這個功能個別做研究，然後另外開會討論。
- 下午3點 — 和「帳戶」功能群產品主管討論工作上的問題，如需要的資源、遇到的困難等
產品開發過程中的向上、向外管理很重要，特別是對組織龐大的公司而言。因為通常網站新產品的設計都涉及許多後端資料庫、舊有系統 (legacy system) 的相關改動。而這些專案關鍵路徑 (critical path) 上的工作若未事先妥善規劃，通常曠日費時。
因此和產品部門主管，甚至是主管的主管定期溝通來確保開發資源，並且得到他們的協助以清除產品開發外在阻礙，就格外重要。
- 下午3點半 — 今日第三次回覆電郵，大略規劃隔天的工作（三項必須／想要完成的事）
通常我一進辦公室後就非常忙，一整天會在不知不覺中過去。所以我設法在前一天下班前就計劃好隔天最重要的三個工作目標，以確保到時真正重要的任務能得到足夠的注意力。
-
下午4點 — 趕著去搭舊金山跨灣巴士，接小孩回家
-
晚上9點半 — 和印度的程式及QA工程師們進行每月例行的電話會議
就我所知，在我們部門裡的十多個產品經理中，只有我和另一個PM定期舉行這樣的遠距會議。其他PM通常都只和奧斯汀的Tech及QA Lead溝通，與印度的程式和QA工程師團隊則沒有太多交流。
我自己覺得開這會除了可以和印度的團隊成員搏感情，也有助他們對整個產品或專案「既見樹又見林」，而不只是每天埋首於自己所寫或所測試的一小部分程式碼而已，這對提升整個團隊的士氣很有幫助。
《數位時代》長期徵稿，針對時事科技議題，需要您的獨特觀點，歡迎各類專業人士來稿一起交流。投稿請寄edit@bnext.com.tw，文長至少800字，請附上個人100字內簡介，文章若採用將經編輯潤飾，如需改標會與您討論。
（觀點文章呈現多元意見，不代表《數位時代》的立場。）
