對於新創公司的技術長（CTO）而言，有哪些主要的職責與挑戰？
身為新創公司的技術長，您的職責廣泛且多樣，主要包括：
- 技術策略與架構： 制定公司的技術願景和發展方向，選擇合適的技術棧和架構，以支持產品和業務的發展。
- 團隊建設與管理： 招募、培養和管理工程團隊，建立積極健康的技術文化，提升團隊的效率和生產力。
- 技術流程優化： 設計和實施高效的開發流程、測試策略和部署方案，確保軟體的品質和交付速度。
- 技術債務管理： 識別、評估和管理技術債務，避免其對未來開發和系統穩定性造成負面影響。
- 與其他部門的協調： 與產品、設計、營運等部門緊密合作，確保技術決策與業務目標一致。
- 預算與成本控制： 管理工程部門的預算，有效地利用資源。
- 安全與合規： 確保系統的安全性，並符合相關的法規和標準。
- 技術選型與供應商管理： 評估和選擇合適的第三方工具和服務，並與供應商進行談判和管理。
主要的挑戰包括：
- 資源有限： 新創公司通常資源較為有限，需要在有限的預算和人力下做出最佳的技術決策。
- 快速變化： 市場和客戶需求變化快速，技術長需要保持敏銳的洞察力，並快速調整技術策略。
- 技術債務累積： 在追求快速迭代的過程中，容易累積技術債務，需要有意識地進行管理和償還。
- 團隊擴張： 隨著公司的成長，工程團隊需要快速擴張，如何保持團隊文化和效率是一個挑戰。
- 不確定性： 新創公司面臨諸多不確定性，技術長需要在不確定的環境下做出可靠的技術決策。
如何在新創公司中建立和維護一個健康的技術文化？
建立和維護健康的技術文化至關重要，可以提升工程師的士氣、生產力和留任率。以下是一些關鍵要素：
- 重視業務價值： 確保團隊的工作與業務目標緊密相關，讓工程師理解他們的工作如何為公司創造價值。
- 採用成熟的解決方案： 在可行的情況下，盡量使用現有的、成熟的工具、函式庫和雲端服務，避免重複造輪子。
- 清晰的技術決策過程： 建立透明的技術決策過程，例如使用「請求評論」（RFC）機制，鼓勵團隊成員參與討論和提供意見。
- 編纂工程指南： 編寫並維護工程指南和風格手冊，確保團隊在編碼、測試和部署等方面保持一致性。
- 重視速度，但速度不是策略： 將工程速度作為一個目標，但要制定明確的策略和行動方案來實現這個目標，而不是盲目追求速度。
- 知識分享與學習： 鼓勵團隊成員之間進行知識分享，例如舉辦技術講座、錄製講解影片等，並支持持續學習和技能提升。
- 擁抱持續改進（Kaizen）： 鼓勵團隊不斷反思和改進工作流程和技術實踐，將錯誤視為學習的機會。
- 明確溝通與減少術語： 強調清晰的溝通，避免過度使用內部術語和縮寫，確保所有團隊成員都能理解。
- 建立信任與心理安全感： 創造一個開放和信任的環境，讓工程師敢於提出問題、表達疑慮和犯錯，而不用擔心受到懲罰。
- 重視開發者體驗（DX）： 投資於提升開發者的工作體驗，例如提供易於使用的工具、清晰的文檔和高效的開發流程。
在新創公司中，應該如何有效地管理和處理技術債務？
技術債務是軟體開發過程中不可避免的一部分，但如果管理不當，可能會嚴重影響未來的開發效率和系統穩定性。有效的技術債務管理包括：
- 定義和識別技術債務： 將技術債務定義為那些主動降低當前或未來業務效率或效能的技術決策、實作或細微差別。定期與工程團隊合作，進行技術債務盤點，誠實評估各種類型的債務（例如設計債務、程式碼債務、測試債務、文檔債務等）的程度。
- 量化和分類技術債務： 雖然很難精確量化所有技術債務，但可以對其進行分類（例如輕微、中等、嚴重），並估計修復所需的時間和資源。
- 將技術債務納入規劃： 在短、中、長期技術藍圖中明確規劃償還技術債務的工作。可以撥出一定的開發時間專門用於修復技術債務（例如每個 sprint 的 5-20%），或者將償還技術債務作為日常工作的一部分。
- 持續償還： 根據技術債務對業務的影響程度和修復成本，優先處理那些最關鍵的債務。對於專職負責維護的團隊（例如「雙團隊」模式中的客戶團隊），可以將償還技術債務作為其主要目標之一。
- 避免技術債務破產： 持續監控和管理技術債務，避免其累積到難以處理的地步，導致需要進行大規模的重構或系統重寫。
- 透明化技術債務： 向團隊和管理層清晰地溝通技術債務的現狀、風險和償還計劃，爭取他們的支持和理解。
- 在開發過程中考慮技術債務： 在進行新的功能開發時，要權衡短期交付速度和長期可維護性之間的平衡，避免不必要地引入新的技術債務。
如何制定和維護新創公司的技術藍圖？
技術藍圖是指導技術發展方向的重要工具，它應該與公司的整體業務戰略相一致。制定和維護技術藍圖的步驟包括：
- 了解業務目標： 深入理解公司的短期和長期業務目標，以及產品發展的願景。
- 劃分時間範圍： 將技術藍圖劃分為短期（Horizon One，例如當前 sprint）、中期（Horizon Two，例如未來幾個月）和長期（Horizon Three，例如未來一年或更長）。不同的時間範圍可能由不同的流程和負責人管理。
- 短期藍圖： 包含團隊當前正在進行的工作，例如功能開發、缺陷修復、技術債務償還和緊急工作項。可以使用看板或類似的工具進行管理。
- 中期藍圖： 關注未來幾個月需要完成的主要技術專案和改進。通常需要更詳細的規劃和規格說明，並與產品藍圖緊密結合。
- 長期藍圖： 更具戰略性，關注未來的技術趨勢、潛在的架構變革和長期的技術目標。可能比較抽象，需要定期回顧和調整。
- 優先順序排序： 根據業務價值、風險和資源可用性，對藍圖中的項目進行優先順序排序。
- 跨部門溝通： 與產品、設計等部門分享技術藍圖，確保各部門的計劃相互協調和支持。
- 定期回顧和更新： 技術藍圖不是一成不變的，需要隨著業務發展、市場變化和技術演進定期進行回顧和更新。
- 使用視覺化工具： 可以使用圖表、表格或專門的藍圖工具來清晰地展示技術發展的方向和時間表。
在新創公司的早期階段，應該如何選擇和實施技術流程？
在新創公司的早期階段，靈活性和快速迭代至關重要。選擇和實施技術流程應該遵循以下原則：
- 從簡開始： 避免過於複雜和繁瑣的流程，先建立一套基本可行、能夠滿足當前需求的流程即可。隨著團隊和業務的成長，再逐步完善和調整。
- 關注核心價值： 優先實施那些能夠直接提升軟體品質、交付速度和團隊協作效率的流程。
- 技術規格： 儘早開始撰寫技術規格，在實際編碼之前花時間思考和規劃，可以減少後期的返工和提高開發效率。技術規格應涵蓋需求、設計、資料模型、測試、部署等方面。
- 程式碼審查： 實施輕量級的程式碼審查流程，以確保程式碼品質、知識共享和團隊一致性。可以根據專案的重要性和風險程度，決定是否需要強制程式碼審查。
- 版本控制： 強制使用版本控制系統（例如 Git），並建立清晰的分支管理策略。
- 自動化： 盡可能地實現自動化，例如自動化測試、建置和部署流程，以減少人工錯誤和提高效率。
- 持續整合與持續交付（CI/CD）： 建立 CI/CD 管道，以便頻繁地將程式碼變更整合到主分支，並快速地將軟體交付給使用者。
- 敏捷方法： 可以考慮採用敏捷開發方法（例如 Scrum 或 Kanban），以實現迭代式開發和快速響應變化。
- 冷卻期（Cooldown）： 在高強度開發之後，安排一定的時間用於修復 bug 、重構程式碼和處理技術債務，以保持系統的健康。
- 測試策略： 建立全面的測試策略，包括單元測試、整合測試和端對端測試，確保軟體的品質和可靠性。
如何確保和提升新創公司工程團隊的開發者體驗（DX）？
良好的開發者體驗可以提高工程師的幸福感和生產力。提升 DX 的方法包括：
- 清晰的開發環境設定： 提供簡單易懂的開發環境設定說明，最好能夠一鍵安裝和運行所有依賴。
- 一致的工具和流程： 確保團隊使用一致的開發工具、程式碼風格規範和開發流程。
- 快速的反饋迴路： 縮短從程式碼提交到測試和部署的反饋時間，讓開發者能夠快速發現和修復問題。
- 可靠的測試資料： 提供易於設定和使用的本地測試資料，方便開發者進行單元測試和整合測試。
- 有用的開發工具： 投資於能夠提升開發效率的工具，例如程式碼編輯器、除錯器、性能分析工具等。
- 減少不必要的干擾： 幫助工程師減少會議、通知和其他不必要的干擾，讓他們能夠專注於編碼工作。
- 持續改進工具和流程： 定期收集開發者對工具和流程的反饋，並根據反饋進行改進。
- 技術升級： 關注新的技術趨勢和工具，並在評估其價值和風險後，考慮引入能夠提升開發者體驗的新技術。例如，Stripe 將其使用的 Flow 語言遷移到 TypeScript，以改善開發者體驗。
- 清晰的文檔： 編寫和維護清晰、準確的技術文檔，方便開發者理解和使用現有的程式碼和系統。
- 授權和自主性： 給予開發者足夠的授權和自主性，讓他們能夠參與技術決策和解決問題。
在新創公司中，技術長應該如何選擇和管理技術架構和工具？
選擇合適的技術架構和工具對新創公司的成功至關重要。技術長應該：
- 與業務需求對齊： 選擇的技術架構和工具應該能夠支持當前的業務需求，並具備一定的可擴展性以應對未來的發展。
- 考慮團隊技能： 盡量選擇團隊成員熟悉或容易掌握的技術，以縮短學習曲線和提高開發效率。
- 評估技術成熟度： 權衡使用最新技術的風險和收益，對於核心系統，可以考慮使用更成熟和穩定的技術。
- 架構模式選擇： 根據業務規模和複雜性，選擇合適的架構模式，例如單體架構或微服務架構。早期階段通常可以從單體架構開始，隨著業務增長再考慮遷移到微服務。
- API 設計： 重視 API 的設計，將其視為不同服務或組件之間的契約。清晰、一致且易於使用的 API 可以提高系統的整合性和可維護性。
- 資料和分析： 及早考慮資料儲存、處理和分析的需求，選擇合適的資料庫和資料管道技術。
- 工具選擇： 根據團隊的需求和預算，選擇合適的開發工具、測試工具、部署工具和監控工具。
- 技術雷達： 可以參考 Thoughtworks 的技術雷達模型，建立公司內部的技術雷達，用於評估和推廣新的技術、工具和模式。
- 實驗和評估： 在引入新的技術或工具之前，進行充分的實驗和評估，了解其優缺點和適用場景。
- 避免過度採用新技術： 要謹慎對待新技術，避免盲目追逐潮流，導致系統複雜性和維護成本增加。可以將一些新技術標記為「評估」或「試用」狀態，在實際專案中驗證其可行性後再考慮「採用」。
- 「無聊」技術： 在核心業務和基礎設施方面，可以考慮使用一些成熟、可靠但可能不那麼「新潮」的技術，以降低風險和提高穩定性。
在新創公司中，技術長如何衡量工程團隊的成功？
衡量工程團隊的成功不僅僅是看交付的功能數量，還需要考慮到多個方面：
- 業務價值交付： 工程團隊的工作是否有效地支持了業務目標的實現？例如，是否按時交付了關鍵功能，是否提高了使用者參與度或轉換率。
- 軟體品質： 軟體的穩定性、可靠性、安全性如何？是否有較少的 bug 和生產環境問題？可以使用 DORA 指標（例如部署頻率、變更失敗率、平均修復時間）來衡量。
- 工程效率和速度： 團隊的開發速度和效率如何？是否能夠快速響應需求變化？但要注意，速度不應以犧牲品質為代價。
- 技術健康度： 系統的架構是否合理？技術債務是否得到有效管理？程式碼是否易於理解和維護？可以使用技術債務盤點等方式進行評估。
- 團隊健康度和士氣： 工程師的滿意度如何？團隊的協作是否順暢？是否有較低的離職率？可以通過員工調查、 1:1 會談等方式了解。
- 個人成長和發展： 工程師是否在不斷學習和提升技能？團隊是否提供了足夠的成長機會？可以使用能力矩陣等工具進行評估。
- 流程效率： 開發流程是否高效？是否存在瓶頸？是否能夠持續改進？
- 預算控制： 工程部門的預算是否得到有效管理？是否在預算範圍內完成了工作？
- 風險管理： 工程團隊是否有效地識別和應對技術風險？
需要注意的是，很難用單一的指標來衡量工程團隊的成功，通常需要綜合考慮多個方面，並根據公司的具體情況和發展階段來調整衡量標準。技術長應該與團隊和管理層共同定義成功的標準，並定期進行評估和反饋。