owned this note   changed 5 years ago  
Linked with GitHub

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

歡迎來到 MOPCON 2020 共筆

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

共筆入口：https://hackmd.io/@mopcon/2020
手機版請點選上方 按鈕展開議程列表。

什麼是商業思維？

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

RD為什麼在公司地位低？

今天要聊兩件事

  1. 技術債
  2. deploy on Friday

技術債(technical debt)

一定得還嗎？

債要怎麼還才是聰明的

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

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

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

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

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

老闆不還債，背後真正的問題是什麼？

技術債是屬於活下來的公司，我們有技術債應該以此為榮（？

鄙視鏈：公司有些東西重要、有些不太重要

  • 業務部門在談的事
    | 公關問題
    | 客戶問題
    | 營收問題
  • 技術部門在談的事
    | 成本問題
    | 部門問題(二十幾個人都不爽)
    v 個人問題(RD爽不爽)

換個說法：從公關、客戶、成本來講

圖片

  • 退費金額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. 盤點近期重要的專案

協助各部門解決上線風險，確保這調整不會成為推卸責任的箭靶

  1. 各研發團隊的版控跟佈屬自動化

將整個團隊的建構管理能力全面性提升

  1. 打破大家對業務團隊的錯誤假設

用對方法溝通，很多事情都可以被解決
其他人的錯誤想像：業務部門"不能談"？

溝通＞推進＞重建

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

過去常犯的五個錯誤

  • 做事沒彈性
  • 遇事不堅持
  • 提案沒說服力
  • 逆著商業思考
  • 忽略人性

阻礙你的，往往是超出職務邊界的那些事

你能探索問題背後的問題嗎？

全職維運團隊退場

=> 開發的人要為自己寫的 code 負責，而不是丟給其他人
Eating your own dog food.

  • 商業發展不該受系統能力限制
  • 隨時可部署是基本，週五不部署是一種選擇
  • 每個系統可以有自己的部署計畫
  • 唯一指標是SLA(Service Level Agreement)
    去想想怎麼去優化自己的SLA

多層配套

  1. Monitoring system

監控、修復、預警、自動還原

  1. 技術客服介入

初步判斷並嘗試排除錯誤

  1. 維運團隊接手

排除問題所花費的時間逐步降低

Deploy on Firdays.

  1. 從商業層面上是難以完全避免的

你可以減少在週五部署，但你得有能力隨時發佈程式

  1. 對技術對來說，是正面價值

技術能力的提升，很多時候來自於挑戰自己的邊界
可以看看 Netflix 的 chaos monkey

你的腦袋裡可能存在著很多為什麼

為什麼不還技術債？為什麼業績導向？為什麼專案這麼趕不提早講？為什麼做這麼累，薪水只有這樣？為什麼找這麼爛的PM來管？

每個「為何」都值得深入探索

很多時候探索完，問題的答案就找到了
而解決問題的方法，…

每次跨出「邊界」都是成長的開始

如果你估做了幾年，發現抱怨的事情都一樣，你應該試著跨出邊界

技術可能是表面問題

tags: MOPCON 2020
Select a repo