課程
前線部署工程師(FDE)養成實戰03
已完成 0 / 18
課程目錄+
  1. 模組 A:FDE 是什麼角色

    • 01FDE 到底在做什麼:跟一般外包工程師的差別11 分鐘
    • 02這門課的方法論總覽:訪談→設計→部署→驗收→續約12 分鐘
  2. 模組 B:客戶訪談與需求梳理

    • 03第一次訪談:問對問題,比會技術更重要14 分鐘
    • 04把訪談內容變成可執行的需求文件13 分鐘
    • 05抓範圍:怎麼避免專案無限擴大12 分鐘
  3. 模組 C:技術方案設計

    • 06技術選型:不是選你最熟的,是選客戶撐得住的13 分鐘
    • 07資料模型設計:這步錯了後面全部要重來15 分鐘
    • 08架構文件:讓客戶的 IT 團隊看得懂、你自己也好維護13 分鐘
  4. 模組 D:部署與整合

    • 09開發環境到正式環境:一條乾淨的部署路徑14 分鐘
    • 10系統整合:串接客戶既有系統的眉角15 分鐘
    • 11測試與除錯:客戶案子的品質關卡13 分鐘
  5. 模組 E:驗收與交接

    • 12驗收:怎麼定義「做完了」12 分鐘
    • 13交接與培訓:讓客戶團隊真的能自己維運13 分鐘
  6. 模組 F:商業:提案、定價、續約

    • 14怎麼寫一份打動客戶的提案13 分鐘
    • 15定價:怎麼算出一個你不會做到虧本的報價14 分鐘
    • 16續約與長期關係:一次性案子跟長期客戶的差別12 分鐘
  7. 模組 G:接案與職涯

    • 17找到第一個客戶:作品集、人脈、還是平台接案12 分鐘
    • 18從接案到規模化:一個人、一個小團隊、還是加入公司做 FDE13 分鐘

課程目錄

  1. 模組 A:FDE 是什麼角色

    • 01FDE 到底在做什麼:跟一般外包工程師的差別11 分鐘
    • 02這門課的方法論總覽:訪談→設計→部署→驗收→續約12 分鐘
  2. 模組 B:客戶訪談與需求梳理

    • 03第一次訪談:問對問題,比會技術更重要14 分鐘
    • 04把訪談內容變成可執行的需求文件13 分鐘
    • 05抓範圍:怎麼避免專案無限擴大12 分鐘
  3. 模組 C:技術方案設計

    • 06技術選型:不是選你最熟的,是選客戶撐得住的13 分鐘
    • 07資料模型設計:這步錯了後面全部要重來15 分鐘
    • 08架構文件:讓客戶的 IT 團隊看得懂、你自己也好維護13 分鐘
  4. 模組 D:部署與整合

    • 09開發環境到正式環境:一條乾淨的部署路徑14 分鐘
    • 10系統整合:串接客戶既有系統的眉角15 分鐘
    • 11測試與除錯:客戶案子的品質關卡13 分鐘
  5. 模組 E:驗收與交接

    • 12驗收:怎麼定義「做完了」12 分鐘
    • 13交接與培訓:讓客戶團隊真的能自己維運13 分鐘
  6. 模組 F:商業:提案、定價、續約

    • 14怎麼寫一份打動客戶的提案13 分鐘
    • 15定價:怎麼算出一個你不會做到虧本的報價14 分鐘
    • 16續約與長期關係:一次性案子跟長期客戶的差別12 分鐘
  7. 模組 G:接案與職涯

    • 17找到第一個客戶:作品集、人脈、還是平台接案12 分鐘
    • 18從接案到規模化:一個人、一個小團隊、還是加入公司做 FDE13 分鐘

03·模組 B:客戶訪談與需求梳理

第一次訪談:問對問題,比會技術更重要

客戶嘴上說的需求,通常不是真正的問題。這一集教你往下挖,並給你一份可以直接用的問題清單。

觀念14 分鐘含影片

0:00 / 0:24

客戶說的是解法,你要找的是問題

比喻:病人走進診間說「醫生,我要吃止痛藥」。好的醫生不會直接開藥,會先問:哪裡痛?痛多久了?什麼時候最痛?止痛藥是病人想到的解法,醫生要找的是病因。

客戶也一樣。「我們想導入 AI 客服」「我們需要一個儀表板」,這些都是客戶想到的解法。你第一次訪談的任務,是往下挖,找到那個解法背後真正的問題。

這很重要,因為照著錯誤的問題做出來的系統,做得再好也沒人用。

往下挖三層(示意)

下面是一段虛構的訪談,示範怎麼從解法挖到問題。注意 FDE 幾乎沒有提任何技術:

客戶:我們想導入一個 AI 客服。

FDE:現在客戶來問問題,是誰在回?大概怎麼回?

客戶:客服部三個人,用信箱跟 LINE 官方帳號回。

FDE:這樣運作起來,哪個部分最讓你頭痛?

客戶:回太慢,客戶常常抱怨。

FDE:通常慢在哪一步?是量太大回不完,還是有些問題特別難回?

客戶:其實量還好……主要是最近離職了兩個資深客服,新人很多產品問題不會回,要去問人,問不到就卡住。

挖到第三層,問題已經完全不一樣了。表面上是「需要 AI 客服」,真正的痛是資深員工的知識沒有留下來,新人接不住。

這兩個問題的解法差很多。前者可能是一個自動回覆機器人;後者可能是先把資深客服的回覆整理成知識庫,讓新人查得到——AI 可以幫忙整理和檢索,但它不一定要直接面對客戶。

訪談問題清單

依序問,不用每題都問,但每一區都要碰到:

現況:現在是怎麼做的

  • 這件事現在是誰在做?一天大概做幾次?
  • 可以讓我看一次實際的操作嗎?
  • 用到哪些工具、表格、系統?

痛點:哪裡最痛

  • 這個流程裡,哪一步最花時間?
  • 最近一次出問題是什麼情況?
  • 如果這件事明天就解決了,你最先感受到的改變是什麼?

數字:痛有多痛

  • 這件事每個月大概花掉多少人力時間?

上一集 · 02

這門課的方法論總覽:訪談→設計→部署→驗收→續約

下一集 · 04

把訪談內容變成可執行的需求文件

  • 出錯一次,代價大概是什麼?
  • 決策:誰說了算

    • 這個專案最後由誰決定要不要做?
    • 誰會每天使用做出來的東西?他今天有在這裡嗎?

    成功:做完長什麼樣

    • 三個月後,你怎麼判斷這個專案是成功的?

    最後一題特別重要。答不出來,代表這個專案還沒準備好開始。

    四個常見的地雷

    地雷為什麼有害改成
    問太技術「你們資料庫是用什麼?」客戶答不出來,氣氛變僵先問流程,技術問題之後找 IT 問
    問太籠統「你們有什麼需求?」只會得到一句解法問具體的一次事件:「最近一次卡住是什麼時候?」
    太早給方案聽到一半就說「這個用 AI 很簡單」,客戶就不再往下講整場訪談不提解法,只聽
    只訪問老闆老闆知道痛,但不知道流程卡在哪一定要跟每天做這件事的人談

    訪談結束後 24 小時內

    寫一頁摘要寄給對方,只包含三件事:

    1. 我聽到的現況是什麼
    2. 我理解的核心問題是什麼
    3. 我還不確定、需要再確認的地方

    然後請對方回覆「對」或「不對,其實是……」。

    這封信的價值在於:它在任何人寫下一行程式碼之前,就讓雙方對問題有了同一個理解。很多專案最後的爭議,追根究柢都是從來沒有人把這件事寫下來確認過。第 04 集會把這份摘要擴成正式的需求文件。

    帶走的東西:你的訪談問題清單

    把上面五區的問題,改寫成符合你產業用語的版本,存成一份自己的清單。每次訪談前拿出來看一次,訪談後檢查五區是不是都碰到了。

    動手做

    本集練習

    你的訪談問題清單

    五區都要碰到。改寫成你自己產業的用語,每次訪談前拿出來看一次。

    填寫完成後按右邊存檔

    下一集教你怎麼把訪談內容,變成一份雙方都能簽字確認的需求文件。