產品開發流程


Posted by chihyu on 2021-01-25

需求怎麼來?

PM 會告訴工程師要做什麼(需求)

  1. stakeholder(利益相關者) 向 PM 提出需求 ex. 折價券的功能
  2. PM 寫 spec(規格書):
    • Product Requirement Document (產品需求文件)
    • Product Specifications (產品規格書)
  3. PM 畫 Wireframe(線搞),粗略頁面、怎麼使用之類的
  4. PM 把需求整理出來,交給設計師產生 mockup(設計稿)
  5. 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)

部署

  1. local 環境 (本機)
  2. development 環境 (dev)
  3. staging 環境 / qa 環境:不對外公開的最新版本會在這測試
  4. 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)。

產品經理四大核心能力

  • 對用戶和顧客的深入知識
  • 對用戶資料的深入知識
  • 對事業的深入知識
  • 對產業的深入知識

文章來源:做產品真是哭夭難! — Marty Cagan 演講 70 分鐘中文逐字翻譯(附贈 YouTube 錄影)


#Web #product development







Related Posts

SSRF lab (1)

SSRF lab (1)

function 額外補充

function 額外補充

讀書筆記-前端三十2: Web Development

讀書筆記-前端三十2: Web Development


Comments