今天想聊聊一件我一直很在意的事。

Day 7 我寫到那個警語，我以為在表上寫一行「之後修改不列入紀錄」就能解決問題，結果還是有人回去改。

寫那篇的時候我一直在想一件事，如果當時旁邊有一個人，看到我的設計之後說一句「那如果他還是改了呢？」，我大概當場就會知道這個方法行不通。

但沒有那個人。

一個人做專案，最大的風險是一個人

我一開始以為，一個人做的主要問題是慢、是做不完，是排不完的需求。

後來發現不是，做不完最多就是晚一點，而且我可以自己決定先做哪個。

但真正的問題是，我下的這些判斷沒有一個會被別人看過。

我收需求、我判斷要不要接、我訪談、我畫流程圖、我決定哪一步自動化哪一步不自動化、我寫程式、我測試、我上線。這條線上的每一個環節都是我，中間沒有任何一個地方，會有另一雙眼睛。

沒有人 review，實際上會發生什麼事

一、我的盲點會直接變成系統的盲點。

我想不到的事情，系統就不會處理，而且不會有任何跡象，因為我根本不知道那裡有東西要處理。警語那件事就是這樣，我不是漏掉了，我是想到了但想歪了，而想歪的東西光靠我自己根本抓不出來。

二、錯誤最後都是在上線之後才被發現。

而上線之後是成本最高的時候，資料已經跑出去了、信已經寄給真人了、大家已經照著做了。如果有人在設計階段花十分鐘看一眼，那十分鐘可以省下事後的好幾天。

三、沒有人會挑戰我的前提。

列出這點總覺得自己特別M，但真的很重要，因為同事給的回饋大多是「這個功能可不可以改成這樣」，很少有人會問「你為什麼要做這件事」，如果我假設的前提錯了，就無法解決到真正的問題，後面做得再好都是白做。

四、我不知道自己做得好不好。

沒有參照對象，我寫出來的東西是不是一種糟糕的寫法？這個流程設計在別人眼中是不是很怪？我沒有基準線，只能靠「它有沒有跑起來」來判斷，但 跑得起來跟做得好，是兩件不同的事。

現在還不完整，但總比沒有好

意識到這件事之後，我開始有意識地去找一些「可以代替 review 的東西」，雖然它們都不完整，但總比沒有好。

把流程圖攤在需求方面前。

我在 Day 2 說過，畫流程圖常常會抓出雙方認知不一樣的地方，對我來說，那其實就是一種 review，只是被 review 的不是我的程式，是我對這條流程的理解。

把 demo 做快一點、醜一點。

早一點拿出去，就是早一點讓現實幫我檢查。一個做了兩週才拿出來的完整版本，如果方向錯了，那兩週就沒了。

問 AI。

AI 可以幫我看程式、找邏輯漏洞、告訴我某個寫法有什麼問題，這部分它很有用。

但它有一個很根本的限制，我問它什麼，它就答什麼。

它不會主動問我「你為什麼要做這個功能」，也不會知道我們公司的主管有拖延的習慣、人資其實很在意某件事、那個部門的狀況比較特殊。它可以 review 我的程式，但沒辦法 review 我的判斷，因為判斷的依據不在程式裡，在我腦袋裡的那些現場。

工程師會看我的程式。

我做完 demo 之後由工程師幫我部署上線，這個過程他會看我的程式，這也是唯一一個真的懂技術的人在檢查我的環節。

但他看的是程式，不是流程。

他不會問我「這一關為什麼要等所有人都填完」、「為什麼這一步要留給人做」、「這個提醒為什麼是兩次不是三次」。這不是他的問題，他不在那些會議裡，不知道人資為什麼會那樣做事。要 review 流程，得先知道這條流程為什麼長成那樣。

然後我發現一件事。

AI 可以檢查我的程式，工程師可以檢查我的程式，我能找到的 review 全部集中在同一半。

而這一年下來我最常出錯的地方，從來都不是程式。

還是靠自己吧！

前一篇我寫到一個發現，我為人資做了控制面板，讓他們看得到進度，但我從來沒有想過，填寫的人也需要看到自己的進度。

那個專案是在上半年做的，而我是在寫這個系列、寫到第八天的時候，才想到這件事。

中間隔了好幾個月，我沒有想到，當然也沒有人跟我說。

這三十天就是我在替幾個月前的自己 review。

強迫自己把每一個決定寫成一句話、說清楚當初為什麼那樣選，本身就是一種檢查，也是一種進步～

所以該怎麼辦？

老實說我現在還沒有解法哈哈哈

我能做的大概是這幾件事，把判斷寫下來而不是只放在腦子裡、把東西早一點拿給人看、以及承認「沒有人檢查過」這件事本身就是一個風險，在做比較重要的決定時多停一下。

但這些都只是減輕，不是解決，一個人做專案，這件事本身就是一個結構問題。