PM
含有「PM」共 137 篇內容
全部內容
發佈日期由新至舊
上一篇文章提到了 成為優秀 PM 重要的三件事。這邊也分享我認為從 PM 的角度，成為優秀的工程師最重要的三件事。如果有其他不同的想法，也歡迎留言補充與指教。
1. 持續同步資訊
當進度落後或遇到問題時，第一時間說明潛在風險與影響，不要到最後一刻才揭露問題。
另外，也不要只專注於程式碼開
前陣子與同事閒聊時，發現大家對某位 PM 一致給予了高評價。因此思考了一下是哪些行為，能讓 PM 成為工程師們想合作的對象，並寫下了這篇文章。
內容為個人觀點，如果有其他不同的想法，歡迎留言補充與指教。在下一篇文章中，我會反過來從 PM 的角度出發，分享成為優秀的工程師要掌握的三件事。
平常看到臉書的抽獎活動，只要是官方粉絲專頁，我都會碰碰運氣試一下，我也知道這是官網的宣傳伎倆，是宣傳手法之一，目的是要提高聲量和點擊率，動動手指換一個希望，也是一種生活樂趣。
忘了是多久以前的事了，看到好友做了腦筋急轉彎2的心理測驗，我也跟風測了一次，網頁上說在留言區貼上測驗結果，再tag一個好友
探討人工智慧 (AI) 時代下產品經理的角色轉變，從掌握 AI 概念、活用 AI 工具到培養數據驅動思維、跨領域知識及快速學習能力等面向，並點出 AI 的侷限性與注意事項。
撰寫的API規格書是軟體PM必學技能，能有效提升開發效率並減少溝通誤差。本文分享API規格書從需求收集、設計架構到版本管理。PM不需寫程式，但需理解API邏輯，成為開發與需求方的溝通橋樑，讓專案更順暢、開發團隊更高效！
以一個資深員工的眼光來看，光寶是什麼樣的企業呢？Elgin 首先自謙她在光寶待了五年，並不是最資深的員工，但她認為光寶可以說是「幸福企業」。
需求優先度是 PM 都會遇到的議題，尤其在 To C 產業，或是 To B 要做成 SaaS 型產品，常會遇到的兩難。
象限法
最常用的需求分析應該是象限法(個人感受，無數據支持)，適合分析兩種至多三種名目屬性的變數。包含有無、是否、男女等。常見的範例兩種變數，緊急不緊急、重要不重要
OGSM 是我工作上很常使用的架構。我用它來：
◼︎ 對焦公司目標，規劃專案內容
◼︎ 和老闆評估資源投入，確認工作排序
◼︎ 和團隊對標專案時程
付費限定
在先前的內容中，我們聊過了有關專案經理的工作範疇、技能以及產業生態，而產品經理與專案經理最大的差異在於：知識的深度、技能的深度，產品經理主要專研某個領域的專業知識並統籌出可以精準解決使用者問題的軟體服務，而專案經理並沒有資源能處理這麼細節的內容，更多時候還是以「結案」為首要目標。
在我們公司，PM 是個高含金量的職位，能在這裡當上 PM，無論放在內部組織還是業界市場，都代表著一種極高的價值和信任。
而我今天未滿30歲，要接下這個重要職位！