在 Threads 看到 @nick.reading2022 分享一張 Life of a Developer 的圖，我覺得很有意思。
那種花了很多時間累積能力，突然看見工具可以幫忙完成一部分工作的落差，很容易讓人停下來想：接下來，我的價值在哪裡？
原貼文與圖片把討論帶向問題定義、判斷與對結果負責。我往下看，也看到不同的提醒：工具熟練不等於基礎能力；有些責任原本就和 PM、系統設計重疊，不能一句話全部交給工程師。
我反而覺得，這些不同的聲音讓討論更完整。
我喜歡那張圖帶來的提問，但不會把它當成能力高低的量尺。它是觀點示意，不是工程師價值的實證曲線。能生成程式，也不代表理解程式已經不重要。
只是，從企業工作的角度，我還想多問一句：功能做出來之後，公司接得住嗎？
拿改預約時間這件事來想。
假設客戶可以在畫面選一個新時間，按下確認，系統顯示修改成功。看起來很順，也很容易覺得事情完成了。
但原本安排的人員有沒有收到通知？新時段真的還有位置嗎？如果需要補差額，誰處理？現場同事看到的，會不會還是舊名單？
這些事不一定出現在那顆按鈕上，卻決定了按下去之後，是少一件工作，還是多一場混亂。
想到這裡，我也提醒自己，看到一個漂亮、能操作的版本，先不要太快說完成了。
如果我是要接手的同事，我希望有人和我走過一次：正常的時候怎麼做，失敗的時候又怎麼辦。不是直到客戶問起，才發現大家對完成的理解都不一樣。
所以，比起立刻加下一個功能，我會想先把這件小事走完。
找實際處理預約的人，用一個不含個資的例子，從客戶提出改期，一路走到現場確認。看看哪些資訊要更新、誰需要知道，哪些情況不能直接答應。
再一起講清楚，什麼才算改期完成。
不只是畫面跳出成功，而是新安排確實成立、舊安排正確釋放、相關的人收到可核對的資訊。如果中間失敗了，不能只留下成功的畫面；要讓負責的人看得到，也有補救的方法。
可以先在測試環境試正常改期、時段已滿、通知失敗這幾種情況。每種情況預期看到什麼，由使用部門和工程端一起確認。先把一段工作驗證清楚，再決定要不要擴大使用。
做到這裡，才比較有辦法知道，這個功能究竟幫上了什麼忙。
但我不希望「對結果負責」，最後變成把所有問題都丟給工程師。
業務需要把客戶的期待與承諾說清楚，使用部門需要帶出真正在做的工作與例外，主管需要決定取捨。工程師則需要能提出限制、說明風險，並且有時間驗證，而不是等大家答應完，再負責想辦法接住。
如果不能決定範圍、不能拒絕不合理的期限，卻要承擔所有後果，那不是我想像的共同負責。
我也不覺得答案是從此只要會講需求，不必理解技術。要知道資料為什麼不一致、錯誤可能藏在哪裡，仍然需要有人真正理解系統。那些基礎不會因為畫面更快出現，就自動變得多餘。
對我來說，比較值得把握的，是有機會更快做出第一個版本時，能不能把省下的時間，留一些給這些原本沒談完的事。
我欣賞的合作方式，是有人願意把不懂的地方問清楚，把不能答應的地方講明白，再一起把事情做完。不必每個人什麼都會，但不能每個人都只做到自己那一段。
到最後，我想看的不只是螢幕上多了一個功能。
而是使用它的人，真的少了一次追問、少了一次重做；遇到問題時，也不用再猜該找誰。
延伸閱讀與致謝：@nick.reading2022 原貼文與圖片・作者延伸・關於責任分工的討論・關於基礎能力的提醒
如果你也在整理公司裡值得改善的一段工作，可以從工作診斷開始。
文章主題