owned this note
owned this note
Published
Linked with GitHub
# 產品開發的兩難 - 游舒帆(Gipi)
{%hackmd @HWDC/BJOE4qInR %}
>#### 》[議程介紹](https://hwdc.ithome.com.tw/2024/session-page/3317)
>#### 》[填寫議程滿意度問卷|回饋建言給辛苦的講者](https://forms.gle/uTxyLQWdD4GtXCRp8)
---
[TOC]
---
## 前言
軟體開發的過程中跟其他(產業)工作完全不同,前面錯的會延續後面的結果。軟體因為一直有使用者,更動它會影響使用者,稱之為技術債。是軟體開發的常態。
## 軟體開發常遇到的問題
- 出 bug 時,應解決 root cause or workaround?
- 功能做完整, 還是單點解?
- 小功能愈來愈多時, 體驗愈來愈差
- 迭代可能讓體驗變差
- 資源要放在需求還是技術債
- 滿足多數客戶,還是深入特定客戶
- 滿足多數客戶可能讓產品變糟糕
- 平台至少有2個需求方, 平台方不好做.
- 一般產品應該要侷限特定需求方
- 這些問題沒有標準答案:看情況
## 要換個輪子還是繼續騎?
客戶停不下來而且不相信你是對的
如何說服團隊目前是方輪子,軟體開發很難佐證
[What is technical debt#1](https://melv1n.com/what-is-technical-debt/)
[What is technical debt#2](https://blog.smitio.com/what-is-technical-debt)
- 被懷疑效率與能力,可能沒惡意或是好奇
- 團隊專業分工,但是實際產出侷限在開發者身上
- 軟體開發人數5倍,不能代表產出5倍
- 明明是三鐵選手, 卻被要求跟單項選手比賽
- 請巿場部門做競品分析, 結果選了10個競品, 然後每一個項目都輸. 意思是, 不要想去滿足10個客戶對象, 如此一來, 產品就會很難規劃.
- 應回過頭來想, 關鍵的客戶/鎖定的客戶, 所對應的競爭對手是哪些.
## 軟體開發工作項目
|  |
|:--:|
|*Figure A*|
* 新研發項目
* 需求開發
* bugs/issues
* 技術債償還
* 客製化
* 需求評比
> 習慣選擇容易的, 快的, 短期沒事, 後果都發生在長期.
> 業績都揹1年, 沒有marketing會揹3年=>所以有可能是軟體開發部門去揹技術債.
# 大多數的兩難,問題都在於**資源配置**
## 資源配置盤點
|  |
|:--:|
|*Figure B-1*|
大多的團隊在初期都處於 *Figure B-1* 最左邊偏重短期的狀況, 沒有人或資源去規劃長期的事情。
|  |
|:--:|
|*Figure B-2*|
- 要從 *Figure B-2* 最左邊偏重短期到最右邊均衡需要階段性
- 減少技術債
- 減少短期、投資長期
- 降低客製化
- 投入新研發項目
- 客製化太多,產品就會越發散,但在早期不接又不行(兩難)
- 某個特定對象,做深就會變成是在某個特定領域裡面,特定客戶對象很有競爭力的 1 個好產品
技術債 -(換個說法)-> 甜蜜的負擔 (祖產)
- 需要有人去控制 產品的走向
- 哪些客製化產品可以接
- 哪些產品已經不需要接,公司也可以活下來
## 與老闆、業務端溝通需要明確的能說出修改前後的差距、並說服對方改變後比改變前好
|  |
|:--:|
|*Figure C*|
1. 對目標的具體定義
2. 對現況的清楚描述
3. 有個想像的路徑與方向
4. 有短期的計畫
5. 聚焦
6. 能藉由回饋持續修正方向
- 長線思考
- 如果對長期是好,通常是值得做.
- 做這個決定後, 1年後, 3年後會變成長樣?
- 減法原則
- 聚焦巿場,目標少, 需求自然少.
- 服務誰,客戶對象是誰
- e.g. 數位行銷部門 vs 產品部門, 想要掛promotion(B2B) vs 影響客戶體驗(B2C)
價值主張
為更精準的客戶服務
## 溝通的4大原則
### 1. 可以判讀的證據
- 量化
#### 溝通的原則
1. 掌握數據
1. 圍繞著效益
1. 說明趨勢正在惡化
### 2. 長期效益與短期衝擊
#### 說明可能的衝擊
1. 回應時效變慢
1. 能接的案子減少
1. 客戶需求推遲
#### 重新衡量優先順序
|  |
|:--:|
|*Figure D*|
- 客戶分級
- 議題分級
- 調降目標
> 搞清楚是革新還是革命
#### 痛點先解,逐步交付
|  |
|:--:|
|*Figure E*|
### 3. 溝通、溝通、過度溝通
- 資訊透明化:對現況(進度、問題、錯誤)的認知一致
- 坦誠 & 建立信任感
- 同舟共濟:盡己所能,你的難關,我跟你一起承擔
- 客戶罵業務, 客戶通常(?)對技術人員比較客氣 => 因為客戶需要能碰到有解決問題的人.
### 4. 堅持,但保有彈性
重點是團隊認知一致並有共識, 不要妥協
|  |
|:--:|
|*Figure F*|
- 資源變動原則
- #1 任務資源不動
- 20% 資源異動為上限
- 3 個月重新檢視
#### 產品開發的兩難
|  |
|:--:|
|*Figure G*|
兩難,經常源自於資源配置的問題
定位:把核心客戶服務好
長線思考,短期死不了,未來更重要
量化,不只是管理,關鍵是溝通
團隊合作,有彈性,更要有底線與堅持
---
## ==以下聊天區==