###### tags: `芷蕾`, `講座`
# 商業策略與產品策略共舞
## 用戶體驗地圖
主要有兩種表達形式
1. 時間軸表示法
2. 飛輪表示法：能夠一眼看出接觸點位於哪個階段，這是一個簡化版的地圖，僅呈現較為關鍵的模式或是目標。
延伸閱讀：[體驗地圖 與 使用者體驗旅程](https://designtongue.me/體驗地圖-使用者體驗旅程/)
## 產品探索
to do
總共有四個階段
1. 線上調查
2. 一對一訪談
3. 問卷調查
4. 焦點小組

延伸閱讀：[焦點小組實作經驗分享](https://medium.com/uxeastmeetswest/焦點小組實作經驗分享-897640b8cc0)
## 產品建置
### RoadMap
to do
### 產品概述、設計、測試
to do
### product backlog
backlog不一定會做，只是可能會做的代辦清單，backlog需要經過PO排序，PO會與團隊成員和利益關係人商討在自行決定這些任務的優先順序為何，也會定期清掉不必要的需求。

排序的方式有很多種，每個企業的評斷標準不同：

（依照影響力與複雜程度來排序）

（來自阿雅的簡報，象限看不太懂，如果有人看懂幫忙補充）
阿雅提出的幾個排列方式
* How well does it solve the people problem?
* Return on investment for company
* Fit with strategy?
* Dependency
* 20%緩衝時間、10%技術債(ex:code寫的很亂需要整理的時間..新創公司大概在10%，大公司則是20%)
* 要有50%的代辦是能夠dirve metrics的，10%是big bet也就是比較冒險的大變動#1，10% for 公關用，也就是那些更動具有新聞價值，能夠幫公司做曝光提升形象。
* 符合現實：技術資源到位、投資人同意的

`#註1:曾經讀過一篇報導是說那些比較創新且成功的公司都熱愛做實驗，測試很多新功能然後從數據中學習，測試的越多成功越大，當然失敗的也很多，但如果沒有大量實驗，成本也比較高。一次實驗1000項測試可能有1%的機率成功，但那10次的成功將為公司帶來巨大的好處，可能是轉換率提升2倍之類的，但如果你只實驗100個，那你成功的次數也就少了，得到的好康少，失敗的還是很多。`

### Backlog裡面有什麼？
1. Epic = a collection of stories.
`一個Epic有點像是一個大分類的概念，像是只要是跟搜尋功能有關的(ex:關鍵字查找、推薦清單..)都會被歸類在搜尋這個Epic之下`
1. Each ticket has:
* User story
As a (persona in specific context),I would like to (what feature),so that I can (job to be done.)
舉例：作為一個管院大學生，我需要一個可以用筆寫字的平板電腦，這樣我就可以在上課的時候做筆記還不怕筆記被我弄不見。
延伸閱讀：[Agile User Story 敏捷開發之使用者故事](https://chuanstudio.pixnet.net/blog/post/63057787)
* 驗收標準
* 產品概述(修正後含有額外資訊的產品Brief )->給全部的team member看
* 設計


延伸閱讀資料：[用故事地圖管理敏捷開發需求（上）](http://teddy-chen-tw.blogspot.com/2014/01/blog-post_15.html)
## Scrum team
PO scrum master

## Backlog grooming
其實就是一個和開發團隊溝通的過程，開發團隊會問一些問題，也會就ticktets給一些回饋，並針對每張tickts給予不同的難度評分（他不見得會以天數告訴你這個要做多久，反而會以類似等級或是點數的方式告訴產品經理這個大概要做多久的感覺。），Scrum team也會討論最佳解方為何。

grooming完之後，產品經理要根據大家的回饋修改tickets內容，針對開發團隊的問題補充額外資訊，根據開發團隊的T-shirt sizing修改backlog的順序。

延伸閱讀：[Backlog Refinement](https://www.agilealliance.org/glossary/backlog-grooming/#q=~(infinite~false~filters~(postType~(~'page~'post~'aa_book~'aa_event_session~'aa_glossary~'aa_organizations~'aa_research_paper~'aa_video)~tags~(~'backlog*20refinement))~searchTerm~'~sort~false~sortDirection~'asc~page~1))
## Sprint

每個sprint的時間要固定

產品上線不要在最後一天，避免出問題大家還要加班。（ex:sprint一週，上線在週二）

產品經理要先訂出選擇標準selection criteria，
哪一個要進入本次的sprint就看backlog的order是怎樣的

sprint之間沒有間隔。

> * -2weeks
> * scrum team
> * Backlog grooming
>
> product backlog by PO
> * user story
> * 驗收標準

根據grooming的feadback後，就開始計劃sprint（確定要做），剛剛前面只是一些想做的代辦
### Sprint Planning
* 在計劃階段會：
* 決定sprint的目標為何，也就是這期間你要達成什麼目標（可能是一個功能）
* 預估未來大概可以做多少tickets
* scrum team在開始前會訂出做完的定義(Definition of Done)
* 時間：sprint開始前1weeks
* 參與人員：scrum team
* 階段：Sprint Planning
* 重點：Set Sprint Goals and Definition of Done by scrum team Sprint backlog by 開發團隊

### Durint the sprint
* 站立會議
* What are the blockers?
* 有在軌道上嗎？有朝著sprint的目標走？
* Scrum master協助移除障礙，產品經理和開發團隊討論確認進度。


### 敏捷的概念就是即時根據用戶的需求、反饋來修正MVP

### 沒做完怎麼辦？要繼續在下一個sprint做嗎？

sprint裡沒做完的會回到product backlog，然後再重新排序排隊（跟新的在比一次），如果還是在最上面就會回到sprint。

而判斷哪一個要先做的前提是要先列出selection criteria，舉例，你的第一件事情可能是想先打敗競爭對手的某A功能。

當我問你你要做什麼，你得交出你要做什麼，但前提是你有一個選擇標準。

每個選擇都沒有好壞，都有trade-off，成效來自於你有沒有選到對的事情做，為目標達到最大的效益。

延伸閱讀：[[Scrum軟體開發入門]上課筆記與心得](https://medium.com/evan-android-note/scrum軟體開發入門-上課筆記與心得-80160016f5f2)
[The 2020 Scrum GuideTM](https://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog)
[當一個 Scrum Master 是一個怎樣的體驗？](https://blog.techbridge.cc/2019/01/05/hello-i-am-a-scrum-master/)

阿雅針對scrum這段講得比較快，也比及輕描淡寫，所以我還不是很了解，以上提供幾個完整講述scrum的文章，大家看完可以幫我補充一下我的筆記！