首頁

在做PM的過程中，不可預期的事情，常常發生，而讓自己可以減少非預期事件發生緊張感，自己也衍生了幾個小撇步，提供給大家參考參考

當產品開發後，有可能除了遇到下架之外，還有可能要移轉給其他單位持續運營，當這情境發生時，也會需要準備相對應資料給對方；這篇內容說明在移交時，要備妥那些資料，比較好讓對方持續運營。

這一篇從財務的角度來說明產品下架時，要注意的相關事務

這一篇使用者的角度出發，來進行相關產品下架的相關事務

產品開發後，也勢必會有結束的一天，整理一些下架需注意事項，先從內部審查的角度整理

當AP做好後，要上架到到平台時，又是另一個挑戰，因為永遠不會知道，審查人員會注意什麼？做了一些採過雷的筆記，讓自己可以避免忘記。

當開發進行到一個段落後，就需要開始進行測試驗收，確認是否符合預期，如不符合預期，就需要討論要如何調整和排程。

SPEC 的內容是為了讓開發團隊易於理解，整理一些小Tips，讓SPEC寫得更順暢

Roadmap是為了讓產品的開發達成的願景，產品的目的地，因此避免加入了許多跟願景無關的內容，依據5項原則進行撰寫。

Function Map了解整個產品會有具備那些服務功能，而這些功能彼此之間的具備哪些關聯性

User Story協助開發人員及相關人員，對於開發的內容會有一個參考依據

當產品有需要跨國使用的話，那就要考量語系的功能，而在一開始時，就需要將相對應語系內容和Key值先建立起來，以利於未來的擴增性

建立常見預設情境，在每次構想功能時，可以做完一個開始

詳實特定範圍的內容，擴大問件內容討論的範疇及細節，可以採以易於閱讀理解的方式進行撰寫

在開發時的關鍵元件內容，都建置起來相關參考資料

撰寫How-to內容說明，注重可實現的步驟內容，不要讓其他內容分散注意力

引導教學Tutorials，在寫規格書時，先考量的第一步

規格文檔，會需包含未來、現在、過去的內容，因此也需要做好版本控制，避免現在執行項目的人員，誤判仍在設計中的未來項目

列舉出主要開發節點，開發流程只是一個框架，要找出最符合組織的作業方式，讓專案可以運行順暢為主。

撰寫執行內容時應盡可能完整描述，以執行者的角度出發，讓任務簡單上手。若內容需更新，保持即時通知，確保資訊透明且具彈性，以減少溝通成本並適應決策變動。

經過兩年多(2020.7-2023.9)的時…

💡 軟體沒有做不到，只有想不到；硬體沒有做不到，只要有錢一直倒

台灣多數公司為小型組織，資料收集應以高品質文獻為主，特別是近3年的數據。競爭對手產品狀態分析亦能提供有益參考，但需考量自家公司商業模式的差異。

在進行脈絡式開放式訪談時，訪談者需具備控場能力，以維持受訪者的開放分享，同時深入探索其潛在需求。

在確定產品或服務目標後，需透過「觀察」、「訪談」或「文獻探討」來發現需求。觀察應以少數成員在特定場域進行，並記錄對象特點，標註效應。這樣可比較觀察結果，減少主觀偏差，提升需求了解。

當定義問題後，會有多種解決方案出現。為了評估解決方案，可從使用者體驗、可執行程度和商業價值三個面向過濾，維持三者之間的平衡狀態至關重要。

在開始建設系統之前，了解根本問題及其重要性相當關鍵。定義問題時，要深思核心需求與商業模式，雖然產品可能不理想，但仍能吸引使用者。從零到一是最具挑戰性的階段，需不斷進行迭代與探索。在定義問題過程中，提問「為什麼」能理清範疇並為未來產品發展奠定基礎，改變方向亦需謹慎考量。