AI 都會寫程式了,我還要學什麼?——從「做得出來」到學會開發的 30 天

本系列文章・3/25

第 1 章|實作跑在理解前面

  1. Day 1|做得出來,卻完全改不動
  2. Day 2|當實作跑得比理解更快

第 2 章|第一個產品:從做功能,到開始理解工作

  1. Day 3|功能是從觀察和許願長出來的目前閱讀
  2. Day 4|如果所有事情都能交給 LINE 機器人就好了
  3. Day 5|做自己的系統,不代表什麼都要自己做
  4. Day 6|把反覆確認的工作交給系統之後
  5. Day 7|一句「平常都這樣做」,後面藏了多少事情?
  6. Day 8|沒有告訴 AI 的事
  7. Day 9|系統知道怎麼做,不代表使用者就該這樣做
  8. Day 10|我以為功能做完,產品就完成了
  9. Day 11|看到 n8n 時,我以為找到做預約系統的方法了

第 3 章|第二個專案:理解工作的能力開始變成工程判斷

  1. Day 12|原來我在做翻譯
  2. Day 13|聽他怎麼說,也看他怎麼做
  3. Day 14|我開始能從工作流程看見系統需要做什麼
  4. Day 15|我開始能從工作流程看見產品應該如何被使用
  5. Day 16|以終為始:思考產品功能
  6. Day 17|從「這個功能怎麼做」開始看懂系統怎麼分工
  7. Day 18|系統分工之後,怎麼讓不同部分一起工作
  8. Day 19|把「為什麼這樣決定」也留下來
  9. Day 20|從「我要這個功能」到「系統必須保證什麼」

第 4 章|AI 寫大量程式後,我怎麼理解、判斷與相信實作?

  1. Day 21|我幾乎不讀程式碼,那我是怎麼理解系統的?
  2. Day 22|從理解工程概念,到形成自己的判斷
  3. Day 23|我已經能沿著系統思考,卻還不能沿著程式碼追問題
  4. Day 24|我不逐行讀程式碼,那我要怎麼知道 AI 做對了?
  5. Day 25|用測試約束 AI 改程式

Day 3|功能是從觀察和許願長出來的

本篇目錄
  1. 每多懂一段工作,我就會開始許願
  2. 「更方便」不是只有一種答案
  3. 需求和實作常常離得很近
  4. 功能就是這樣一個一個長出來的

現在回頭看,我第一次做諮商所預約管理工具時,花很多時間做的事情,並不是列:

「這套系統應該有哪些功能?」

而是不斷跟已經開業的心理師朋友確認:

「你們現在到底怎麼工作?」

我自己長期使用諮商服務,所以最開始已經有一些個案端的經驗。

我知道自己在使用服務時,哪些地方覺得方便,哪些地方曾經想過:

「如果可以再簡單一點就好了。」

平常到諮商所時,我也會看到一些櫃檯需要人工處理的事情。

但真的開始做產品之後,我才需要繼續往裡面問。

一個預約進來之後,是誰處理?

心理師的時間怎麼確認?

哪些事情需要人工聯絡?

資料現在放在哪裡?

這件事情處理完之後,還需要通知誰、留下什麼?

每多懂一段工作,我就會開始許願

這裡說的「許願」,不是請對方開一張想要的功能清單。

比較像是,我知道某件工作現在怎麼進行之後,就會開始想:

如果這一步不用每次手動做呢?

如果同一份資料原本要輸入兩次,可不可以只做一次?

如果一件事情完成之後,每次都還要另外通知另一個人,可不可以讓系統接著處理?

如果資訊本來就分散在行事曆、試算表或其他工具裡,有沒有可能減少人工搬來搬去?

很多功能就是這樣長出來的。

不是我先坐下來想:

一套預約管理工具應該有 A、B、C、D。

而是:

先看到一段工作,再想像這裡有沒有可能少一步。

接著才把這個想法拿去跟 AI 討論。

「更方便」不是只有一種答案

做到後來,我也發現:

同一件事情,站在不同位置的人,看到的問題不一樣。

我曾經想過,把行動心理師支援報備登記這類功能做得完整一點,讓心理師更方便管理自己的行程。

站在心理師的角度,這當然很合理。

自己的行程更清楚,也可以少一點人工聯絡。

但站在諮商所經營者的角度,心理師端很好用,不一定就是現在最重要的事情。

經營者更在意的可能是:

整體預約有沒有變順?

行政工作有沒有減少?

不同角色之間的工作有沒有因此接得更好?

同樣都叫做「預約」或「行程」:

個案看到的是自己的服務體驗。

心理師看到的是自己的工作安排。

經營者看到的則是整間諮商所的行政運作。

他們不是在使用三套完全不同的產品。

很多時候,只是站在同一條流程的不同位置。

這也讓我開始知道,一個功能就算真的有用,還是要繼續問:

它現在是在替誰解決什麼問題?

需求和實作常常離得很近

我當時沒有先完成一份完整需求文件,再交給另一個人實作。

比較常發生的是:

先弄懂一段工作。

想到一個改善方式。

接著就直接跟 AI 討論:

這個可以怎麼做?

需要哪些資料?

原本正在使用的工具能不能直接接進來?

做到一半,又發現還有事情沒問清楚,再回去補理解。

所以「理解現場」、「形成一個功能想法」和「開始實作」,對我來說常常靠得很近。

AI 讓這個距離更短。

一個「如果可以這樣就好了」的想法,很快就能進入實作。

但也因為太快,我很容易先問:

能不能做?

而不是:

值得做到什麼程度?

功能就是這樣一個一個長出來的

所以現在回頭看第一個產品,我不太會說那些功能是一開始就被我完整「設計」出來的。

它們比較像是從現場工作裡一個一個長出來。

先看到有人真的這樣做。

再開始想:

如果這裡可以少一步呢?

如果這份資訊不用再搬一次呢?

如果前一步做完,後面的工作可以自己接起來呢?

然後再把這些想法交給 AI,一點一點變成真的功能。

功能,是從觀察和許願裡長出來的。

返回系列總覽 →