為什麼文件準備度應該發生在正式撰寫之前？
當一份 Protocol、IB 或其他臨床開發文件延遲時，最直覺的反應通常是：
「是不是 writing 太慢？」
但在實際的臨床開發工作中，文件延遲的原因往往早在 writer 開始寫之前就已經出現。
資料還沒有整理完成。
不同版本互相衝突。
關鍵 decision 還沒有 final。
某個功能團隊的 input 尚未確認。
甚至沒有人很清楚現在到底應該以哪一份 source 為準。
這時候，把更多 writer 放進專案，不一定能讓文件更快完成。
Writing Ready 和「有資料」是兩件不同的事
一個團隊可能已經累積大量研究資料，卻仍然沒有準備好開始正式文件開發。
因為文件真正需要的不只是 information，而是 usable input。
例如：
來源是否明確？
版本是否固定？
不同報告中的數值是否一致？
哪些內容已經 final？
哪些仍然只是 preliminary？
如果出現矛盾，應該由誰確認？
如果這些問題沒有處理，writer 開始工作後就會不斷停下來追問。
於是表面上看起來是 writing cycle 很長，實際上大量時間是在等待 input、確認版本與重新修改。
文件開發真正的第一步，是確認準備度
因此，在正式 drafting 之前增加一個 readiness step，目的不是再增加一道行政流程。
它是在回答：
我們現在真的準備好開始寫了嗎？
一個實用的 readiness review 至少可以檢查幾件事：
現有 source materials 是否齊全？
哪些文件或資訊仍然缺失？
不同來源是否存在明顯不一致？
有哪些重要問題尚未決定？
這些問題需要哪一個功能或 SME 回答？
哪些問題如果沒有先解決，會直接影響後續文件開發？
這些問題被整理清楚後，正式 writing 才比較有可能持續往前，而不是反覆停下來等待。
Gap 不只是「少了一份文件」
談到 gap analysis，很容易讓人想到 checklist：
有沒有 Protocol？
有沒有 nonclinical report？
有沒有 PK data？
但真正影響文件準備度的 gap，不一定是一個「不存在的檔案」。
它也可能是：
兩份文件對同一件事情描述不同。
資料存在，但版本無法確認。
結果已經產生，但科學解讀尚未確認。
某項決策有人口頭討論過，卻沒有形成可追溯的 decision。
或者某個問題看起來很重要，但其實並不會阻擋目前 scoped milestone。
因此，Readiness Assessment 不只是找「缺什麼」，還需要進一步理解：
這個問題為什麼重要？需要誰處理？與下一步開發有什麼關係？
先整理問題，往往比直接開始寫更快
這看起來有點反直覺。
如果目標是趕快完成文件，為什麼不直接開始 drafting？
因為當 source materials 尚未成熟時，過早開始寫作往往只是把問題往後推。
Writer 先寫一版。
SME 發現 assumption 不對。
Clinical team 修改設計。
另一份文件又需要同步。
版本重新流轉。
最後花掉的時間可能比一開始先確認 readiness 更多。
所以 readiness work 的目的並不是追求「所有問題全部解決後才可以開始」。
真正的目標是把問題分清楚：
哪些已經足以開始？哪些可以邊走邊追蹤？哪些必須先得到答案？
這才是專案管理上的價值。
AI 可以讓 Readiness Review 更快，但不能自己關閉問題
AI 很適合協助大量 source review、版本比較、資訊擷取與 inconsistency detection。
它可以快速提出：
「這兩份文件似乎不同。」
「這個資訊沒有找到來源。」
「這項決策在目前資料中看起來尚未確認。」
但這些都只是 candidate issues。
AI 不知道某項差異是不是已經由團隊接受，也不知道某個缺口是否真正影響目前的 development milestone。
因此最後仍然需要人判斷：
這是不是一個真正的 Readiness Issue？
需要誰確認？
優先順序是什麼？
是否影響目前的文件工作？
是否需要 escalation？
AI 可以幫忙找到問題，但不能自動宣布問題已經解決。
文件準備度，其實是文件品質的一部分
高品質的 clinical document 不只是語句正確、格式完整。
它背後還需要清楚的 source、穩定的版本、已確認的決策，以及可以追溯的責任界線。
因此，真正有效率的文件開發，不一定從第一段文字開始。
很多時候，它從更早的一個問題開始：
我們現在手上的資料，真的已經準備好被寫進正式文件了嗎？
先把這個問題回答清楚，後面的 writing 才有可能真正變快。
留言