工作流程 # 保留各項專業判斷的交付系統。 規格優先交付不要求一位工程師或一套 AI 系統，取代分布在產品、領域、架構、品質、安全與營運職能中的知識和判斷。它讓這些專業判斷在整個交付過程中都可以被取得、審查和使用。 ## AI 改變工作方式，不改變責任歸屬。 ### AI 參與工作 AI 可以擷取脈絡、找出問題、整理草稿，並執行已核准的技術工作。 ### 專業人員作出決定 具備相應專業能力的人，仍須對自己職責範圍內的判斷負責。 ### 組織保留知識 經審查的知識、決策、規格和證據，在人員、團隊或工具改變後仍然可以被找到和使用。 共同工作約定 ## 尊重專業判斷，並把它保留下來。 這套工作流程讓每位參與者在交付成果時都有清楚角色。它不會把產品、工程、領域、品質、安全與營運的責任歸屬，混合成一個沒有明確專業範圍的通用角色。 ### 尊重每項專業 不要求任何一位參與者取代所有專家。當變更涉及產品、領域、安全、可靠性、架構、品質或交付判斷時，負責相關專業的人便應直接參與。 ### 保留具名責任歸屬 每份重要文件都必須有具名負責人。AI 可以協助草擬和提出質疑，但不能成為文件的責任人，也不能取代人的審查。 ### 把已確認的答案變成組織資產 已確認的答案應更新知識系統，而不是只停留在私人對話或某個人的記憶中。 提問與審查循環 ## 每個重大問題都有明確的處理路徑和負責角色。 討論文件、規格、架構設計、技術工作和測試規格在形成期間，都會反覆經過這個循環。AI 未再提出重大問題，只是一個審查訊號，並不代表人的責任已經轉移。 ### 1. 對照現有知識提出問題 使用 AI 檢視需求、現有程式碼、已記錄的決策和相關限制，找出缺漏資訊、衝突、例外情況和相依關係。 ### 2. 向負責的專業角色查證 當問題屬於另一項專業時，應請相關同事作出決定、澄清或審查，而不是自行推論答案。 ### 3. 更新文件和知識系統 把決定記錄在適當的討論文件、規格、詞彙表、方法、限制或決策歷程中。 ### 4. 逐行審查 具名負責人應逐項檢查文件是否正確、清楚，並核對工作範圍、限制、必須保留的行為和驗收條件。 交付流程 ## 一條清晰可見的流程，每個階段都有明確的責任歸屬。 以下階段說明一項需求如何由審慎討論，逐步成為範圍清晰的實作工作。當證據顯示原有理解需要修正時，提問與審查循環可以把工作帶回較早階段。 ### 1. 根據現有知識和程式碼界定變更 在決定實作方式前，先討論新功能、新應用程式或新需求。讓參與者和 AI 系統都能取得目前的產品意圖、決策歷程、程式碼、限制、介面和營運脈絡。 - **具責任歸屬的角色:** 重大功能由產品負責人主導；較小功能可由產品經理或計劃經理主導。業務分析師負責定義業務需求。若變更影響安全或可靠性責任，相關專家亦應參與。 - **主要工作產物:** 一份討論文件，以及對相關知識和程式碼庫的查證紀錄。 - **知識系統:** 需求可能揭示詞彙表、產品意圖、計算方法、使用情境、目前技術脈絡或外部連接資訊有所缺漏。 - **準備就緒的條件:** 團隊能說明預期成果、已檢視的脈絡、需要作出決定的人，以及仍未解決的重大問題。 ### 2. 審查並完善討論文件 請 AI 找出未解問題，向負責的同事取得答案，再修訂文件。持續重複，直到 AI 根據現有脈絡未再提出重大問題，而且文件負責人判斷討論已經足以進入規格階段。 - **具責任歸屬的角色:** 討論文件的具名負責人主導審查，對文件所提出問題負責的專家則提供相應判斷。 - **主要工作產物:** 一份經逐行審查的討論文件，包含答案、假設、未完成的決策，以及相關知識來源的連結。 - **知識系統:** 已確認的答案應更新未來工作需要的知識來源，包括術語、業務規則、產品意圖、限制和決策歷程。 - **準備就緒的條件:** 文件負責人已審查每項陳述，並已解決重大問題，或已確定由哪個角色透過甚麼程序完成決定。 ### 3. 撰寫功能與非功能規格 描述使用者可以觀察到的行為，包括正常流程、例外、錯誤、對話方塊、業務規則和驗收條件。非功能規格則在有需要時說明可靠性、可觀測性、警示、安全、效能或技術要求。 - **具責任歸屬的角色:** 對需求負責的人撰寫或擁有規格，並按需要納入產品、業務分析、安全、可靠性、品質和營運專業。 - **主要工作產物:** 功能規格，以及在需要時撰寫的非功能規格。 - **知識系統:** 規格讓已同意的行為、營運期望和驗收證據，可以由工程、QA 和後續變更重複使用。 - **準備就緒的條件:** 預期行為和營運期望已足夠明確，讓技術設計、技術規格和測試設計可以在無需猜測的情況下開始。 ### 4. 需要架構決策時，先設計解決方案 (視需要進行) 當變更引入或改變系統責任、介面、相依關係、技術選擇或重大限制時，應把相關規格轉化為架構設計。修補工作和低風險變更未必需要這個階段。 - **具責任歸屬的角色:** 架構師負責架構決策，並與開發主管及受影響的專家合作。 - **主要工作產物:** 在變更需要時，產出一份經審查的設計文件。 - **知識系統:** 設計文件記錄工程團隊需要保留的決策、替代方案、理由、後果和限制。 - **準備就緒的條件:** 實作所需的架構決策已經明確並完成逐行審查，而且在相關範圍內沒有未解決的重大問題。 ### 5. 撰寫可供執行的技術規格 把已同意的需求和架構設計，轉化為工程師或 AI 程式開發代理可以執行的技術工作。較大的需求可以合理地拆分成三份、二十份或其他合適數量的技術規格。 - **具責任歸屬的角色:** 工程師撰寫技術規格；開發主管和其他專家則審查會影響其職責的問題。 - **主要工作產物:** 一組技術規格。一份功能或非功能規格可能產生多份技術規格。 - **知識系統:** 新的實作限制、程式碼庫發現、介面和決策，若改變已同意的理解，便應回到討論文件、需求、設計或其他知識來源。 - **準備就緒的條件:** 工程師判斷每份技術規格在其執行範圍和權限內，已沒有未解決的重大問題。 ### 6. 實作已同意的技術規格 工程師判斷技術規格已經準備就緒後，執行指示可以直接是「實作該規格」。新的資訊不應被默默吸收進程式碼，而應交回負責人，並更新適當的較早階段工作產物。 - **具責任歸屬的角色:** 工程師仍對技術規格的執行負責；若新發現的問題超出其權限，便應交由適當的負責人處理。 - **主要工作產物:** 實作成果、驗證結果，以及已符合既定規格的證據。 - **知識系統:** 產生的程式碼、偏差、驗證證據和營運所得知識，會成為下一次變更可用知識的一部分。 - **準備就緒的條件:** 實作已對照技術、功能、非功能和測試規格完成驗證，再交由適當角色作出驗收和發佈決定。 同步進行的品質工作 ## 測試規格應從需求開始，而不是從實作倒推。 QA 和測試工程師應根據功能與非功能規格撰寫測試規格，讓驗收證據持續對應程式碼寫成前已同意的成果和營運期望。 ### 1. 從需求推導測試規格 把已訂明的行為、例外情況、可靠性期望、可觀測性要求和警示條件，轉化為可測試的情境和證據。 ### 2. 使用相同的提問與審查循環 QA 工程師請 AI 找出未解決的測試問題、更新知識系統，並逐行審查測試規格。屬於其他專業的問題，應交回負責相關判斷的同事。 ### 3. 讓驗收證據清楚可見 測試和營運證據顯示已同意的條件是否獲得滿足，讓驗收負責人可以作出決定，而不必在實作完成後重新定義需求。 組織交付能力延續 ## 每完成一個交付作業，組織都更有能力處理下一次變更。 這套流程持續改善共享的知識和證據系統。它減少組織對單一個人記憶的依賴，但不會減低專業判斷的價值。 - 詞彙表、產品意圖、業務規則和計算方法 - 使用情境、例外情況、限制和必須保留的行為 - 架構決策、目前技術脈絡和外部連接資訊 - 可靠性目標、可觀測性、警示、測試規格和驗收證據 - 討論歷程、決策、實作所得知識和經審查的偏差 ## 團隊合作讓專業判斷得以長期保留。 每個人都帶來不同的專業能力。規格優先交付協助團隊把這些判斷轉化為共享的交付能力，讓 AI 強化組織成果，而不是令人擔心自己的專業會被取代。 [從一條交付流程開始](https://specfirstdelivery.org/zh-tw/framework/adoption)