[閱讀心得] 鯨游藍海
Published in
Jan 24, 2023
鈦坦科技的敏捷之路
小步快跑，持續試錯
運用敏捷，改造組織這是一本新加坡商 — 鈦坦科技 說明其從創辦公司至今的歷程。如果你在軟體界工作，應該都聽過這間公司，雖然你的業務可能跟它們沒關係，但只要知道「敏捷」這兩字的工程師，也不管你的工作有沒有真的實行敏捷的開發方式，至少要知道這間公司 : 鈦坦科技。
本書提到了鈦坦在初期的工作到後來規模擴大，如何管控逐漸增加的人力分配與工作流程，從一開始純工程師只想到把產品開發好的思維到後來不得不面對管理流程的需求，如何增加自己的管理思維以及做法，都是許多新創公司創辦人的共同心聲。
身為一間極力推展敏捷開發的公司，在整本書講了不少過去在推展敏捷遇到的挫折與心得，如何讓同仁、員工、股東甚至到投資人都可以接受這樣的改變，以及當執行時大家所提出的疑惑、抗拒甚至強烈反對，在本書中也一步一步地接露此過程面臨狀況時該怎麼解決。然而在本書中最令我收穫最多的是依據各種狀況所繪出的系統圖，它有點像是流程圖以及SOP，在各種狀態中會有什麼狀態以及預期都直接繪出來，這樣的好處是 … 可以幫助自己在做決策時提供不同思考的可能型態，甚至把圖攤出來就可以直接解講給老闆與同事們聽，讓你的決策推論很有依據。
- 如果你是創業初始，可以參考 : 英雄時期
- 如果你是部門主管，可以參考 : 分地盤時期、SOP 時期
- 如果你是開發者 (前、後端工程師，UX/UX，PM 或是 SM)，可以參考 : SOP 時期
給公司主管
- 創業者就是主動尋求變化、對變化做出反應並將變化視為機會的人
- 雖然名稱是軟體科技公司，然而我們的工作卻包含「服務」。軟體科技公司與軟體服務公司的差別在於 : 前者提供技術，一旦交付便從此與客戶分道揚鑣 ; 而後者不只提供產品，還有提供服務，例如顧問諮詢、系統維護、障礙排除、或是各種臨時而緊迫的需求
- 在產品開發之前，應先培育人才 (Develop people before making products)
- 敏捷的一個基本原則，就是解決用戶痛點，只要可以帶來商業價值就是一個好的功能，而不要一開始就要我做出一個 xxx
- 所有的工具是為了幫助人提升要率的媒介，而非標誌進步的代表，所以當任何物品能最有效地輔助工作，那就是最好的工具
- 如果做教育訓練時，公司擔心的是員工離職，那麼問題不是出在教育訓練本身，畢竟會離職的員工就是會離職。我們該檢視的是 : 除了教育訓練之外，我們是否建構了學習型組織 ? 而讓員工願意繼續在此組織一起進步
給部門主管
- 取消過往由主管考核部屬升遷的規範，改為由員工依必要技能樹自我評量表自主提出升遷申請，再由推薦的團隊成員與其他主管共同評估，決定升遷與否
- 領導，是在想對的事 ; 管理，是把事做對
- 主管應該處理的不是反覆出現的瑣事，而是突發的例外狀況，以及更長遠的戰略規劃
- 產品開發時，如果你直接寫了 xx 功能，那你就把解法限制住了。但是開發應該是依照需求，為了解決問題，而不是直接提供產品
- 會而有議，議而有決，決而有行，行而有果
- 如果真的收到了客戶的緊急需求時，應該由 PO 與客戶溝通，確認需求 — 當確定要插件的話，那麼就要挪動其他幾張 story card 的優先次序，而不要讓客戶以為插件進來，讓原本六張任務卡變成十張任務卡之後，這十張任務卡還可以如期完成
給員工
- 如果一個人一直挑戰自己，一定會遇到一些挫折 ; 如果一直沒有遇到挫折，那表示那個人一直在挑自己能力範圍內的事情來做。這樣當然比較安全，但也可能低估了自己的能力
- 好的敏捷工程師是會不斷追問，釐清目的和需求的細節，逼問出「客戶價值」，徹底釐清了之後才開始動工
- 如果團隊只重視技術層面的開發，不關心產品的規劃與未來，那麼不只是將自己限縮在負責的卡片(工作)上，更容易困在自己的世界裡，與市場、客戶或用戶脫節
- 敏捷開發的節奏 — 小增量、蒐集回饋、持續迭代，這樣的運作方式，會大幅提升開發團隊成員的溝通頻率，無論是與客戶的溝通，或是與團隊成員的溝通
- 「完成定義」(Definition of Done，簡稱DoD) 團隊內先確保成員對產品的完成樣貌具有共識，然後才進入開發流程中，此避免在交接任務或交付產品時出現落差
- Scrum Master (SM) 的任務 : 協助團隊運用 Scrum 達到商業價值，但這個「協助」可能包含很多事，像是教學、引導、教練或跟著團隊一起開發，再根據觀察提出問題之類的，做法非常多元
- 員工必須條列出過去一年的工作成果、學習並運用了那些技能為產品創造價值，在團隊內做了哪些有影響力的事，分享自己做了什麼具體事情可以佐證已達到下一個職等的標準
- 工作本身不會有熱情，是你自己把熱情帶進去的
