上一篇寫到，當開發速度開始變快之後，很多以前不值得投入的需求，可能會慢慢有機會被做出來。這幾天繼續想下去，我反而開始回頭看我們以前很習慣的一整套開發方式。需求提出來之後，先分析、寫規格、確認流程、排時程，再進開發、測試、驗收，這些事情做了這麼多年，大家都覺得很正常。
以前這樣做其實有很現實的原因，因為做錯很貴。
一個需求如果三個人做了一個月，最後才發現使用者真正要的不是這個，前面的時間幾乎就浪費掉了。所以大家會希望在開始寫程式之前多確認幾次，畫流程圖、寫規格、開需求會議，最好能先把大部分事情想清楚。規格改一次，後面可能就是資料庫、程式、測試全部跟著改，開發到一半才改方向，對以前的專案來說真的是一件很麻煩的事情。
可是當第一版可以很快做出來之後，這個邏輯可能會開始有點不一樣。
有些需求光靠會議其實很難講清楚。使用者說他想要一個畫面，我們畫了流程、寫了規格，大家都說沒問題，真的做出來之後他才發現自己原本想的不是這樣。這種事情以前很常發生，只是因為開發成本高，我們總是希望前面盡量講清楚。現在如果半天就能先做出一個簡單版本，讓使用者真的按幾下，也許比開三次會更容易確認方向。
這讓我開始懷疑，有些我們以前很堅持的流程，到底是因為那真的是最好的開發方法，還是因為以前做錯一次的成本太高，所以不得不這樣做。
當然，我不是覺得需求分析可以不要了。企業裡面的系統牽涉到資料、權限、流程跟其他系統，很多事情還是不能想到什麼就直接做。只是以前我們很習慣把「先想完整再開始」當成理所當然，未來可能會變成有些事情先做到可以驗證的程度，讓實際使用的人碰過，再決定值不值得繼續往下做。
做錯了就丟掉，這句話以前在企業系統裡其實很難講，因為丟掉的可能是幾個星期甚至幾個月的人力。當試錯成本變低之後，有些東西也許真的可以允許自己做錯。
另外一個變化，是做軟體的人可能也不再只有 IT。
以前公司裡有人想做一個工具，通常第一個想到的就是找資訊單位。需求排進來，IT 評估有沒有人、有沒有時間，再決定什麼時候做。現在開始出現另外一種情況，有些人自己就可以先做出一個東西。可能是懂一點程式的人，也可能根本不是工程師，只是很清楚自己的工作，每天哪些資料要整理、哪幾個步驟一直重複，就透過 AI 慢慢把一個小工具做出來。
我其實不覺得這是一件壞事。
很多部門自己的工作細節，IT 不可能比使用者更了解。如果一個人可以很快把自己的想法做成一個小工具，先解決每天很麻煩的事情，對企業來說反而是好事。過去很多需求排不到，某種程度也是因為所有東西最後都塞到同一群人身上。
只是這件事情再往下走，IT 的工作可能就會開始改變。
以前比較像是「你有需求，我幫你開發」，以後有一部分可能變成「你可以自己做，但我們要一起決定哪些事情可以這樣做」。有些只是個人的小工具，也許沒有太大問題；一旦開始碰正式資料、共用帳號、跨系統、客戶資訊，或者一個工具慢慢從三個人用變成三百個人用，事情就完全不一樣了。
原本只是自己方便的一支小程式，哪一天變成大家每天都依賴的工具，誰來維護？做的人離職了怎麼辦？資料算錯了誰負責？權限開太大要怎麼處理？這些問題以前也有，只是以前大部分系統從一開始就在 IT 的管理範圍裡。當未來公司裡可以做軟體的人變多，這條界線一定會越來越難畫。
工程師本身也會碰到類似的改變。
如果以前需要五個人完成的工作，未來兩個人加上 AI 就可以做到，那公司會不會就不需要那麼多工程師？我覺得這個問題現在還太早下答案，但至少工作的內容一定會變。以前很多時間花在把需求真的寫成 Code，當這一段慢慢被壓縮，工程師可能會花更多時間在理解別人做出來的東西、處理共用架構、整合、資料、安全，以及判斷哪些東西可以自己做，哪些東西一開始就應該用正式系統的方式處理。
想到這裡，我覺得 AI 對軟體開發真正有意思的地方，可能不只是工程師可以快多少。
它可能正在把原本很清楚的分工慢慢打散。
需求誰來定義、Prototype 誰來做、什麼時候才需要 IT、什麼東西可以先試、什麼東西從第一天就不能亂試，這些以前比較固定的界線，接下來可能都要重新調整。
做軟體二十年，我以前很自然地認為，需求進來之後就是照一套方法把它變成系統。現在開始覺得，未來可能連「誰來做」跟「怎麼開始做」都不一定還會跟以前一樣。
這件事情如果真的發生，改變的就不只是 Coding，而是企業原本怎麼生產軟體這件事。