# 技術工作者的商業思維，從解決問題到探索問題 - 游舒帆

{%hackmd rG6pzIawQKe5cHU4rycgYg %}

:::success
[TOC]
:::

## 什麼是商業思維？
商業思維就是做生意的思維，也是商業運作的根本道理

RD為什麼在公司地位低？

## 今天要聊兩件事
1. 技術債
2. deploy on Friday

## 技術債(technical debt)
一定得還嗎？

債要怎麼還才是聰明的

當你手邊有錢，你會一次還清嗎?
=> 不會，慢慢還不會死
你有熬夜習慣嗎？（睡眠債、健康債）＝>還了嗎？沒還嘛XD ~~還的時候都是快死的時候!~~


有什麼技術債不用還？不還的機會成本很低的技術債

1. 維護困難，而且熟ASP的人難找
2. 為了不改ASP code，而改用其他 workaround 來處理異常問題
3.
4.

當主管想要全面翻修asp code，老闆卻說先用其他重要案子。

老闆不還債，背後真正的問題是什麼？
> 技術債是屬於活下來的公司，我們有技術債應該以此為榮（？


鄙視鏈：公司有些東西重要、有些不太重要
* 業務部門在談的事
| 公關問題
| 客戶問題
| 營收問題
* 技術部門在談的事
| 成本問題
| 部門問題(二十幾個人都不爽)
v 個人問題(RD爽不爽)

### 換個說法：從公關、客戶、成本來講
:::spoiler 圖片
:::

* 退費金額5000萬
* 人事成本2940萬
* 光是近三個月，退費金額就超過2400萬，問題越來越惡化
* 網路負評造成的影響

### 溝通的原則是
第一，**掌握數據**
> 實際衝擊的數據，點出確切的問題所在
>
第二，**圍繞著利益**
> 用一些大家能理解的語言溝通，像是賠了多少錢？
> 而不是一堆技術專有術語，像是xxx技術老舊，用ooo比較好
>
第三，**說明趨勢正在惡化**
> 現在是解決的時機，不然只會越來越糟糕，預警可能的後果
> 如果不會變壞，那表示已經控制住了八?
> 現在再繼續下去會有問題，讓老闆感受到**急迫感**

### 怎樣的說法才能說服你償還睡眠債?
> 從這個角度出發，技能比較容易找到答案

## Deploy on friday
2015年的那時...

Deploy any time, **crash everyday**.

流程落後、缺乏制度、技術老舊、**一團亂**
> 無法自動化、各個工程師都可以access

永無止盡的**插單**
不分晝夜的**救火**
不斷更動的需求
每件事情都很急

報告：「我們剛剛攻陷的碉堡被友軍誤炸了。」
>　隨時被友軍的code覆蓋（請善用merge）

放心，在 stage 上出問題，上 production 就沒問題了！

> Testing in produciton, crash every time

> 這麼痛苦的事情，一定是報告的方法有問題

2015.7 接手維運負責人之後，只准二、四發布
> 可以確認是哪個版本出狀況
初期時，上線時人要在線上
RD主管：會被業務主管打得滿頭包（回應：會**親自溝通**）

- 第一個問題：
唯一提出疑義的業務主管：
Marketing 的 landing page 常常改常常上，很難只在週二、四上版<-因為不影響主要資料庫，所以可以不照此新規則

**定義例外，但不隨意放寬標準**

- 第二個問題：如果要星期三上線怎麼辦？

* 如果對外發布且具有戰略意義，就特殊處理
* 對內的話，建議提前一天發布，不會有人介意系統提前一天上線的
>讓對方知道你是在替他著想，而不是故意訂個規則去卡他
- 第三個問題：
* 如果有例外時間，請那幾位主管同意並說明原因
**保留緊急通道，但確保足夠謹慎**
* 上線的必要性是什麼？

> **最後 95% 的 case 都 follow 了這個 policy**

### 緊接著...我們又做了幾件事...
1. 盤點近期重要的專案
>　協助各部門解決上線風險，確保這調整不會成為推卸責任的箭靶
2. 各研發團隊的版控跟佈屬自動化
> 將整個團隊的建構管理能力全面性提升
3. 打破大家對業務團隊的錯誤假設
> 用對方法溝通，很多事情都可以被解決
> 其他人的錯誤想像：業務部門"不能談"？

**溝通＞推進＞重建**

> 原以為沒辦法溝通，但其實是溝通方法不對

## 過去常犯的五個錯誤
- 做事沒彈性
- 遇事不堅持
- 提案沒說服力
- 逆著商業思考
- 忽略人性

### 阻礙你的，往往是超出職務邊界的那些事
你能探索問題背後的問題嗎？

### 全職維運團隊退場
=> 開發的人要為自己寫的 code 負責，而不是丟給其他人
Eating your own dog food.
* 商業發展不該受系統能力限制
* 隨時可部署是基本，週五不部署是一種選擇
* 每個系統可以有自己的部署計畫
* 唯一指標是SLA(Service Level Agreement)
去想想怎麼去優化自己的SLA

### 多層配套
1. Monitoring system
> 監控、修復、預警、自動還原
2. 技術客服介入
> 初步判斷並嘗試排除錯誤
3. 維運團隊接手
> 排除問題所花費的時間逐步降低

### Deploy on Firdays.
1. 從商業層面上是難以完全避免的
> 你可以減少在週五部署，但你得有能力隨時發佈程式
2. 對技術對來說，是正面價值
> 技術能力的提升，很多時候來自於挑戰自己的邊界
> 可以看看 Netflix 的 chaos monkey

### 你的腦袋裡可能存在著很多為什麼
為什麼不還技術債？為什麼業績導向？為什麼專案這麼趕不提早講？為什麼做這麼累，薪水只有這樣？為什麼找這麼爛的PM來管？

### 每個「為何」都值得深入探索
很多時候探索完，問題的答案就找到了
而解決問題的方法，...

### 每次跨出「邊界」都是成長的開始
如果你估做了幾年，發現抱怨的事情都一樣，你應該試著跨出邊界

### 技術可能是表面問題

###### tags: `MOPCON 2020`