作者 Cliff Chew (Singapore Based Data Consultant)
編輯註：本文原文為英文，另有原文英文版本請參考此連結
作為一名數據從業者，我總是對利用數據來改進流程感到興趣。我最近在 Medium 上發表的一篇關於如何在 Google 上追蹤我的工作任務的文章，讓我也想到了之前透過 Google 日曆數據來優化我生活的專案。
在探索這兩個專案的過程中，我發現了一些關於數據品質的細微差別，這些差別雖然不那麼引人注目，但卻與媒體常提到的其他熱門詞彙同等重要。在這篇文章中，我希望向更廣泛的讀者強調這些與數據品質相關的細微之處。
一切的起點 — 數據收集
「你無法改進你無法衡量的東西」，這句話通常被認為是彼得·杜拉克(Peter Drucker)說的。在任何正常的分析工作流程中，你需要收集、處理和分析數據，希望能產生一些理想的行動、輸出或結果。
圖1 — 數據專案的典型分析流程
任何分析專案的開始都需要以某種方式收集和累積一些數據。Google 日曆和任務(Google Calendars and Tasks)都是支持我生活優化工作的主要產品。首先，Google 日曆和任務都是免費使用的，這使得我更容易考慮將它們用於我的專案。在這兩個工具上，創建任務以線性待辦事項列表的形式顯示，或者在日曆視圖上創建和列出事件都非常容易。然而，雖然這兩個工具本身都是很棒的產品，但我最喜歡的是它們的數據收集過程，但我覺得如果能夠通過它們的應用程式介面(API, Application Programming Interface)調用來訪問數據，我可以在處理和輸出領域做更多事情。
圖2 — 透過 API 調用獲取數據後，區分出我自己的處理和分析
關於 API 的簡單介紹，它代表應用程式介面。它們是允許程式腳本使用某些數據的服務。由於數據可以通過程式腳本檢索，API 允許一系列生態系統和服務從中發展，從天氣預報應用到加密貨幣交易所。我能夠利用Google 提供的 API以可擴展、高效的方式處理和輸出 Google 任務和日曆數據。
用戶生成內容的問題
另一方面，這兩個工具的數據收集過程也並非完美。理想的數據專案會盡可能自動追踪他們的數據，以消除人為錯誤、懶惰或不一致性。當然，日曆和任務都需要手動用戶數據輸入，這在一定程度上會影響數據質量。
例如，普通用戶很可能不會在 Google 日曆上更新他們的事件(Event)結束時間，如果事件超時的話。這需要額外的努力做更新，對大多數人來說，設置日曆事件很可能是為了確保他們不會重複預訂。然而，為了分析我在某些事件上花費了多少時間，當事件有異動時，我不得不付出額外的努力來更新我的事件結束時間。不幸的是，我注意到有些天我太忙碌，忘記更新我的事件結束時間。類似的情況也可能發生在我的任務上，我需要編輯它們的時間到我最終執行它們的時候。
任務與事件
如我在上一篇文章中提到的，任務和事件本質上有非常不同的屬性，使得很難一起分析和優化它們。
首先，事件有持續時間，而任務沒有。事實上，任務並不代表我完成它們所需要的時間（比如這篇「長」的 Medium 文章）。然而，有些任務的持續時間對我的分析提供了重要價值，例如支付每月的賬單。我是否應該將較長時間的任務創建為日曆上的事件？就我個人而言，我不想這樣做。從主題上來說，事件是我經歷的生活體驗，有時與朋友在特定地點，而任務是我要完成的過程。所以把任務記錄為事件感覺不對。從我的工作流程角度來看，因為我喜歡在我的任務中有可以按優先順序排序的項目，並在完成時劃掉。如果它們是日曆上的事件，我就無法做到這一點。
其次，即使我在兩個工具中統一了類別名稱，事件上的持續時間屬性意味著我無法明確說出我的任務和事件中哪個生活主題佔用了我更多的生活。這是因為事件和任務的計量單位不同，事件以持續時間（小時）衡量，而任務以頻率（次數）衡量。解決這個問題的一些想法包括為每個單一任務設置一個基本持續時間（支付賬單），然後在我的任務描述中為較長時間運行的任務添加持續時間信息。
無論如何，將持續時間屬性納入任務中將需要更多的努力，因為它不是默認的輸入參數，這樣做將會相當麻煩。我仍在想辦法如何最好地將兩個工具的數據源合併成一個一致反映我生活承諾的視圖，但目前，我正在分別運行和顯示我對事件和任務的分析。
結語
我們生活在一個有豐富數據的世界，「數據科學家」、「深度學習」、「生成式人工智能」等吸引眼球的熱門詞彙引起了轟動。然而，當企業追逐這些熱門領域時，當我們考慮使用數據改進我們的流程時，我們需要從根本上理解我們正在優化的問題的性質和背景，理解不同方面為實現當前期望結果所採取的步驟，並理解數據是如何創建和存儲的，然後才能有效地利用數據進行分析。
雖然我們可能對事情如何運作有一些想法，但沒有什麼比親自動手處理數據更能讓你更好地理解數據如何使用或無法使用。
一些書籍推薦
感興趣的非技術人員可以參考《Ask Your Developer》這本書，以了解他們如何與程式設計師合作來擴大他們的業務與技術。作者寫得很好，使用簡單的語言針對非技術讀者，但又給你足夠的內容與你的程式設計師進行進一步的對話。
另一本名為《The Phoenix Project》的書講述了一位高級程式開發人員如何幫助她的組織解決數位轉型的困難，使組織重新回到行業得證軌上。如果技術術語讓你感到厭煩，這個虛構的敘事可能會重新激起你對技術應用於商業流程的興趣。
你必須登入才能發表留言。