從開發走向管理及規劃 — 工程師的自我修養

「軟體正在吞噬世界」這句話出自 Netscape 創辦人 Marc Andreessen，十幾年下來很精確的描繪了資訊產業的迅猛發展及對其他領域的滲透性。

站在軟體工程師的角度，除了選擇持續專注於技術上，也可以試著跨出去、試著接觸非工程的任務。本次講座以工程開發為起點，分享走出到管理及更大範圍的規劃遇到的點滴及相關的挑戰。

如果您對於以下議題有興趣，歡迎一起在線上聊聊

1. RD 跨到 Tech Lead、PM 到 BD 有哪些事情需要注意？
2. 哪些工程本位的思考對自己可能是有害的？
3. 如何保持健康且具有持續性的學習心態？
4. 軟體工程的訓練有哪些高價值但容易被忽略的部分？

Transcript

1. 從開發走向管理及規劃 工程師的自我修養 SAM HUANG
2. AGENDA 01 02 03 04 05 背景介紹 工程師的價值地圖 從工程師出發 AI 時代的挑戰 結語
3. 背景介紹
4. 顧問諮詢：協助技術佈局及相關規劃 開發協力：協助產品開發及後續維運 商模合作：協助擴展及增強商業模式 忻旅科技：一站式軟體系統規劃開發 Web App IoT Blockchain Cloud AI
5. 多技術觀點 Web / APP / IoT / Blockchain / AI 多領域經驗 接觸超過 10 個領域 多合作形式 顧問 / 開發 / 維護 / 優化 顧問規劃：領域 x 架構 x 應用
6. 開發 / 顧問 / 營運 工程師。碰過嵌入式系統、Linux / Android 、sensor 及 audio ，而後 APP 、Web 、雲端及一點點區塊鏈。 開發外亦協助技術顧問、團隊管理及產品設計，曾在多間 公司擔任技術長及技術顧問。參與超過 60 個專案、產品 開發，橫跨旅宿、金融、教育、印刷、電商、醫療及電信 等多個領域。 Sam Huang https://www.sam-huang.info/ MOPCON 2022 Panel - 談區塊鏈的意義、現況及未來 MOPCON 2022 Keynote - 從 IoT 到 Web2 ，從 Web2 到 Web3 : 那些開發路上的奇妙風景 JSDC 2021 - 從 React Native 跨屏開始的多領域開發歷程 AWS 案例分享
7. Timeline 2004 2024 台大資訊系 / 所 Garmin 忻旅科技 / ... PC → NB → Smart Phone → Tablet → IoT → AIoT → ? Web → Mobile → IoT → Big Data → Blockchain → AI → ? 不變的是變化，變化中什麼不變？ Engineer / PM / BD / Marketing
8. 工程師的價值地圖
9. 工程師的價值 是什麼？ 只是開發？
10. 破題：底層邏輯的建構 彼得原理： 在一個等級制度中，每個職工趨向於上升到他所不能勝任的地位 彼得反轉原理： 一個員工的勝任與否，是由層級組織中的上司判定，而不是外界人士 → 外在刻度不好找，很難客觀 經驗是生存者偏誤 整合跨界是外行領導內行 Open-minded 是保留被說服的可能
11. 技術變化真的快！ 需求變化似乎沒那麼快，但技術的發展卻告訴我們 很多解法 第一個網頁出現到今天大概 12000 天 即使追溯到最原始的也才 20000 天 技術推著我們走 網站、手機、APP 、IoT 、大數據、區塊鏈、 AI 、... → 被推著走也未必是壞事，結合廣告及新型態的互動 往往可以走出新的路
12. 軟體工程？ 軟體工程在實務上有時候是自然科學跟社會科學的結合 技術討論 + 技術管理 + 人事管理 + 專案管理 + 時間管理 + ... 和其他生活中常感受到的工程也不太一樣 同一時間存在許多工法，而且都是對的 個體能力強弱差異極大，差異可以到數十倍， 甚至跟經驗無關 能改良自身常用工具，厲害的人善於改造開發環境 一旦失敗很常什麼都沒有，幾乎沒有回頭路
13. 好的工程師？ 工程師思維的價值 設立目標 / 評估 / 找方案 / 解決 / 反饋 關鍵在於循序漸進的方法論 junior / senior / manager 解決具體問題 / 解決完整問題 / 重新定義問題 舉例：網站太慢 改寫演算法 / 分析頁面結構及架構 / 是否需要回到整體去思考
14. 實務開發可能像什麼？ 與其說像蓋房子，倒不如說像在編給一般人看的工具書（如字典） ➜ 聽需求 → 寫程式碼 → 用工具編出軟體 → … 有很多不同流派的寫法，還要配合用戶的習慣 不同編輯有不同養成方式 書籍不斷在更新 新舊交接是個問題 確實存在分模組的概念，但還是會互相影響 每個做法都是對的，最後才知道答案 特例跟通則？ ...
15. 真實世界問題是什麼? 長期系統開發目的是追求可持續性：當問題定義清楚，其實解法可能有限 （工程和研發不同，多數人是在做工程） 更大一個圈：再次發現問題 上面案例：慢是問題嗎 管理 / 人事 / 資源 / 時程 / 大目標 / 小目標 鬆綁問題領域的過程 / 從模糊中找精確的過程
16. 過度優化？ 某些優化本質就是打破規則及邏輯 (ARM 課程一堆 tag) 如果說“ 聰明” 是一種讚美，那麼這就是 programing 。如果說“ 聰明” 是 一種指責，那麼這就是 engineering 。 best practice != 完美 不要一直抽象（workaround 有時是好的) 不要期待別人能理解你 設好中間點（課程的計時） 避免工程壞習慣
17. 開發者在意的是 … 重點在技術 工具：如程式語言 範式：如何演算法 目的：想要達成什麼結果 有經驗的開發者在意的是 … 重點在不確定性的管理 流程：如思考流程 角色：你該在意什麼？你負責了什麼？ 維度：這問題存在嗎 / 這問題是怎樣被定義的 / 這個解法是怎樣被表述的 討論執行 vs. 注重結果 調整關注點
18. 從工程師出發
19. 落子無悔 + 反映現實 穿越不確定性：工程上怎麼做？ 決策基於證據 目標設定明確 不預期超線性的成長 根據需求進行重新評估 RD → PM / Tech Lead / BD 當問題不明確：取捨的藝術
20. 描述問題的能力：接收其他領域的需求持平敘述 釐清用戶的真實需求及平衡：展場互動屏幕系統 你們能不能在 windows 電腦上寫資料庫 任務：轉譯成你能做的方向 → 沒有最好方案 需求的權衡 環境網路不好 / 開發團隊效益 / 其他效益 更新情形：持續更新 → 行程表及先期驗證 → 告知及推銷方案的優劣是當責 RD → PM(SENIOR RD)
21. 知道其他領域需求但要回到工程本身( 技術顏色要深一點) 工程目的在於解決問題：拉亞 菜單的結構 用技術架構來解決行銷問題 強前端彈性 / 平後端架構 RD → TECH LEAD
22. 回到工程本身後理解這技術不是全部，只是整體的成 敗輔助：整件事情負責 將技術變成產品：HiPrint 如何產品化 … 追求產品能銷售，才能討論賣得好 控制產品走向確保市場驗證，懂得說 No 工程：特化 / 公版 / 合流 … 哪些是最大公 因數（plugin 弭平業主和客戶的利益衝突） 如何讓目前能夠推廣 … 找尋最大的利益權衡 RD → BD
23. AI 時代的挑戰
24. AI 取代 junior engineer / Google 25 % 程式碼是 AI 寫的 / ... → 切身在意的到底是什麼 ? prompt engineer ? 工具造成工作型態及習慣不同是常見的 第一批面對電腦的打字機員工 Google 出現造成的影響 smart phone vs. 黑莓機 → 問題應該是在於找到合作的模式 → 透過 AI 替自身賦能 這是個喧鬧的時代
25. 建構屬於自己的閱讀及吸收資訊的方式 → 透過 AI 統合各種技術的做法 舉例：閱讀技術文件 跨越圈子之後問題變得越加複雜，透過 AI 縮減成本、產生新解法或重拾舊解 法 → 透過 AI 使既有的高成本做法變得可行 舉例：梳理複雜舊資料 功夫在詩外
26. 結語
27. 資訊理論中的熵 ≅ 亂度 ≅ 不確定性 ≅ 資訊量 工程師思維已經是一個堅實的起點了 量度的標準 持續前進
28. https://www.revtel.tech https://lin.ee/Qg2AUocY https://www.sam-huang.info/ THANK'S FOR LISTENING