具備產品思維的工程師的建議開發流程？
放掉自己的面子，走向巨人，然後站在巨人的肩膀
不知道為什麼，任何時候對於調整自己都覺得沒什麼大不了，我自認是水，我可以成為任何形狀，唯獨工作上對於「承認自己目前的做法是有問題的」的這件事特別苦手。
是莫名放不下的自尊？又或是覺得如果從現在要重新開始學會有陣痛期怕大家又走得更遠了？又或是不想觸碰那個重新學習的脆弱？
最近有一個功能走進了死胡同，沿途覺得開發都很不舒服，但自己不知道問題在哪；昨天嘗試跨過心魔向主管詢問，結果發現我從一開始 mindset 就錯了。
// 當我要開始執行前，先掌握現況是重要的 //
除了最一開始要先理解產品需求之外，最主要的重點是要盡可能地全面掌握即將要修改的功能的全貌，除了 API 文件之外，還有現有功能的流程，再嘗試思考解決方案。當看到一個黑影就跳入之後可能會需要來回修改，尤其是發現有沒有想到的地方可能就需要全盤丟棄。
妳目前做法比較像是 try & error 打個比方你現在要修汽車的輪子 妳因為心裡比較慌張沒有底 可能拿到地上有看起來可以的輪子就拿起來裝裝看 但是你沒有先看你要修的是什麼車 什麼品牌 匹配的輪子又有哪些選擇 優缺點是什麼
索性約了另外兩個同事想要了解他們的做事方式，同時也想知道自己的盲點，今天跟其中一位聊完，更全面地知道了具備產品思維工程師的「做事方法」。
這才認知到之前在第二間公司的時候工程師是被寵壞的。我們有優秀的產品經理，也有優秀的測試人員，幾乎只需要看著文件產 code 就好了，結果當我到了這間公司需要一條龍地處理所有事情的時候全部爆掉ＸＤ我們要從前面的理解產品需求，到產出解決方案，到後面測試，到上線——是到現在才血淋淋地發現，我的方法不可行需要打掉重練。
以下是建議的開發流程：
- 看既有的行為 / 邏輯看過（每一個呼叫的地方、UI 的操作、使用者流程、發生順序、edge case）
- 重點是知道「目前的操作是不是都搞懂了」，盡可能提升掌握度，才能夠在後續修改的時候降低預期外的問題發生率
- 註：這裡可能是花最多時間的地方
- 提出來討論解決方案
- 加上類型 + 欄位（加上解決方案後的樣子、行為）
- 想技術方案
- 寫扣
- 做了之後如果發現不可行（這裡可能會覺得放棄很可惜、產生進退兩難的心情），果斷動手去嘗試第二種（觀察優缺點）
- 測試
盡可能 5 或 8 以上的卡都這樣寫過，前期訓練過後累積起來的東西能夠提升掌握度，code review 的時候也更能講出東西
讓我想起日本列車員會有指差確認的概念，透過身體的各個感官並用協調，來增加操控器械的注意力的安全動作方法
這一套就是我的指差確認，持續練習來提升我的產出品質 ✨
總之 先不要急著寫 code 欲速則不達 妳要先了解你在面對什麼 還有發現自己鑽牛角尖了 主脈絡有缺 就趕緊跳出來 不要糾結在那裡 想說 哇這樣進度不就倒退了嗎 這樣是不是來不及
如果有天你練就了 追程式碼就可以把 UI的行為猜得七七八八 妳就進到下一個階段了 就是看code 比看文字輕鬆
有人問真的太好了ＱＡＱ
以下附上 NotebookLM 的會議記錄摘要
功能開發流程討論會議記錄 時間：2024/10/9 參與人員：力哥、我 主題：討論如何更有效率地進行功能開發，以 API 改版功能為例。
會議內容摘要：
一、 現階段遇到的問題：
在進行 API 改版功能開發時，我直接從 API 文件著手，看完文件後直接開始寫程式碼，導致開發過程中遇到許多預期外的問題，需要不斷回頭修改，浪費了許多時間。 對於如何將 API 文件中的改動轉化為具體的開發步驟和影響範圍感到困惑，不知道如何撰寫清楚的 PRD 文件。 在開發過程中遇到問題時，不確定應該找誰討論，擔心會驚動到太多人。
二、 力哥提出的解決方案：
採用更完善的軟體開發流程：建議我採用更完整、線性的軟體開發流程，盡量避免開發過程中不斷回頭修改，才能提高開發效率。
步驟一 (文件分析)：仔細閱讀 API 文件，了解 API 的變更內容，包括新增、 刪除、 修改的欄位和參數等。 步驟二 (現有邏輯分析)：分析現有系統的程式碼和操作邏輯，了解 API 改版會影響哪些部分。 步驟三 (預期行為定義)：根據 API 改版內容和現有系統邏輯，定義出 API 改版後預期的系統行為，包含不同情境下的操作流程和頁面呈現方式。 步驟四 (解決方案討論)：將預期的系統行為整理成文件，找 PM 和相關工程師討論，確認功能設計的合理性和技術可行性。 步驟五 (技術方案設計)：根據討論結果，設計技術方案，並再次確認技術方案的可行性。 步驟六 (程式碼撰寫)：開始撰寫程式碼。 步驟七 (測試)：進行程式碼測試，確保功能正常運作。 加強需求釐清：在開始寫程式碼之前，花更多時間釐清需求，才能確保開發方向正確，避免做無用功。 可以使用 PRD 文件來記錄 user story 和 use case，並盡可能將 use case 思考完整。 在釐清需求的過程中，可以隨時找 PM 或其他相關人員討論，確認自己的理解是否正確。 善用團隊資源：在開發過程中遇到問題時，不要害怕尋求幫助，可以找 PM、 工程師或設計師等相關人員一起討論解決方案。 對於功能需求相關的問題，可以找 PM 討論。 對於技術方案相關的問題，可以找工程師討論。 對於UI/UX相關的問題，可以找設計師討論。
三、 後續行動方案：
我會嘗試使用力哥建議的開發流程，並加強需求釐清，盡量在開始寫程式碼之前就將所有細節都想清楚。 在開發過程中遇到問題時，我會積極尋求團隊成員的幫助，並將遇到的問題和解決方案記錄下來。 我會嘗試自己撰寫 PRD 文件，並在下次會議中與力哥討論。
四、 力哥的建議：
養成良好的開發習慣：雖然完整的開發流程看似繁瑣，但長期下來可以幫助我提高開發效率，減少錯誤發生。 不要害怕犯錯：每個人都會犯錯，重要的是從錯誤中學習，下次才能做得更好。
五、 心得：
經過這次與力哥的討論，我更加了解到完整軟體開發流程的重要性，也學習到如何更有效率地進行功能開發。 我會努力將力哥的建議應用到日後的開發工作中，並持續精進自己的開發能力。
（擅自幫我打心得的部分wwww）