《K-DNA．連結你的未來》第四章｜重構計畫 (11)
員工代表看著投影片，沉默了一會兒。
「至少，你們有把這件事說清楚。」
逸晨坐在台下，聽著榆寧的回答。
他忽然意識到，這幾年來，公司花了大量資源研究如何讓模型理解使用者，卻很少有機會真正聽見使用者如何理解公司，而今天，這場說明會才剛剛開始。
測試啟動後的第一週，數據並沒有如預期般漂亮；六千名員工收到邀請，實際完成註冊的人數不到一半；願意提供基因資料的人，更是少數；企業合作窗口有些焦急。
「照這個比例，最後的參與人數可能遠低於預估。」
榆寧看著報告。
「但目前沒有證據顯示參與率低，是因為產品不好用。」
「那是什麼原因？」
「有人還沒看完說明，有人想先了解企業能看到什麼，有人暫時不想使用，也有人認為自己不需要這項服務。」
「所以，我們就不做任何事？」
榆寧回答：「不是。我們可以改善說明、讓流程更容易理解，也可以邀請員工提出問題。但不能把所有沒有註冊的人，都當成需要被說服的潛在客戶。」
對方沒有再說話。
這種觀念，顯然與一般企業導入數位服務的習慣不同。
過去，只要參與率不如預期，專案團隊就會增加提醒、調整推播、提供獎勵，甚至重新設計流程，讓使用者更容易完成註冊，但這次，Biogene 必須先分辨：使用者是不理解，所以沒有參與？還是理解之後，選擇不參與？兩者的意義完全不同。
因此，團隊設計了一份不記錄個人基因資料的匿名問卷，讓員工可以自由回饋。
結果出乎意料。
有些人不是反對基因科技，而是不希望自己的健康資訊與工作環境產生任何關聯；有人擔心資料日後被用於保險或人事決策；也有人只是覺得，自己目前沒有需要透過基因分析解決的問題。
一位物流公司的員工寫道：「我每天工作已經很累了。我不需要再多一個系統告訴我，應該怎麼生活。如果它真的能幫助我，就先讓我自己決定要不要使用。」
這段話被榆寧特別標記起來，她把問卷結果帶進團隊會議。
「我們一直在設計一套讓人更了解自己的產品，但有些人現在最需要的，可能不是更多資訊，而是不要再被另一套系統管理。」
逸晨看著那段回覆。
「把它放進使用者研究報告。」
「我已經放進去了。」
「不要當成負面意見。」
榆寧笑了一下。
「我知道。」
第二週，真正的技術問題開始浮現。
物流企業的輪班員工，使用Compass Core追蹤作息時，出現了一批異常結果。系統原本依據一般日間作息設計建議流程，但輪班人員的生活時間並不固定。有些人凌晨下班，有些人下午才開始工作，有些人每週更換班別。當這些使用者只提供有限的生活資訊時，模型偶爾會把他們的睡眠時間判定為不規律，進而提出不符合實際工作安排的生活管理建議。
其中一名員工甚至在回饋中寫道：「我不是不想早睡，而是我的工作時間根本不允許我早睡。」
技術團隊立刻召開檢討會，子謙把問題整理在白板上。
「這不是單純的資料不足，而是模型預設了某種生活模式。我們把一般日間工作者的規律，當成所有人的標準。」
逸晨說：「也就是說，模型不是不知道答案，而是問錯了問題。」
「沒錯。」
榆寧翻閱使用者回饋。
「我們應該先問工作型態，而不是直接把生活時間套進既有分類。」
子謙搖頭。
「這樣會增加新的資料需求。」
逸晨說：「那就評估是否真的需要。如果只需要知道使用者是固定日班、輪班，還是時間不固定，就不要要求他提供完整工作紀錄。」
技術團隊重新設計了生活節奏模組。他們不再把某一種作息視為標準答案，而是先辨識使用者所處的生活情境，再依照情境提供相應的建議。
這項修改看起來並不複雜，但它讓團隊重新理解了一件事：所謂個人化，不只是根據一個人的資料產生不同答案；更重要的是，不要把某一種人的生活方式，當成所有人都應該遵循的標準。
第三週，另一個更棘手的問題出現。
一名金融公司員工選擇了部分資料授權，希望改善日常飲食習慣，系統依照他的紀錄，提出了一套一般性的飲食管理建議，但在後續回饋中，使用者表示自己有特殊飲食限制，而這項資訊並未包含在最初的問卷裡，模型並不知道；問題是，它在不知道的情況下，仍然產生了看似完整的建議。團隊重新檢視流程後發現，系統雖然有標示建議的適用範圍，卻沒有在關鍵步驟詢問是否存在會影響建議的限制條件。
這讓逸晨非常警覺。
「我們不能期待使用者知道自己應該提供什麼資料。」
子謙回答：「所以，我們需要建立情境風險檢查，但不能因此把所有資訊都問一遍。」
榆寧接著說：「我們要問的是，哪些資訊如果不知道，就不應該繼續提供特定建議。」
於是，Compass Core增加了一個新的判斷機制。
當使用者提出某類需求時，系統先辨識可能影響建議安全性與適用性的關鍵條件；如果必要資訊缺失，就先提供低風險的一般性內容，或詢問使用者是否願意補充；如果仍然無法合理判斷，就明確停止提供進一步的個人化建議。
這個改變讓部分流程變長，但它也讓團隊第一次看見，模型的可靠性不只是答案是否正確，更包括它是否知道答案的適用範圍。
逸晨在檢討會議結束前說：「我們不能把使用者沒有提供的資料，當成不存在的問題。」
這句話被子謙寫進了Compass Core的設計原則。
一個月過去，先導測試的第一份中期報告完成。
參與率沒有達到企業原本預期，基因資料授權比例，也遠低於Biogene過去在一般消費市場的數字，但有三項結果讓獨立稽核團隊特別注意。
第一，使用者對資料用途與授權選項的理解程度，明顯高於專案開始前的預估。
第二，即使沒有提供基因資料，仍有相當比例的使用者持續使用生活管理與目標追蹤功能。
第三，當使用者發現系統無法提供某些個人化分析時，多數人能夠理解原因，而不是單純把它視為產品失效。
當然，這些數據還不足以證明K-DNA Compass已經成功，但至少說明，使用者不必交出所有資料，才有理由繼續使用服務。
「至少，你們有把這件事說清楚。」
逸晨坐在台下，聽著榆寧的回答。
他忽然意識到，這幾年來，公司花了大量資源研究如何讓模型理解使用者，卻很少有機會真正聽見使用者如何理解公司，而今天，這場說明會才剛剛開始。
測試啟動後的第一週，數據並沒有如預期般漂亮；六千名員工收到邀請，實際完成註冊的人數不到一半；願意提供基因資料的人，更是少數；企業合作窗口有些焦急。
「照這個比例，最後的參與人數可能遠低於預估。」
榆寧看著報告。
「但目前沒有證據顯示參與率低，是因為產品不好用。」
「那是什麼原因？」
「有人還沒看完說明，有人想先了解企業能看到什麼，有人暫時不想使用，也有人認為自己不需要這項服務。」
「所以，我們就不做任何事？」
榆寧回答：「不是。我們可以改善說明、讓流程更容易理解，也可以邀請員工提出問題。但不能把所有沒有註冊的人，都當成需要被說服的潛在客戶。」
對方沒有再說話。
這種觀念，顯然與一般企業導入數位服務的習慣不同。
過去，只要參與率不如預期，專案團隊就會增加提醒、調整推播、提供獎勵，甚至重新設計流程，讓使用者更容易完成註冊，但這次，Biogene 必須先分辨：使用者是不理解，所以沒有參與？還是理解之後，選擇不參與？兩者的意義完全不同。
因此，團隊設計了一份不記錄個人基因資料的匿名問卷，讓員工可以自由回饋。
結果出乎意料。
有些人不是反對基因科技，而是不希望自己的健康資訊與工作環境產生任何關聯；有人擔心資料日後被用於保險或人事決策；也有人只是覺得，自己目前沒有需要透過基因分析解決的問題。
一位物流公司的員工寫道：「我每天工作已經很累了。我不需要再多一個系統告訴我，應該怎麼生活。如果它真的能幫助我，就先讓我自己決定要不要使用。」
這段話被榆寧特別標記起來，她把問卷結果帶進團隊會議。
「我們一直在設計一套讓人更了解自己的產品，但有些人現在最需要的，可能不是更多資訊，而是不要再被另一套系統管理。」
逸晨看著那段回覆。
「把它放進使用者研究報告。」
「我已經放進去了。」
「不要當成負面意見。」
榆寧笑了一下。
「我知道。」
第二週，真正的技術問題開始浮現。
物流企業的輪班員工，使用Compass Core追蹤作息時，出現了一批異常結果。系統原本依據一般日間作息設計建議流程，但輪班人員的生活時間並不固定。有些人凌晨下班，有些人下午才開始工作，有些人每週更換班別。當這些使用者只提供有限的生活資訊時，模型偶爾會把他們的睡眠時間判定為不規律，進而提出不符合實際工作安排的生活管理建議。
其中一名員工甚至在回饋中寫道：「我不是不想早睡，而是我的工作時間根本不允許我早睡。」
技術團隊立刻召開檢討會，子謙把問題整理在白板上。
「這不是單純的資料不足，而是模型預設了某種生活模式。我們把一般日間工作者的規律，當成所有人的標準。」
逸晨說：「也就是說，模型不是不知道答案，而是問錯了問題。」
「沒錯。」
榆寧翻閱使用者回饋。
「我們應該先問工作型態，而不是直接把生活時間套進既有分類。」
子謙搖頭。
「這樣會增加新的資料需求。」
逸晨說：「那就評估是否真的需要。如果只需要知道使用者是固定日班、輪班，還是時間不固定，就不要要求他提供完整工作紀錄。」
技術團隊重新設計了生活節奏模組。他們不再把某一種作息視為標準答案，而是先辨識使用者所處的生活情境，再依照情境提供相應的建議。
這項修改看起來並不複雜，但它讓團隊重新理解了一件事：所謂個人化，不只是根據一個人的資料產生不同答案；更重要的是，不要把某一種人的生活方式，當成所有人都應該遵循的標準。
第三週，另一個更棘手的問題出現。
一名金融公司員工選擇了部分資料授權，希望改善日常飲食習慣，系統依照他的紀錄，提出了一套一般性的飲食管理建議，但在後續回饋中，使用者表示自己有特殊飲食限制，而這項資訊並未包含在最初的問卷裡，模型並不知道；問題是，它在不知道的情況下，仍然產生了看似完整的建議。團隊重新檢視流程後發現，系統雖然有標示建議的適用範圍，卻沒有在關鍵步驟詢問是否存在會影響建議的限制條件。
這讓逸晨非常警覺。
「我們不能期待使用者知道自己應該提供什麼資料。」
子謙回答：「所以，我們需要建立情境風險檢查，但不能因此把所有資訊都問一遍。」
榆寧接著說：「我們要問的是，哪些資訊如果不知道，就不應該繼續提供特定建議。」
於是，Compass Core增加了一個新的判斷機制。
當使用者提出某類需求時，系統先辨識可能影響建議安全性與適用性的關鍵條件；如果必要資訊缺失，就先提供低風險的一般性內容，或詢問使用者是否願意補充；如果仍然無法合理判斷，就明確停止提供進一步的個人化建議。
這個改變讓部分流程變長，但它也讓團隊第一次看見，模型的可靠性不只是答案是否正確，更包括它是否知道答案的適用範圍。
逸晨在檢討會議結束前說：「我們不能把使用者沒有提供的資料，當成不存在的問題。」
這句話被子謙寫進了Compass Core的設計原則。
一個月過去，先導測試的第一份中期報告完成。
參與率沒有達到企業原本預期，基因資料授權比例，也遠低於Biogene過去在一般消費市場的數字，但有三項結果讓獨立稽核團隊特別注意。
第一，使用者對資料用途與授權選項的理解程度，明顯高於專案開始前的預估。
第二，即使沒有提供基因資料，仍有相當比例的使用者持續使用生活管理與目標追蹤功能。
第三，當使用者發現系統無法提供某些個人化分析時，多數人能夠理解原因，而不是單純把它視為產品失效。
當然，這些數據還不足以證明K-DNA Compass已經成功，但至少說明，使用者不必交出所有資料，才有理由繼續使用服務。
鍵盤左右鍵 ← → 可以切換章節