這系列文章的命題是：當把產品做完後，不管是已改版多次還是 MVP，只要是產品，永遠有變得更好、持續進步的空間，但要如何改善呢？該從哪裡下手呢？
以下整理了一個概略的產品優化流程，會在接下來的文章中細講每個步驟。
上一篇談到估時，「估時」基本上會發生兩個時間點前後，一是設計稿 and/or PRD 完成後，二是專案 KO 後。至於到底是哪個時間點，仍視各團隊習慣的流程而定，只要專案跑得順，這些步驟或環節都能彈性規定。
如果是規模比較小的專案，或者甚至只是要改個文字或背景色的小任務，有時候可能連設計稿都沒有，直接跟工程師口頭溝通即可，雙方簡單討論後，PM 就能知道這個任務的估時了。
但如果是規模比較大的專案，比如要從零做一個新產品或功能、產品介面要重新設計、後端程式碼要重構等，那通常都會有一個 KO (Kick-Off) meeting——中文似乎較少有對應的專有名詞，硬要說的話就是「專案啟動會議」。
KO meeting 要做些什麼？
KO 的目的是讓團隊知道這個專案的背景脈絡與目標，進而確保大家資訊同步、目標一致，這樣真的有問題時，才有同一個溝通基礎。
也可把 KO 會議想像成是旅行團的說明會，在出發前往異地旅遊前，旅行社會先召集導遊、領隊和團員，讓導遊和領隊跟團員們說明到時候的行程與細節，包括會去哪、看到什麼景點、每天三餐吃什麼、晚上睡哪裡等。
KO 會議也差不多是這樣，每個團隊的流程不同，以下供參：
- PM 開場，說明該專案的執行背景（為什麼要做這個專案）、目標、預計死線、參與人員
- UX 接手，逐一說明 UX flow，有必要時也會對照 UI mockup 一起看
- PM 結尾，向大家說明下一步，比如請設計師修改剛剛討論的地方、請工程師各自估時等
💡 如果是規模更大的案子，或者團隊成員完全沒有合作過，有時也會再開一個 pre KO 會議，先跟大家介紹該專案的背景，並且大致瀏覽 UX flow，請大家先回去各自熟悉每個畫面，等每個人都有基本認知後，再召開正式的 KO 會議。
開發的時候，PM 要幹嘛？
KO meeting 開完了、估時也完成了、PM 也把專案時程抓好了，再來就真的要進入開發了。那這時工程師忙著寫程式碼，PM 要幹嘛呢？
通常一個 PM 手上都會有好幾個專案或產品線在跑，比如產品線 A 是日常維運、B 正準備進開發、C 在收集需求，準備下個階段的迭代、D 正在進行 UX design，所以即使 B 產品線不會佔用 PM 太多時間，但 ACD 仍是很有得忙。
不過，儘管 PM 在開發中專案從主導轉為偏被動的角色，碰到以下情況時，PM 仍需要來解決：
1. 需求變動
比如老闆突然想改文案、主管想改按鈕的顏色、別的部門想要再加一個區塊、某某部門說要提早上線……，需求大大小小、合理與不合理的都有，PM 就要評估是否接受這些改動，以及改動帶來的對應影響（如：設計是否也要改、專案估時是否會隨之異動）。
2. 功能使用邏輯有 bug
明明每次都跟 UX 設計師討論很多次了，也自認已經考量到各種操作情境與邏輯，但每到工程師手上，總是會有一些漏掉的細節……
如果是比較小的，比如錯誤文案漏掉了、點選後要另開視窗還是原地跳轉等這種小細節，UX 設計師在 UX flow 上補充即可；但如果是涉及層面較廣的疏漏，比如某種權限的範圍完全沒有制定、某些限制會造成矛盾的結果等，PM 很可能要花不少時間跟 UX 設計師重新釐清各種細節。
3. 畫面缺漏
如果是在 UI 跟 UX 拆分的團隊，UX 漏掉的話，UI 通常也是跟著漏掉（因為 UI 通常是照著 UX 做），UI 上面有文案寫錯，也很可能是 UX 的版本就已經有錯誤了，總之，一旦畫面有缺漏，通常 UX 和 UI 這兩份設計稿都要一起修改。
4. 功能不可行或太耗時
在功能進入開發階段時，偶爾會收到工程師反映某某功能做不到，或者雖然可以做到，但他覺得太耗時。這時得先回到最初的命題：這個功能要完成什麼事？用戶痛點是什麼？產品目標是什麼？
只要執行方式與這幾個命題並不相悖，要改功能、換成簡單的方式、縮小範圍、甚至砍功能、把該任務移到下個階段，其實都是可行的。
要如何維持開發進度？
之前寫過一篇〈4 個指標+黑箱理論，協助你降低組織管理的成本。讀《葛洛夫給經理人的第一課》〉的讀書心得，裡面提到的「黑箱理論」，其實也適用於 PM 看待一個產品開發的流程。
PM 並非寫程式的那個人，尤其技術力不如工程師專業時，該怎麼做才能確保開發進度能照著預期走呢？以下幾個是我嘗試過也持續在使用的方式：
1. 保持資訊透明且即時更新
在我的現職公司，每個產品線在每週一早上都會有例會，會議內容很簡單，就是讓 PM 最多用 15 分鐘更新上週進度與本週待辦事項，目的是確保大家的資訊對齊，也會讓每個人知道自己這週該完成哪些事情。
但每週更新的頻率仍不算高，一個專案很可能一天之內就會有超多事情要討論，所以一旦碰到上一段提到的任何問題，儘管討論可能都是一對一的（比如 PM 與設計師、設計師與工程師、PM 與工程師），但有了結論或者需要下一步行動之後，建議在所有人的群組裡 tag 相關的人，並且 cc 可能需要知道的人。
舉例來說，PM 和 UX 設計師改動了某個空畫面的文案，那就得在群組通知 UI 設計師更改 mockup，也得讓前端工程師知道這項更動；又或者 PM 和工程師討論把某個過度複雜不好做的功能移到下個階段，那 PM 也得在群組讓主管和 QA 知道，這樣 QA 測試時就可以忽略這部分，主管也會知道功能有異動。
2. 不定時追蹤進度
功能進入開發後，我自己的習慣是：每天早上會打開 JIRA（公司採用的專案管理系統）看一下各個工程師的進度，哪些票完成了、哪些票剛進入實作，如果發現某張票的狀態太久沒動，或者超出當初預期的時間，我就會「關心」一下負責的工程師。
💡 但很重要的是，有時候這種「關心」會給人壓力，畢竟 PM 的角色就是很容易變成「催狂魔」，工程師好像看到 PM 時，都會有一種「好啦好啦我知道我做太慢了，我會趕工！不要催我！！」的畏懼（或不耐）。
尤其我現在所處的工作環境，大家的共通語言是英文，而我們幾乎沒有一個人是英文母語者，為了怕語言表達或理解能力不足而造成誤會，我寧可囉唆一點，追蹤進度時必定會先表明來意，比如我會很直接地說：「我不是要催你，只是想知道進度。如果進度落後，我可以跟主管溝通看看時程，或者看是不是需要找人來幫忙」，而不是只問一句「目前進度如何？」，這恐怕會給對方一種「反正你就是要我趕工嘛」、「你就只是想要知道什麼時候會做完對吧」的感覺。
3. 隨時想好備案
即使進度順利，PM 的口袋裡一定隨時要有一份備用清單，因為意外永遠是突如其來的（這句話蠻廢的，但也沒說錯對吧）。
在每週一的進度會議前，我習慣在前一個工作天（通常是週五）先整理要報告的內容，並且思考：如果接下來這個任務做不到？如果進度突然延誤？如果有人下週臨時請假？……等，並先想個對應的方向，比如先預估影響範圍與相關人士，再提出幾個對應的解決方式，等真的發生時，也才能夠在第一時間跟主管或團隊討論。
💡 對於專案來說，最不幸的意外應該就是「無法達到死線」，也就是專案會延誤上線。若預期會發生這種事，務必在第一時間跟團隊或主管討論解法，比如是要縮減功能、找支援、跟需求端溝通上線時間、加班等。千萬不要等到無法挽回時才臨時抱佛腳，這樣一來累到開發團隊（大家可能真的要瘋狂加班趕進度），二來也會讓需求端對自己的信任度大減。
結語
不知不覺又寫了三千字，這篇主要是想聊聊 PM 在開發過程中要注意哪些事、扮演什麼角色，上面都寫得差不多了，大致上就是把自己想像成是產品的褓姆吧，PM 就是要確保一個產品能平安順利長大、不斷變成更好的狀態。
至於該怎麽做，方法真的很多，每個團隊有不同的默契、每間公司有自己的 DNA，上述的溝通方式不一定適合每個人，只能說是我自己在前公司與現職公司試過，用起來還算有效且順手的，就寫出來記錄一下。
最後，原本想再加一段「實際開發時間跟估時差好多，該怎麼辦？」，但寫完後，覺得放到後面的章節比較適合，所以這篇就先到這裡啦！
