今天的故事是延自上兩篇的後續自動化處理，讓我再把整個細節稍加補充，最一開始我們是先使用 google sheet 表單當作資料庫，程式會定期去表單抓取每一個群組可用的線路設定，所以當臨時頁面上出現線路資料的服務等級不為 0 的時候，維運人員到 google sheet 上，找到該筆線路資料，移除該資料，然後換成其他備用的線路資訊。

範例：當臨時頁面出現〔線路123〕服務等級5，那就要把〔線路123〕從表格移除，然後換成〔線路456〕。

google sheet 當作資料庫當然只是臨時的，當開發團隊安排把資料存入其他設備，下一步就是要製作後台操作頁面供維運團隊使用了，當時在設計的操作介面時，想著要分群組顯示顯示資料，維運團隊就可以分群組逐一處理，為了避免重蹈之前的錯誤，所以這次在開發團隊討論完預計的功能設計時，便先去找維運工程師確認這是否是他們所需要的？

當把我們想好的方案提議給維運工程師時，維運工程師表示
『我們沒有要每個群組逐一檢查耶...』
「嗯？不然你們都是怎麼處理」（訝異的睜大眼睛）
『有問題的直接換過去就好了。』
「嗯...還是你先說一下現在你們怎麼處理？」
『我會把檢查出來的資料，跟備用的線路資料配對，然後把 google sheet 上的資料抓下來，用程式直接產生新的一份檔案，再直接複製貼到 google sheet 上』
「所以只要等級不為 0 的就換，你們不用再做二次確認嗎？」
『對喔！反正我們來說，有問題就是得換』
「哪個資料換不用知道嗎？」
『有記錄就可以，還要可以看到當下每個群組適用的線路資訊就好』
「好」

老實說，當我聽到維運工程師的處理方式出乎意料，就如前一篇文章所敘述的，以往我所面對的使用者都是非工程師，很少遇到可以自行先做小工具來補足我們系統尚未提供的服務，另一部分感到意外的部分是我從還沒有想到這樣換，感覺好像自己的腦袋已經被限縮在特定的範圍裡。

談需求時與其自己憑空想像，不如直接詢問維運團隊操作步驟，然後針對每個步驟去詢問跟設想不同的可能性，慢慢探究操作步驟的每個原因，然後再進行設計規劃，才能淬煉出實際幫助較大的功能。