序章：火線的挑戰

「下週開始，你要接手 Program Manager 的工作。」

當老闆在晨會上說出這句話時，我腦袋整整空白了五秒。

作為一個 PM（Project Manager / Product Manager），我最擅長的事是與使用者對話，把需求整理成 PRD，再交給工程團隊。可現在，角色卻升級成 Program Manager ——這個在 PMP 裡有明確定義的角色，意味著我要管理的不只是單一專案，而是一整個跨專案、跨系統的「計畫」。

這代表什麼？
👉 我必須能與不同領域的工程師對話，理解他們的程式邏輯，甚至能看出設計上的缺陷。

可是問題來了：

「如果你看不懂程式，我說什麼你都只會點頭。」

這是其中一位老鳥工程師的冷笑話。當時我只能尷尬地乾笑，但心裡清楚：我必須開始學程式，否則在 Program Manager 的位置上，我永遠只能當「傳話筒」，而不是能帶領計畫的人。

第一章：PRD 的食材

身為 PM，我的「基本功」就是寫 PRD。

比方說，我想要做一個小車專案，那麼我可能會寫下這樣的需求：

這就像料理的「食材」：看起來乾乾淨淨，但還不能直接上桌。
工程師需要的是「食譜」，也就是 Spec。

第二章：Spec 的食譜

Spec 是 PRD 的細化，它告訴工程師「如何實現」。

我把剛剛的需求轉換成一份簡單的 Spec：

這樣一來，工程師就能依據這份「食譜」去寫程式。
但既然我要當 Program Manager，我決定親手下廚。

第三章：第一次進廚房 —— micro:bit 積木

我選擇的工具是 micro:bit，因為它有 積木編輯器，可以用拖拉的方式快速拼湊邏輯。

我在腦海裡想像：

• 如果按下按鈕 A → 顯示左箭頭
• 如果按下按鈕 B → 顯示右箭頭
• 如果同時按下 A+B → 顯示上箭頭

這時候我覺得自己就像 小當家第一次拿起菜刀，有點笨拙，但手裡已經開始有「料理」的感覺了。

[快速上手] 如何在 MakeCode 編輯器中建立這個練習

1. 開啟 MakeCode 編輯器：
   前往 Microsoft MakeCode for micro:bit。

2. 建立新專案：
   點擊 "New Project"。

3. 尋找積木：

   • 當 按鈕 ... 被按下 積木位於 輸入 (Input) 的類別中。
   • 顯示箭頭 ... 積木位於 基本 (Basic) 的類別中。

4. 組合積木：

   • 從「輸入」中拖拉出三個 當 按鈕 ... 被按下 積木。
   • 使用下拉選單，分別將它們設定為 A、B 和 A+B。
   • 從「基本」中拖拉出三個 顯示箭頭 ... 積木，並分別放入上述的三個事件積木中。
   • 使用下拉選單，將箭頭方向分別設定為 West (左)、East (右) 和 North (上)。

5. 完成：
   完成後，您可以直接在網頁的模擬器上測試，或將程式碼下載並傳輸到您的 micro:bit 上實際操作。

第四章：模擬器的驚喜

我點開 micro:bit 網站右邊的模擬器，按下「A」鍵，LED 點陣馬上亮出一個「←」符號。
按下「B」 → 「→」
同時按下 A+B → 「↑」

螢幕上的小燈點閃爍的瞬間，我真的笑了。
因為這就是我寫在 PRD 裡的「驗收條件」啊！

我不需要硬體，不需要焊接電路板，就能在網頁上看到需求「活過來」。
這就是積木帶來的第一份感動。

第五章：積木背後的真相 —— Python

不過，Program Manager 不可能只懂積木。
我切換到 Python 模式，看到積木自動轉成了程式碼：

def on_forever():
    # 如果按下按鈕 A
    if input.button_is_pressed(Button.A):
        basic.show_arrow(ArrowNames.WEST)
    # 顯示左箭頭
    # 如果按下按鈕 B
    if input.button_is_pressed(Button.B):
        basic.show_arrow(ArrowNames.EAST)
    elif input.button_is_pressed(Button.AB):
        basic.show_arrow(ArrowNames.NORTH)
basic.forever(on_forever)

我眼睛一亮。
原來剛剛的積木就是這些 if/elif/else！
Spec 裡的「條件 → 行為」對應到程式碼的「if → display.show()」。

第六章：第一次驗收報告

我把這段程式回頭跟 PRD 驗收條件比對：

• 按下 A → 顯示「←」 ✅
• 按下 B → 顯示「→」 ✅
• 同時按下 A+B → 顯示「↑」 ✅

這是我人生第一份「自己完成的驗收報告」。它不只是文字，而是一段真的跑起來的程式。

第七章：第一次的失敗

當然，事情不會永遠那麼順利。

我最初寫程式時，忘了在兩個按鈕內加入內容，變成：

# 第七章：第一次的失敗 - 錯誤程式碼
# 顯示右箭頭

def on_forever():
    # 如果按下按鈕 A
    if input.button_is_pressed(Button.A):
        basic.show_arrow(ArrowNames.WEST)
    # 顯示左箭頭
    # 如果按下按鈕 B
    if input.button_is_pressed(Button.B):
        basic.show_arrow(ArrowNames.EAST)
    elif input.button_is_pressed(Button.AB):
        pass
basic.forever(on_forever)

結果當我同時按下 A+B 時，螢幕一會兒顯示「←」，一會兒顯示「→」，亂成一團。

這時候我才真正體會：
Spec 如果沒寫「同時按下 A+B」的情境，程式就會有 Bug。

第八章：小當家的領悟

小當家第一次煮湯時，師父告訴他：「料理不是食材的堆疊，而是背後的邏輯。」

我覺得程式也是這樣。

• PRD 就是食材：定義需求。
• Spec 就是食譜：設計邏輯。
• 程式 就是料理：把邏輯落地。
• 測試 就是評審：驗收成果。

我不需要成為全職工程師，但至少現在我能看懂程式、看懂邏輯，這讓我在 Program Manager 的角色上有了新的武器。

結尾：下一道料理

第一道「小點心」完成了。

接下來，我要挑戰「真正的料理」：

👉 讓小車遇到障礙時自動停下來。

這不再只是單純的前進/左轉/右轉，而是要處理「環境的不確定性」。也就是說，我要寫出第一份 Spec 驗證程式。

這就是下一篇：《風中的挑戰》。

🎯 第一篇重點整理

故事核心：從 PM 到程式邏輯的轉變

• PM 被推上火線：從產品經理的角色開始，實際動手學習。
• 學習 micro:bit 積木程式：入門程式設計的工具。
• PRD → Spec → 程式邏輯的第一次轉換：理解從產品需求 (PRD) 到規格文件 (Spec)，最終如何轉化為可執行的程式邏輯。

實作練習

• 拖拉積木，箭頭方向顯示左右邊或上：動手完成基本的方向控制。
• 模擬器測試：驗證程式碼在虛擬環境中是否按預期執行。

學習價值

• 理解 Spec 不只是文字：體認到規格文件 (Spec) 實際上是程式背後的邏輯和指令集。

鉤子 (Hook)

• 下一篇預告：我們將挑戰更進階的避障功能，正式進入真實 Python 的世界！