邁向頂尖產品經理 — 簡單紀錄

依照條列的方式記錄下此本工具書的一些重點，細節就不詳述了。

關於產品經理Project Manager

產品經理簡稱PM

產品開發

• 需要有基本的技術知識，以及成本估算、會計財務相關的基本概念。
• 必須清楚提出完整需求。
  舉個簡單的例子：
  （不好）讓登入流程更方便
  （比較好）登入流程加入第三方登入（LINE, FB等等）功能
• 明定使用者故事，列出Who, What, Why…等。
  舉例來說：
  作為年輕小資族（年收30萬以下），我希望App可以精簡存錢的步驟，讓我可以更輕鬆存到第一桶金。
• 心態上要保持「彈性」應變，產品與需求瞬息萬變，要即時應對與調整

身分地位

• 與專案經理不同。
  專案經理重點在控管流程，確保專案的執行順暢，保證產品可以被準時交付。產品經理本身更著重在產品本身的開發，以及與公司內、公司外的人打交道，是重要的溝通橋樑。
• 雖然名稱冠上「經理」，但其實身份同於工程師、設計師等同事。
  要小心不要一副高高在上的姿態，這樣只會增加溝通的難度，畢竟他們各自還是對其主管負責。
• 需要「定期」與各個「利害關係人」溝通回報。
  利害關係人，例如財務、會計等等，不是與專案內部最直接的同事們就好，因為專案的時程與人力有改變，可能都會影響到成本的增加減少，如果在專案的最後才做告知，可能會因為當初的成本估算與最後的實際支出落差太大，導致預算不足甚至是公司會有所虧損（收入不敷成本），所以必須要與這些同事、主管做匯報。

SCRUM開發流程

• 每日立會。
  每天花上大約15分鐘，每個人依序說出昨天做了什麼、有哪些困難，而今天打算做什麼，就是一個簡單的例行回饋。不過如果有其他延伸或細節問題，則是個別討論，不要佔用大家的時間。
• 短時間衝刺。
  有別於瀑布式的長時間完整開發週期，SCRUM通常是以大約2~4週為一個週期，在這個週期內「衝刺」出「可行還能用」的解決方案，為的就是快速獲得回饋與即時修正（即時很重要！）。以一季來看，SCRUM最多可以做出約8個衝刺，總共獲得8次的回饋，而瀑布式可能是在完整開發之後（大家默默開發），一季的最後才釋出產品讓大家試用，這時候可能就已經來不及修改了。
• 燃盡圖。
  橫軸是日期，縱軸是故事點時間。用於檢視隨著日期的推進還剩多少故事點（簡單來說就是工作）要做的一張圖。理想情況下，斜線會是穩定的往右下延伸，代表每天都有完成相應的工作，沒有太多工作處於停滯狀態（如果是太多沒做完，就會是接近水平的直線，因為隨著天數的增加，工作沒變少）。

相關案例

整理案例中幾個印象比較深刻的

• 書中的產品開發心得的案例分享，分享者大多是資深的軟體工程師出身。
  或許是因為懂得產品的實際開發，以及有著經手過許多產品，而且清楚那些開發上會遇到的實際問題，所以更知道該如何打造出好產品。
• 「幫客戶多想一點」
  客戶只提到要解決什麼問題，或是提出功能需求，如果只是完成這些要求而已，那可能只有60分。能進一步思考使用情境，以對方的角度發揮同理心，多想一些更多的其他可能性，貼心地替客戶考慮更多，這樣或許能提高到80分，甚至是100分了。
• 「釐清問題本質」
  有時要聽出弦外之音，客戶有時候要的只是功能，但其實常常需要轉換成「需求」，這樣才能夠解決痛點。如果只照著功能做，就會落入知其然不知其所以然的窘境，常常需要反覆加以修改，只因為不懂客戶的真正問題是什麼。

組織

• SCRUM團隊大約5~9人。
  人太少討論起來沒效果，人太多又沒效率，因此通常來說，SCRUM團隊成員大約是這個人數。
• 回顧很重要。
  在專案完成或是告一個段落時，進行每個人對於專案的回顧調查。透過這樣的調查，可以知道每個人有遇到哪些困難，哪些部分可以提出改進的，「檢討要具名是誰，而讚美則不用」，藉由這樣的回顧探討，交換彼此的意見，讓團隊中的所有成員都能藉此成長。甚至連「工作滿不滿意」都可以在這樣的回顧中得知，也免得員工提離職都不知道為什麼。
• 清楚各成本，掌握財務。
  從時間、人力的安排，加加總總把成本估算出來，這件事是PM特別重要的工作。知道開發產品要花多少錢，這樣「提供預算」的那些人，像是財務或是老闆，心裡才有個底要賺多少錢才能回本。因此估算這個階段可是身負重責大任，無論估太多或太少，都會影響往後專案的執行，如果估太多，那麼即便產品再吸引，可能在初期就直接被否決；估太少，可能做到一半才發現已經沒錢了，沒有足夠的預算做行銷或是公開測試等等，所以可以說是特別重要的一個階段。
  而在成本中的估算時，要記得預留「準備成本」，也就是「以防萬一」發生什麼事的一筆預算，通常可以是總預算的5%~10%，依產品不同而不同，如果沒動用到這筆錢，或許還能從中發一點「獎金」，乍看之下就像是為了公司省下一筆錢了。