產品心得：從不確定到確定的專案 kick-off 之路
前陣子領到自己 team 相關的 Q4 公司目標，目標是把一個系統，假定這是個購物商場系統，12 月底要拼上線。想想專案滿大的，牽涉內部跨部門資源、事前規劃對外溝通，林林總總將近一半的同事都會參與到，一時之間不知道怎麼 kick-off，陷入一陣焦躁。
所幸在中山書街花了點時間穿梭，找到的《專案管理：玩一場從不確定到確定的遊戲》給了自己幾道曙光。看書真好，以後有需要就多看書。
專案必備 mindset：變是常態，改是必然
特別提到專案管理的恆常心態，是因為發現自己焦躁的出處，是想像未能向同事呈現精準方向與時程的專案架構，會讓自己看起來不專業。然而，專案本來就可能隨著公司發展而轉向，時程也可能因為對設計開發期程的誤判而變動。
Kick-off 會議中，專案架構就是用來改的——就像小組作業中的非同步合作，總要有個人先拉出簡報的骨幹，再由大家去填肉、調整而成。
「沒有人有時間去梳理出整個專案的主軸，你就是那個沒有人。」調整到這樣的心態後，能更坦然地去檢視專案範圍，事前向關係人討教，先盡個人之力拉好骨幹後，進到 kick-off 會議來面對更多的修修改改。
到這裡，第一次籌備如此規模專案的我，被書裡這句話深深鼓勵到：
不是因為具備能力才展開專案，是因為展開專案才開始具備能力
專案目標回扣商業目標，由時間、目標、數字三者構成
專案只是專案，它是用來達成某個商業／公司目標的手段。我回去看了下 Q4 的商業目標，舉例來說，是「年底線上通路月營業額達 100 萬」。
要達到月營業額的目標，勢必要留有上線後要導流更多人去賣場、吸引更多人結單，甚至是實驗調整的時間，那麼，專案上線只是這條偉大航道的一個里程碑，上線時間壓在 Q4 末公司會哭。
而專案之所以是專案，是因為它有被期待終結的期限，不然叫許願。所以，我加入了時間、數字（數出哪幾個管道也算），把專案目標從「上線購物商場系統」改寫成「m 月 d 日要將雙平台購物商場系統推上正式環境」。
藉由關係人的擔憂，拉出專案不同時間點下的 HMW
由於專案真的有點大，以我負責內部產品的職位視角，不一定能第一時間想像到 marketing team、CS team 實際上會需要如何跟使用者溝通，因此事前募集了一些他們的 concern，結果是五花八門：
例 1：新的系統會是雙平台同時上線還是 iOS 先行？
→ 單純的疑問
例 2：線上商場會不會用輪播比單張大圖更吸引點擊？
→ 可能是個陷阱題，如果業界沒有普遍的偏好，這類問題上線前沒有人能將其證實為真（我在這次決定先忽略這種題型，先以我們的最佳解做就好）
例 3：這一波的宣傳策略是「給你滿滿的大平台」
→ 在別的關係人會議中已有初步決策，寫出來作為提醒
例 4：要記得在上線前就在結帳各頁埋 event
→ 基於過去經驗所列出的待辦事項
我打開 Figma，在專案拉出縱向的時間軸，粗分為事前產品籌備、事中實作上架、事後分析計畫。橫向則用 HMW 把每個時間點、關係人在乎的事給轉化出來：
例 1：新的系統會是分平台上線還是 iOS 先行？
→ 若上線時間不同，我們如何讓 Android 使用者願意耐心等待？
要記得在上線前就在結帳各頁埋 event
→ 我們如何即時、精確地計算商業目標的達成率？
加總起來，每個階段都列了 3–4 個 HMW，但總算幫助我們了解專案各個時期值得關注的問題，也因此能整理出相應的 to-dos，進而在 kick-off 會議中看到專案的 6–7 成全貌。
Fail early，追求專案的最小可用
回歸到最初的焦躁，是擔心自己召開的會議、呈現的內容不專業。書裡輕輕推了一把，說專案本身也應該是敏捷開發，早點試錯，早點向關係人／主管簡單 present 過，了解對方與自己的期望落差。
如此對方既對專案架構及 kick-off 會議的內容有所掌握，也留下在會議前弭平期望落差的餘裕。是個很棒的舉動、但有時自己會卡住、擔心打擾到他人而作罷，要常常提醒自己才行。
就這樣，宣布這次看書急救、有效！之後應該會想再廣泛地攝取產品知識，預計會讀《產品路線圖：從革新到蛻變》。
