自 2007 年以來零項目失敗 —— 背後的工程紀律
我於 2006 年創立 Software Tailor。十九年過去,公司歷經四個截然不同的經濟周期、六家橫跨製藥、金融、政府、法律、國防與能源行業的《財富》世界 500 強客戶,以及自 2007 年以來零項目失敗。最後一個數字,正是投資人與採購審查者最常問起的,亦是唯一需要解釋的。以下是支撐着這份紀錄的四條工程紀律。
紀律 1:單一交付模式,不混淆服務與產品
每一項 Software Tailor 的合作都運行於同一套交付模式 —— 一個範圍緊湊、交付可用軟件的試行階段,然後是客戶依據已交付內容選擇是否資助的擴展階段。我們並無一個按需求文件交付的「服務」業務,以及另一個按路線圖交付的「產品」業務並存。兩者會彼此衝突;其中一方總會被迫補貼另一方。
單一模式意味着每位工程師於動手之前就知道「完成」是甚麼樣子。這就是不失敗的前提條件。
紀律 2:客戶群紀律 —— 只接我們能交付的客戶
我們的客戶群是挑選出來的,並非隨機而來。19 年間六家《財富》世界 500 強客戶,並不是緩慢的銷售管道,而是刻意設立的篩選門檻。我們接下的每一位客戶,都要於啟動前通過三項測試:他們的問題是我們以前解決過的、他們內部的贊助者就是會使用該軟件的本人(而非一層層的中間人),以及他們的硬件 / 資料環境能讓我們交付而毋須繞道半年採購。
通不過任何一項測試的客戶,會變成轉介給他人的對象,而不會成為項目。這是最常令我們流失收入的一條規則,亦是 19 年來零例外的一條。
紀律 3:對應到公認框架的工程紀律
早在 AI 風險管理擁有自己的框架之前,我為 Software Tailor 所制定的工程紀律,在形態上就與其相符:治理工作、繪製風險、量度成果、管理變更。NIST AI RMF 1.0 [1] 於 2023 年將該形態為 AI 形式化,而 2026 年 4 月的 Critical Infrastructure profile [1]則將之延伸至受規管行業。閱讀這些文件,我們內部的紀律乾淨地對應到那四項功能。
這帶來的是:每個項目都可以端到端依外部框架而非僅依我們自家習慣審計。當採購團隊問試行階段範圍如何決定,答案與 NIST 對風險管理會給出的答案相同 —— 而客戶自家的合規團隊早已內化了該套詞彙。
紀律 4:可記錄、可復原、可重建
第四條紀律早於我們現在用於 AI Suite 的審計軌跡詞彙存在。每一項 Software Tailor 的合作均運行於這樣一種狀態:任何決定、任何成品、任何版本的程式碼,皆可從版本控制的輸入重建。對於軟件工程而言這並不罕見;不尋常之處在於我們將之套用於項目本身,而非僅僅程式碼庫。Sprint 決定、範圍變更、客戶簽核 —— 全部記錄,全部可復原。
這正是為何我們為 AI Suite 採取不含內容的審計日誌的做法,會以那個樣子交付出去。審計列模式,就是我們早已套用於項目之上的同一模式。詞彙借自合規框架;做法則借自我們交付的方式。
甚麼被帶到了 AI Suite
Local AI Suite + AI Admin Console 產品線 —— 見為何我們以可安裝二進制檔交付 AI,而非雲端 SaaS —— 正是把同一套工程紀律應用於一條產品線,而非一次客製化合作。同一套單一交付模式(客戶在自己環境中運行的桌面安裝程式)、同一套客戶群紀律(具明確資料駐留約束的受規管行業)、同一套框架對應(NIST AI RMF + EU AI Act 部署者義務)、同一套可記錄、可復原、可重現的審計姿態。
自 2007 年以來零項目失敗並不是口號,而是少數規則無一例外地套用的結果。同樣的規則,現在亦管治着 AI Suite 的構建方式。
參考資料
- NIST。「AI Risk Management Framework (AI RMF 1.0)。」nist.gov/itl/ai-risk-management-framework。檢索於 2026-07-15。
相關文章
在真實工作負載上考驗同一套紀律。
本地部署 AI 平台建基於締造這份紀錄的同一套規則 —— 可記錄、可復原、可重現,並毫無例外地貫徹。在你自己的環境中就一個真實工作負載部署它,並以同一標準要求它。