淺談產品開發與工作流程

大綱整理

• 工程師的一天
• 工程師怎麼知道要做什麼？
• 做完會部署到哪裡？
• QA 會怎麼測試？
• 怎麼樣算是完成？

工程師的一天

公司通常會以兩週為一個開發週期，期間內會分配該做的工作。
使用 Sprint Planning（工作天為 10 天）

• Day 1（週一）
  召集 PM、前後端，開會討論決定這兩週要開發的功能。針對每個 task 討論細節、附上設計稿。根據 task 的 Story Points(難度分數/時數)，再分配給每位工程師（扣除開會、無預警事件。兩週大概有 60-65 小時）。

• Day 1 ～ Day 8 (隔週三為止)
  開發 + Daily Standup，是否有遇到 blocker（舉例：後端 API 有沒有準備好，讓前段進行串接）

• Day 9 (隔週四)
  部署（Deploy）

• Day 10 (隔週五)
  這兩個禮拜做了什麼功能（Sprint Semo）
  檢討會議（Sprint retrospective）

  • Went well
  • To improve
  • Action items

工程師怎麼知道要做什麼，哪來這麼多工作要做？

PM 會告訴你。
那麼，一個需求是怎麼產生的？（關鍵環節：2 & 4）

1. stakeholder 提出需求
   stakeholder（利益相關者），舉例來說，行銷部想要在電商網站雙十一節期間，發送折扣碼券給會員，就把這個需求提給 PM。

2. PM 開始撰寫 spec
   PM 與行銷部討論，確認需求之後，就會開始寫 spec（產品規格書）。

3. 畫 wireframe
   撰寫 spec，也會著手開始畫 wireframe（線稿）。

4. 交給 Designer 產生 mockup
   PM 把東西需求整理好之後，交給 Designer 產生 mockup ，就會有比較具體的畫面產生 。像是之前在做部落格、餐廳網站時，使用 zeplin，來搭起設計師與工程師之間的畫面設計的橋梁。

5. 交給工程師開工

撰寫 spec 相關名詞介紹

Product spec 裡面有什麼東西？

• 先來介紹一下什麼是 PRD？
  PRD（全名為 Product Requirement Document），又稱為產品需求規格書。PRD 的功能主要是在幫助公司開發新產品或是舊產品疊加新功能時，與相關利益相關者、開發工程師溝通的重要媒介。

  PRD 目標是將產品需求「描述清楚」，任何的設計文件都是輔助將「抽象化、形而上的功能」，用各種方式「具體化」，所以 PRD只求清晰明瞭，詞必達意。

• UI 部分
  
  

• 商務邏輯部分
  
  

• 以上圖片來源：PRD到底该怎么写？更全面的文档范例来了

User Story 使用者故事

幫助 PM 撰寫 spec 時，以客戶或使用者的觀點撰寫下有價值的功能，藉以釐清真正的開發需求。

撰寫 user story 初級的範本，以此為例：

（中文版本）作為一個 (某個角色) 使用者，我可以做 (某個功能) 事情，如此可以有 (某個商業價值) 的好處。
（英文版本）As a (role of user), I want (some feature) so that (some business value). => who/what/why

舉 lidemy 學習系統，user story 為範例：

• 身份：
  管理員、助教、學生
• 功能：
  • 進度報告頁面改善 (P1、P2 後面數字表達優先處理順序)
    • P1 身為一個使用者，我希望在進度報告頁面可以看到發文者的身份，才能更了解他的背景
    • P2 身為一個使用者，我希望可以搜尋進步報告頁面內容
  • 後台進步分佈頁面
    • P1 身為一個管理員，我希望可以看到每個學生進度到哪一週

卡片、票、任務，都是同一種東西

任務（Task）、卡片（Card）、票（Ticket）、問題（Issue），都指同個東西。
實際工作現場會使用的管理開發任務的軟體：Jira

軟體開發方法論

• Waterfall 瀑布流（線性、回不了頭、週期長）
  Requirements -> Design -> Implementation（實作） -> Verification（驗證） -> Maintenance
• Agile 敏捷 (循環流、可隨時更新產品需求、週期短)
  敏捷的核心原則
  • 要頻繁的發佈
    頻繁的意思是「至少每兩週發佈一次」。好的產品團隊甚至每天發佈好幾次，就是所謂的「持續交付」 (Continuous Delivery)。
  • 團隊要被賦權且被問責
    被賦權的意思是「交由團隊來找解決問題的最佳方法」。舉例來說，不是由管理層告知團隊「請串接日本當地 LN 公司的行動支付」，而是告訴團隊「我們眼前看到的問題，是太少日本當地人購買我們的產品，海外轉換率實在太低了，請你們解決這個問題」。

實現敏捷的實作

• Kanban（看板、檢視成果的週期不固定）
  最有名的案例：Trello
• Scrum (開啟 sprint，檢視成果週期為兩週一次)
  三個重要角色：Product Owner、ScrumMaster、Team(Designer、Developer)
  真實工作現場：Product Owner + ScrumMaster（PM）

做完會部署到哪裡？

1. local 環境（本機）：在你自己的電腦上做測試
2. development 環境（dev）：部署到真實 server、拿 local 開發時的資料，來做測試
3. staging 環境 / qa 環境：像是 production 的地方；大部分會拿 production 的資料來測試，不對外公開的最新版本。
4. production 環境：大家都可以看得到！

QA 會怎麼測試？

與工程師針對程式碼的 Unit Test 不一樣。QA 只管最後功能呈現出來有沒有錯誤。
主要兩個測試面向：

• SIT（System Integration Testing）：手動測試或自動化測試
• UAT（User Acceptance Testing）：實際使用者來做測試（PM）

參考資料：
什麼是 User Story?
【SOP不藏私】系列＃EP1「連猴子也會的PRD指南」
做產品真是哭夭難！ — Marty Cagan 演講 70 分鐘中文逐字翻譯