寫作 · AI Native 工作法 ·

不到 3 小時做出一個網站之後,我開始反省怎麼提需求

有些需求,不是想清楚了才做得出來,而是先做出來,才有辦法真正想清楚。

文/Eason Kuo · Senior Vice President,國泰健康管理

前幾天趕了一下「島」的流行,做了一個小實驗:試著用 AI 協作,把腦袋裡的一些想法,直接做成一個可以打開、可以操作的網站。

從開始到做出第一個版本,不到 3 小時。

說真的,過程還蠻有成就感的。但做完之後,讓我想得更多的不是 AI 寫程式有多快,而是一個有點不舒服的問題:

以前,我是不是太常讓團隊猜我想要什麼?

我們習慣從「需求」開始

我們過去的工作方式,很習慣從需求開始:先討論方向、釐清需求、畫流程、確認規格,再安排開發。

這些事情都很重要,我到現在也不覺得它們可以省略。但做這個小網站的時候,我發現一件很誠實的事:連提出需求的人,都不一定能在一開始就清楚描述自己真正想要什麼。

包含我自己。

很多想法講了半天還是很抽象。直到看到實際畫面,才突然發現:「欸,這不是我要的。」或是:「等等,原來還可以這樣做?」

以前遇到這種情況,我可能會覺得是需求沒有想清楚,下次要想得更清楚一點。這次自己動手做完,才開始懷疑這個結論。

有些需求,是做出來才想得清楚

我後來的體會是:

有些需求,不是想清楚了才做得出來,而是先做出來,才有辦法真正想清楚。

人對抽象描述的理解,本來就有很大的落差。我說「溫暖一點」,設計師心裡的溫暖和我的不一定一樣;我說「互動要直覺」,工程師想到的可能是另一套操作。這種落差,在會議室裡用語言對齊,往往要來回很多次;放一個畫面在大家面前,常常幾分鐘就看出來了。

當然,我要先講清楚:不到 3 小時做出 Prototype,不代表 3 小時就能完成一個正式產品。資安、資料正確性、系統整合、測試、維運,每一件都需要專業與時間。這些不會因為 AI 而消失。

但如果只是為了確認方向、驗證想法,為什麼一定要等所有規格都寫完,才開始讓大家看到東西?

當第一版變便宜,工作方式也該跟著變

Prototype 變便宜之後,團隊做事的方式大概也得跟著改。

以前我們花很多時間討論:「這個需求到底要怎麼做?」

現在是不是可以更常問:「我們能不能先做一版,讓大家看看哪裡不對?」

這兩個問題差的不只是順序。前者假設我們能在動手前把事情想完整;後者承認我們想不完整,所以選擇用最便宜的方式,盡早暴露理解上的差異。

AI 讓做出第一版的門檻越來越低。但我覺得真正該改的,不是要工程師寫得更快,而是讓 PM、設計、工程師和業務早一點看到同一個東西,早一點發現彼此想的不一樣。

我自己要改的地方

這次實驗最刺到我的,其實是身為主管的部分。

我開始反省,自己有時候是不是太習慣用腦袋裡的想像跟團隊溝通,然後再讓同事花很多時間,把我還沒完全成形的東西做出來。做出來之後,我再說一句「這不是我要的」。

這樣想想,好像也不太合理。

所以我給自己的功課很簡單:

  • 少說一點「這不是我要的」。
  • 多做一點「我先弄一版給你看」。
  • 把第一版當成討論的材料,而不是交付的成果。

最後

當做出第一版越來越便宜,最浪費的反而可能是一直停留在想像裡。

這次不到 3 小時的小實驗,讓我更確定一件事:不是所有事情都要先做完整規劃才能開始。有些事情,先做出來給大家挑毛病,反而更有效率。

挑毛病的人,也包括我自己。