淺談產品開發與工作流程


大綱整理

  • 工程師的一天
  • 工程師怎麼知道要做什麼?
  • 做完會部署到哪裡?
  • 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 分鐘中文逐字翻譯







你可能感興趣的文章

統一建模語言 UML

統一建模語言 UML

[Day 02] Bandit Problem

[Day 02] Bandit Problem

面試前測,一些資安問題

面試前測,一些資安問題






留言討論