最近在準備公司內部 ISO 9001 的二階稽核，負責撰寫研發流程相關的正式文件。雖然平常就有在管理技術文件，但這次需要把所有流程梳理得更具體、更有邏輯性，確保每一項活動都能被「看得見、追得動、驗得出」，還是有不少地方值得記錄。
梳理流程的第一步：從階段（Phase）下手
我們的研發流程被切成四大階段：Product、Development、QA Testing 和 Sign-Off。每個階段都有不同的重點，像 Product Phase 強調 FRS 定義和前期規劃；到了 QA 就是確保測試結果可追蹤、可重現。
一開始的挑戰是怎麼把這些流程寫得既精簡又清楚，不會變成堆文字卻沒人看得懂的文檔。後來發現，最有效的方式是把每個階段的：
- 核心活動（Activities）
- 輸入與輸出（Inputs/Outputs）
- 參與角色（Roles）
通通列清楚，讓每個人都知道自己該做什麼、交付什麼、不該做什麼。
定義「誰該負責什麼」比想像中重要
ISO 文件裡面常會問：「這流程誰負責？怎麼確認有執行？」這時候模糊用語就會出事了。為了讓角色清楚，我把參與者分成三類：
- Coordinator：負責推流程、確認產出、收尾。
- Mandatory Participants：這階段一定要參與、而且有交付責任的角色。
- Optional Participants：有關聯但非必要，通常提供建議或協助。
這樣在稽核時就能清楚說明：流程中哪些角色負責產出、哪些只是旁觀或支援。
不只是文件，更是驗證機制
ISO 強調「可驗證性」，所以流程設計不能只靠文字敘述，而是每個階段都要有具體可佐證的輸出物。像 FRS 文件要有審查紀錄、測試階段要有 coverage 報告、最後要有正式簽核紀錄。這些東西不是為了應付稽核，而是讓整個流程真的可以被追蹤、檢查，發現問題也能回頭補強。
幾個我自己記下來的提醒
這次過程中也累積了一些心得，列幾個自己覺得實用的：
- 流程不怕寫得細，但用語要讓團隊看得懂 不需要每句都像法條，能讓開發、測試、主管一眼懂意思，比硬湊專業詞更有用。
- 符號用法最好一開始就定清楚 有時表格裡會出現 +、&、,，但每個人理解可能不同，一開始就定義好邏輯會省掉很多混亂。
- 縮寫要嘛統一，要嘛標明 像是 Dev vs. Dev.，到底有沒有點其實影響不大，但統一性會影響文件的專業度。
- 表單、文件記錄不要等到最後才補 包含文件編號、簽核欄、版本管理這些，建議在一開始就放進流程裡，否則最後補起來會很吃力。
整體來說，這次撰寫流程文件不只是幫團隊準備稽核，更像是一個把研發流程「梳理清楚、標準化」的機會。也讓我重新思考一件事：我們花很多時間寫 code、測 bug，但其實流程設計的品質，也會影響整體交付效率。
寫 ISO 不用想得太嚴肅，它其實就像是在幫團隊拉一條清楚的繩索，讓每個人知道該往哪個方向走。
Techoverse 
發表留言