# Side Project 企劃與執行追蹤板

> 填一個日期——專案開始日——15 個任務的目標完成日自動排出來，剩餘天數每天自動更新。
>
> **這份的完整版是 CSV**（日期欄是公式）。Markdown 是紙本／Notion 版，日期要自己填。
>
> **用 Google 試算表**：檔案 → 匯入 → 上傳 CSV → 匯入位置選「取代試算表」。
> **匯入 Notion**：Import → Markdown（公式不會過來）。

## 這份表想解決的問題

Side Project 最常見的死法不是做不出來，是**做到一半失去方向**——因為一開始定義的是解法不是問題，
或者範圍大到看不到終點。所以這張表的前六列全部在 Step 1 和 Step 2，都還沒開始寫程式。

那不是拖延，是這個流程最重要的部分。完整說明見
`/pages/resources/side-project-from-zero.html`。

## 兩個最容易略過、但代價最大的欄位

**「每次卡關當下就記一筆」**——事後補寫一定寫不出來。卡關的過程才是備審裡有價值的東西，
成果本身反而不是。你三個月後不會記得當時為什麼卡住。

**「記下他們卡住的地方，不是他們的稱讚」**——朋友說「很酷」對你沒有幫助。
你要的是他在哪一步停下來、皺眉、問你「這個要怎麼用」。

## 任務表

| 階段 | 任務 | 目標完成日 | 狀態 | 卡關與筆記 |
|---|---|---|---|---|
| Step 1 定義問題 | 寫下你觀察到的問題，一句話 | 第 3 天 | | 注意是問題不是解法 |
| Step 1 定義問題 | 說明這個問題現在怎麼被解決、哪裡不夠好 | 第 5 天 | | |
| Step 1 定義問題 | 確認這是別人也有的問題，不只是你自己 | 第 7 天 | | 問三個人 |
| Step 2 定義 MVP | 列出所有想做的功能，然後刪到只剩一個 | 第 10 天 | | |
| Step 2 定義 MVP | 寫下「做完長什麼樣」的驗收條件 | 第 12 天 | | 沒有驗收條件就不會完成 |
| Step 2 定義 MVP | 估這個 MVP 要幾天；超過兩週就再砍一次 | 第 14 天 | | |
| Step 3 做第一版 | 完成 MVP 第一版 | 第 35 天 | | |
| Step 3 做第一版 | 每次卡關當下就記一筆：卡在哪、怎麼解的 | 持續 | | 事後補寫一定寫不出來 |
| Step 3 做第一版 | 留下過程截圖或 commit 紀錄 | 持續 | | 這是備審的佐證 |
| Step 4 外部反應 | 找三個真實使用者試用 | 第 42 天 | | 不要只找朋友說好 |
| Step 4 外部反應 | 記下他們卡住的地方，不是他們的稱讚 | 第 45 天 | | |
| Step 4 外部反應 | 依回饋改一輪 | 第 52 天 | | |
| Step 5 可展示 | 寫 README（用 README 公版那份） | 第 56 天 | | |
| Step 5 可展示 | 補一張截圖或 Demo 連結 | 第 58 天 | | 最常被略過、也最有效 |
| Step 5 可展示 | 寫一段「我以為 X 但發現 Y」的反思 | 第 60 天 | | 用反思引導那份 |

天數是建議節奏，不是規定。兩個月做完一個能展示的小東西，比半年做一個做不完的好。

## 用完接哪裡

- 完整流程說明：`/pages/resources/side-project-from-zero.html`
- 怎麼寫 README：`/pages/resources/readme-guide.html`
- 反思怎麼寫：`/pages/resources/reflection-in-portfolio.html`

---

*模板由 TBD Studio 提供 · tbd-web.vercel.app*