對不了解系統上線流程的人來說，他們會覺得這不過就是個小調整，為什麼每次都要我三催四請的？

對開發的工程師來說，他們會覺得這些人有完沒完啊？這些文字不是都已經討論過了，為什麼每隔幾天，甚至幾小時就要改一次？

實際上，改動文字對工程師來說可能花不到 1 分鐘的時間。

但對有上版流程的公司來說，每次更新可能都要花 1 小時以上（就算只有改一個字）。

今天這篇文章不是要談誰對誰錯，或是如何用技巧來迴避問題；而是要分享面對問題時，可以如何一步步「解決」他。

文章寫完後，感覺自己在寫技術發展史；另外，這是朋友向我分享的經驗，絕對不是我自己的。

石器時代：寫死在程式碼

在最遠古的時期，網頁上的文字是寫死在程式碼的。

雖然直觀，但維護性極低。

因為面對「修改文字」的需求變更，開發人員可能改了 A 頁面，卻忘了還有 B、C、D 等頁面也用到一樣的詞彙。

大航海時代：建立語言包維護

如果系統只用同一種語言，那寫死在程式還勉強能維護。

但如果接下來要進軍國際市場，有中、日、英、法等多國語系的需求時，我想工程師就會崩潰了。

因為寫死在程式碼是完全行不通的，雖然很痛苦，但開發人員會需要把系統中所有的文字抽出來，建立「語言包」來維護才能解決這個需求。

這樣未來在面對「修改文字」的需求變更時，開發人員只要在單一檔案處理，透過模組化的管理，可以大幅降低遺漏的可能性。

工業時代：提供 Google Sheet 讓產品方填寫

把文字集中到語言包維護後，其實面對修改文字的需求就很容易處理了。

但…接下來要討論的是「人」的問題。

因為產品方會一直看系統的文字，看著看著可能就覺得哪裡不順眼，不順眼就要改！

所以在新版本上線後，可能一週內會收到多次文字變更的需求。

在這樣的狀況下，現實生活中最容易遇到的就是「漏訊息」；當訊息有前後因果關係、重複資訊的時候，失誤在所難免。

為了減少產品方打擾 PM 與工程師的頻率，以及減少訊息遺漏的問題。

提供一份格式律定好的 Google Sheet，讓產品方在線上「修改文字」是一個不錯的方案。

這樣雙方約定一個時間一次性更新即可（會跑一個將 Google Sheet 轉成語言包的腳本）。

科技時代：直接透過管理介面修改文字

改成 Google Sheet 後，雙方和平了好一段時間。

但還有一個問題，那就是這種修改沒有「即時性」。

因為程式每次上版都需要 Build Docker Image、跑回歸測試、上多個環境確認…

你可以理解為這些步驟至少要花費一小時以上的時間，而且會涉及到不同團隊的人（開發、QA、PM…）。

如果今天只是要修改文字，這樣的操作完全不符合成本效益。

所以目前的最新方案，就是在後台管理介面中，新增修改文字的功能，讓產品方可以依照自己的需求即時進行調整（搭配預覽頁）。

總結

修改文字是一個常見的需求變更，而且很多時候是在系統上線後才發生。

對工程師來說，修改文字這件事的確很簡單，但背後所需花費的時間與人力成本其實很高。

相信看完這篇文章後，大家可以理解為什麼有些小變更需要等一段時間才能更新。

儘管這篇不是純粹的技術文，但還是提醒一下讀者，每個時代的演進都需要不少時間成本。

這些改進所用到的技術並不困難，但問題在於：

• 有足夠多的時間來做優化嗎？
• 這個問題真的有優化的必要性嗎？
• 優化帶來的效益符合成本嗎？

因此千萬不要看完這篇文章後，就拿他去跟工程師吵架，我可不背這個黑鍋。

也許最後的方案在不久後會遇到其他挑戰，但這不就是「有問題我才有工作嗎？」

其實大部分的工程師都是可以理性溝通的，但我們無法接受一直做「白工」和「重工」，今天筆者想透過一個案例來跟大家分享「客戶、PM、工程師」之間思維的差異，並提出可以改善的方案。

本文提及之專案、人物、事件純屬虛構，如有雷同，實屬巧合，請勿對號入座。

大綱
一、工程師說 Loading 太重，可以請你幫忙分擔嗎？
二、需求不斷變更，緩衝時間再多也不夠用！
三、可是客戶態度很強硬啊！東西真的不符合他們需求
四、整理不完的例外，變更不斷的需求
五、從源頭解決問題，不是每個問題都要靠程式解決
六、客戶未必具備工程背景，要協助他們表達需求
七、我們要如何調整，讓未來的合作更加順利

一、工程師說 Loading 太重，可以請你幫忙分擔嗎？

PM 反饋這個問題後，我打開專案管理系統，看那位抱怨 Loading 太重的工程師手上有哪些 Ticket，是否需要做適當的調整。

結果仔細一看才發現，儘管那位工程師在這個 Sprint 中只剩下 2 張 Ticket 尚未完成，但有一張「匯出 Excel 報表」的 Ticket 預估時程遠遠超過之前在 Sprint Planning 的預估（4➝15）。

因為剩下的 2 個 Ticket 都是這次 Sprint 的核心功能，且距離結束只剩不到 2 個工作天，因此 PM 希望我可以接手那個估時已經到達 15 小時的 Ticket，讓工程師專注處理剩下的 Ticket。

跟 PM 談到這裡的時候我覺得有點奇怪，之所以將匯出 Excel 報表的 Ticket 分配給那位工程師，就是因為他之前有實作的經驗，沒道理在這個地方卡這麼久。

二、需求不斷變更，緩衝時間再多也不夠用！

為了釐清這個問題，我跟 PM、工程師開了一個臨時會議，去了解是什麼原因導致一個不困難的 Ticket 花了這麼多時間。

此時我才從工程師那邊了解到另一個事實，其實對他而言，匯出 Excel 報表的功能並不複雜，Loading 太重的原因是客戶不斷變更需求，導致這個 Ticket 的估時不斷增加，但預計交付的日期並沒有延長，因此時間壓力會全部壓到工程師身上。

我在詢問這個需求變更的頻率有多高時，工程師表示把新版交付出去後，可能再過 3、4 個小時就會收到新的需求變更；儘管每次修改都不會花太多時間，但架不住這麼頻繁的更動啊！

當需求變更導致一直做白工、重工，就可能讓工程師工作效率下降，甚至可能在完成功能後故意拖一段時間再交付；畢竟提早交付沒好事，只是讓自己的工作量變更多而已。

三、可是客戶態度很強硬啊！東西真的不符合他們需求

客戶花錢請我們做系統，當然是希望做出符合他們實際業務需求的產品；站在客戶的立場上，他們當然會用最嚴格的標準在看待每一個功能。

但站在我們的立場上，在人力資源固定的狀態下，每多一次需求變更，我們就需要花更多的時間與精力去完成，甚至導致部分同仁需要加班。

為了解決這個問題，我請 PM 跟客戶約一個時間，一起了解需求不停變更的原因是什麼，不然這樣一直改下去其實是在浪費彼此的時間。

四、整理不完的例外，變更不斷的需求

客戶是一個專門提供材料出貨的公司，在深入訪談後，才了解需求之所以會一直變更，是因為這個 Excel 報表始終沒有決定一個固定的版本，會這樣是因為過去客戶在填寫出貨單時沒有律定格式，同一個材料可能有 10 幾種表達方式。

過去沒有遇到這個問題，是因為之前的出貨單都是 Case by Case，所以他們材料名稱儘管不統一，但依舊能夠看得懂；可是如果把好幾張出貨單放在一起看，就會因為資料很難整合而產生許多問題，這也是客戶找我們做系統化的原因。

下面用手機來舉個例子，我們手機有前鏡頭，假使在出貨單上顯示：「前鏡頭、前置相機、front camera、Front Camera、frontCamera」我相信大家都看得懂這是指同一個東西；但如果管理階層想要知道公司這個月到底賣了多少個「前鏡頭」，下屬就需要畫很多時間做比對跟整合。

除了相機的案例外，這邊再舉一個螢幕的例子，每個手機螢幕的尺寸大小不同，因此出貨單上有各自的命名；當管理階層想了解這個月總共賣了多少個「螢幕」，下屬會因為出貨單的材料沒有階層的概念而整理到崩潰。

在了解客戶的痛點後，我們就知道這是因為過去「命名不統一、材料缺乏階層概念」導致的問題。

PM 一開始也是從這個方向去處理問題的，他先請客戶將期望的命名、材料的階層整理出來，然後請工程師依照規格去統整；儘管這個方案看似沒有問題，但因為客戶當時在填寫出貨單時，命名太過狂野，因此有非常多的例外需要處理，而每發現一個例外就要請工程師調整程式。

五、從源頭解決問題，不是每個問題都要靠程式解決

了解來龍去脈後，我想也許我們都把問題搞複雜了，既然我們都知道問題是在出貨單上，為什麼不要從源頭來解決這個問題呢？

如果出貨單的格式沒有律定，在未來同樣的問題還是會發生；因為出貨單上每天都可能會誕生新的名詞，而新的名詞會無法自動歸類，可以料想到就算現在符合客戶的需求，在未來還是會有許多衍生問題。

當然過去的歷史業障很難要求客戶調整，「統一名詞、確定階層」還是一個必要的工作；但也許我們可以先用過去的出貨單模擬客戶期望的 Excel，而不是不斷請工程師修改程式。

若發現有缺少、錯誤的材料先記錄下來，累積到一定的量後再請工程師修正，不然他會改到瘋。

同時為了讓錯誤的歷史在這個階段就停下，我們需要請客戶與填寫出貨單的部門溝通，律定「出貨單」填寫的格式。

如果涉及到客戶公司內部，盡可能讓他們「自行協調」，我們做好「引導的角色」就夠了，如果由我們向客戶的其他部門提出需求，那破局的機率非常高。

六、客戶未必具備工程背景，我們要協助他們表達需求

其實就算是公司內部的溝通也是不容易的，起初填寫出貨單的部門對律定格式這件事反彈極大，因為他們原本都做得好好的，現在變得要依規範行事。

在了解到客戶推行的困難點後，我們製作了一張高達數百個欄位的 Excel，並請客戶向填寫出貨單的部門展示，讓他們體會到混亂的格式造成什麼後果。

在這之後他們才理解為什麼格式需要律定了，也了解公司導入這個系統就是希望把流程標準化，減少報表製作的時間，不是想要刁難他們。

七、我們要如何調整，讓未來的合作更加順利

儘管這個問題最後在多方的協作下圓滿解決，但其實中間有許多摩擦是可以在初期避免的。

Tech Lead

若發現某個 Ticket 的估時逐漸增加，要主動向工程師詢問實際狀況，因為有些細節在 Scrum Meeting 並不會提及。

若發現工程師在做重工、白工，要先釐清問題來源；不是每個問題都要靠程式解決，我們可以先嘗試跟客戶溝通。

PM

如果客戶提出的需求變更太過零碎、頻繁，可以先記錄下來，等累積到一定的量，或是明確需求後再交給工程師處理。

如果發現需求能用模擬的就先用模擬的，盡可能不要讓工程師把時間耗在有高機率做白工的需求變更上。

工程師

如果發現需求變更的內容不合理、次數太多，可以即時與 Tech Lead 反應，而不是用加班默默把需求的吃下來。

希望這個案例對讀者日後執行專案時有幫助，如果還有其他建議也歡迎留言分享喔～

工程師血淚史
▋ 團隊在系統開發上遇到了哪些問題
▋ 需求不斷變更，到底哪個環節出錯了(本篇)
▋ 當 Scrum Master 跟 PM 同時存在，權力與責任該如何區分？
▋ 如果沒有明確的開發流程，團隊將會無所適從
▋ 你知道對專案來說，README.md 有多麼重要嗎？

在驗收階段你就知道一個好的需求規格書有多麼重要

今日目標

1. 了解驗收過程中需求規格書的重要性

2. 談需求變更

3. 將新的爬蟲資料寫到最前面，日期為由近而遠的排序

3.1 插入一個空白欄位：insertEmptyCol

3.2 把空白欄位更新成最新的追蹤人數資訊

1. 了解驗收過程中需求規格書的重要性

驗收的過程就是按造需求規格上的驗收項目一一測試，所以如果沒有需求規格書或是需求規格書寫得太不完善，你在驗收的過程會一直被凹新功能，而這些功能基本上只能忍氣吞聲吃下去，畢竟這是因為你在一開始沒談好規格的歷史業障，這就是我在Day 1提到需求規格書的重要性

2. 談需求變更

反過來如果你需求規格寫得夠好，在驗收的階段你會有很多賺外快的機會，因為大部分的客戶在驗收階段才想到他們實際上還需要哪些功能

對於這些多出來的功能我一律列入需求變更，因為這些需求並不在原合約內所以你可以將客戶的新需求記錄下來依功能報價讓客戶自己決定需要新增哪些功能

根據個人經驗，在結案後你會發現這些多出來的需求變更可能占總外包費的 20%~40% 不等，所以各位在接案時千萬不要因為覺得麻煩沒有好好寫需求規格書啊！你這樣的做法完全在跟自己的錢包過不去，讓自己成為免費勞工。

下面用今天要完成的需求變更舉例：

客戶：我測試了幾天覺得爬蟲蠻穩定的，但最新的爬蟲資料都寫在最後面，這讓我要滑到最後面才知道最新資料，他能不能新資料都寫在最前面啊 (客戶提出需求變更)

我：您的意思是要將新的爬蟲資料寫到最前面，Google Sheet 上呈現的是日期由近而遠的排序嗎？ (確認需求變更的邏輯)

客戶：對，麻煩了

我：不過這項需求並不在原本的需求規格書上面，原本的需求規格書只提到爬蟲日期為欄，粉專標題為列，並沒提到排序方面的需求；經過評估這個功能需要額外的費用XXX，您可以接受嗎？ (提出需求規格書上面的規格做佐證，並說明這個新功能需要加收多少費用)

客戶：恩…可以

我：我把這項規則加到需求規格書的後面，您確認完後我就會開始實作 (讓客戶確認規格及價格後在開始實作)

3. 將新的爬蟲資料寫到最前面，日期為由近而遠的排序

因為沒找到可以一步完成的解法，所以我將這個需求拆成兩個步驟：

1. 先在第二欄插入一個空白欄位
2. 把空白欄位更新成最新的追蹤人數資訊

3.1 插入一個空白欄位：insertEmptyCol

在Google Sheets中插入空白欄位的部分請參考官方的文件，這裡有個需要注意的點：

• 我們觀察到 Google 插入欄位的 api 在 range 的參數上需要 sheet_id 來能執行，而這隻函式會被 writeSheet 函式呼叫，所以下一步我們要對他做一些調整

async function insertEmptyCol (title, sheet_id, auth) {//插入空白欄位
  const sheets = google.sheets({ version: 'v4', auth });
  const request = {
    // The ID of the spreadsheet
    "spreadsheetId": process.env.SPREADSHEET_ID,
    "resource": {
      "requests": [{
        "insertDimension": {//插入新欄位
          "range": {
            "sheetId": sheet_id,
            "dimension": "COLUMNS",
            "startIndex": 1,//代表插入範圍從第一欄開始到第二欄結束
            "endIndex": 2
          },
          "inheritFromBefore": true
        },
      }]
    }
  };
  try {
    await sheets.spreadsheets.batchUpdate(request)
    console.log('update sheet:' + title + ' new column')
  }
  catch (err) {
    console.log('The API returned an error: ' + err);
  }
}

3.2 把空白欄位更新成最新的追蹤人數資訊

因為insertEmptyCol這個函式需要用到用到 sheetId 的參數，我們需要對以下程式做調整：

1. updateGoogleSheets：還記得 getFBIGSheet 會回傳 sheets 的資訊嗎？現在我們就需要裡面的title、id

   const sheets = await getFBIGSheet(auth)//取得線上FB、IG的sheet資訊
   
   // 寫入各自的Sheet
   for (sheet of sheets) {
     if (sheet.title === 'FB粉專') {
       await writeSheet(sheet.title, sheet.id, fb_result_array, auth)
     } else if (sheet.title === 'IG帳號') {
       await writeSheet(sheet.title, sheet.id, ig_result_array, auth)
     }
   }
   

2. writeSheet :

   1. 傳入 sheet_id 參數讓 insertEmptyCol 使用

      async function writeSheet (title, sheet_id, result_array, auth)
      

   2. 先插入空白欄位後再寫入追蹤人數

      // 插入空欄位
      await insertEmptyCol(title, sheet_id, auth)
      // 寫入追蹤人數
      await writeTrace(title, trace_array, auth)
      

   因為取得最後一欄的函式用不到了，請將getLastCol、toColumnName刪除

執行程式

1. 在專案資料夾的終端機(Terminal)執行指令

   yarn start
   

2. 在終端機我們可以看到事先插入新欄位再更新資料

   

3. 確認新的爬蟲資料有正確插入到 Google Sheets 第二欄

   

   如果你在同一天測試，你可以把之前爬蟲日期改成old方便辨識

ℹ️ 專案原始碼

• 今天的完整程式碼可以在這裡找到喔
• 我也貼心地把昨天的把昨天的程式碼打包成壓縮檔，你可以用裡面乾淨的環境來完成業主要求的需求變更吧
  • 請記得在終端機下指令 yarn 才會把之前的套件安裝
  • windows需下載與你chrome版本相同的chrome driver放在專案根目錄
  • 要在tools/google_sheets資料夾放上自己的憑證，申請流程請參考Day17
  • 調整fanspages資料夾內目標爬蟲的粉專網址
  • 調整.env檔
    • 填上FB登入資訊
    • 填上FB版本(classic/new)
    • 填上IG登入資訊
    • 填上SPREADSHEET_ID

在許多人的幫助下，本系列文章已出版成書，並添加了新的篇章與細節補充：

• 加入更多實務經驗，用完整的開發流程讓讀者了解專案每個階段要注意的事項
• 將爬蟲的步驟與技巧做更詳細的說明，讓讀者可以輕鬆入門
• 調整專案架構
  • 優化爬蟲程式，以更廣的視角來擷取網頁資訊
  • 增加資料驗證、錯誤通知等功能，讓爬蟲執行遇到問題時可以第一時間通知使用者
  • 排程部分改用 node-schedule & pm2 的組合，讓讀者可以輕鬆管理專案程序並獲得更精確的 log 資訊

有興趣的朋友可以到天瓏書局選購，感謝大家的支持。

購書連結：https://www.tenlong.com.tw/products/9789864348008