需求怎麼來？
PM 會告訴工程師要做什麼(需求)
- stakeholder(利益相關者) 向 PM 提出需求 ex. 折價券的功能
- PM 寫 spec(規格書)：
- Product Requirement Document (產品需求文件)
- Product Specifications (產品規格書)
- PM 畫 Wireframe(線搞)，粗略頁面、怎麼使用之類的
- PM 把需求整理出來，交給設計師產生 mockup(設計稿)
- mockup 完成後，交給工程師開工
工程師怎麼知道怎麼做？
看 Step 2 的 spec(功能) + Step 4 的 mockup(畫面)，把實際產品做出來
Product Spec
- User Flow 流程圖
- Wireframe 介面
- User Story 使用者故事
User Story 使用者故事
- P1 身為一個(某個腳色)使用者，我希望(某種功能)，才能(有甚麼商業價值)的好處 (As a...user, I hope/I want...so that...)
- P：Priority 優先順序，數字越小越優先
- 一個 User Story 一個 ticket
Ticket 票 (或 task、card、issue)
現成 ticket 系統網站：Jira
一個任務一個 ticket，可以分配 ticket，標示完成進度
軟體開發方法論
Waterfall 瀑布流
- 一個循環，一次性開發完Requirement=>Design=>Implementation=>Varification=>Maintenance
- 中間如果有修改也要等一個循環結束才能在新的循環修改
- 無法回到上個步驟，比較笨重
Agile 敏捷開發
- 快速迭代、快速找出錯誤，可以回到上個步驟
- 類似很多小的 waterfall 一直跑
- Kanban、Scrum
Kanban
- To do
- Doing
- Done
#### Scrum - Product backlog(要開發的功能)
- Sprint 開發週期 (通常 1~4 週)
- Sprint backlog (一個 sprint 裡面要做的功能)
一個 sprint 的流程
- 星期一：Sprint planning meeting
- PM 會解釋一個個票要做甚麼
- 分配誰要做甚麼票
- 估時間(Story point)
- 星期二 ~ 隔週三：開發 + Daily Standup
- 開發自己分配到的東西
- 每天報告昨天作的、今天要做、blocker(有甚麼東西擋住)
- 隔週四：部署
- 部署到測試環境
- 隔周五：Sprint Demo + Sprint retrospective
- demo 這兩週做的東西
- 檢討會議(Went well、to improve、action item)
部署
- local 環境 (本機)
- development 環境 (dev)
- staging 環境 / qa 環境：不對外公開的最新版本會在這測試
- production 環境：公開的
測試
QA/QC
- SIT(System Integration Testing)：實際功能測試
- UAT(User Acceptance Testing)：實際使用者去測試
其他相關文章筆記
敏捷 (Agile) 的核心原則：
- 頻繁發布 (Continuous Deivery)
- 由團隊自行提出方案解決眼前看到的問題
精實 (Lean) 的核心原則：
- 快速學習，有夠多點子可以嘗試
- 消除浪費(MVP/4天或4小時)
產品探索 (Product Discovery)
Build the right thing
打造 prototypes
- 對用戶有價值 (valuable)
- 易於使用 (usable)
- 可被打造 (feasible)
- 商業上可行 (viable)
產品交付 (Product Delivery)
Build the thing right
打造 product
- 穩定 (reliable)
- 可擴展 (scalable)
- 高效能 (performant)
- 可維護 (maintainable)
- 支援多國語言又在地化 (internationalized and localized)
目標：解決問題
產品失敗的四大風險
- 實行性風險：知道需求是甚麼，但做不出來
- 易用性風險：產品做出來，但不知道怎麼用
- 價值風險：產品做出來，知道怎麼用，但沒有需求
- 商業可行性風險：無法賺錢，無法贏過競爭者
Product team
- 交付階段前處理四大風險
- 團隊成員共同協作解決問題
- 團隊成員被賦予解決問題作為目標
如果這是一個被授權的產品團隊 (Empowered Product Team)，他們被交付的是問題與目標，而不是產品路線圖。在真正的產品團隊中，產品經理則要負責的是這個解法能夠 (為用戶) 帶來價值，在商業上也可行
Problem solver(問題排出者)
告訴主管或相關利益人該方法不可行，必須再提出別的方法是否可行，或更有機會成功
Opportunity Solution tree 機會與方案樹狀圖
產品優化工具：Optimizely、Google Optimize
產品探索 (Product Discovery) 就為了「創造價值」 (value creation)，產品優化 (Product Optimization) 只為了捕捉價值 (value capture)。
產品經理四大核心能力
- 對用戶和顧客的深入知識
- 對用戶資料的深入知識
- 對事業的深入知識
- 對產業的深入知識
