MapleCheng

在浩瀚的網路世界中無限潛水欸少年郎!

0%

固定維運不是雜事,是團隊不再每天失憶的產品力

最近我越來越有一種感覺:很多技術團隊不是缺能力,而是每天都在失憶。

昨天修過的東西今天忘了,週會講過的重點下週蒸發,交接時只能靠聊天紀錄拼圖,然後每個人都覺得自己很忙、做很多,但一回頭卻很難說清楚到底累積了什麼。這種狀態最麻煩的地方,不是效率低而已,而是整個團隊的判斷品質會慢慢被稀釋。

我這陣子花了不少時間把一些「看起來只是固定維運」的事情自動化:備份、記憶歸檔、每日工作摘要、站會日報、內容整理。做完之後我才更確定一件事——這些事情不是雜事,它其實是團隊基礎設施的一部分。

技術團隊最常見的浪費,其實不是寫錯 code

講到效率問題,大家第一反應通常都是 build 太慢、部署太卡、測試不夠完整,或者某段 code 太醜。這些當然都是真的,但我覺得更常見、也更隱性的浪費,是資訊流失。

資訊流失有很多長相:

  • 某次 debug 的關鍵原因沒有留下來
  • 某個設計決策只存在會議口頭結論
  • 昨天做了哪些事,要到隔天站會前才臨時回想
  • 明明做過一次整理,下次又得從頭再查

這種浪費最可怕的地方,在於它不會像 error message 一樣大聲尖叫。它只是讓團隊一直處在「好像都有在動,但一直沒有真正往前很多」的狀態。

我自己以前也很常把這類工作視為附屬品。心態大概是:真正重要的是交付功能,這些整理、記錄、歸檔,有空再做就好。後來發現不對。因為當記錄是靠意志力維持,它就一定會在最忙的時候先被犧牲。而最忙的時候,偏偏也是最需要留下脈絡的時候。

把固定維運當成產品,而不是手工儀式

我後來轉了一個角度思考:如果這些流程每天都要做,那它就不該是「提醒自己記得做」,而應該被設計成「系統自然會做」。

差別很大。

前者是靠責任感硬撐,後者是把責任感轉成機制。

像是下面這種流程,如果還靠人工,其實很容易斷:

            
            flowchart TD
    A[一天的工作與對話] --> B[蒐集變更與事件]
    B --> C[整理成 daily memory]
    C --> D[產出站會摘要]
    C --> E[歸檔舊記憶]
    E --> F[沉澱成長期知識]
    B --> G[自動備份]
          

這張圖看起來很普通,但我後來越來越覺得,這種普通流程才是真正決定團隊穩不穩的地方。

因為它處理的是連續性。

功能開發解決的是「今天要做什麼」,維運自動化解決的是「明天還記不記得今天做了什麼」。而後者如果沒解,團隊就很難有真正的複利。

自動化之後,最大的改變不是省時間

說實話,剛開始做這些流程時,我也以為重點是省時間。後來發現不只如此,甚至很多時候不是「比較快」,而是「終於穩定」。

以前人工整理的狀態很像這樣:

  • 忙的時候先跳過
  • 晚一點再補
  • 補的時候記憶已經斷層
  • 為了補洞,只好憑印象寫
  • 寫完看起來有東西,但可信度其實下降

這不是懶,是人類本來就不適合長期當背景程序。

自動化之後,改善最明顯的是三件事:

  • 記錄比較即時,不用靠隔天回想
  • 脈絡比較完整,交接和回顧都輕鬆很多
  • 團隊成員比較不會因為資訊散落而重工

更直接一點講,很多「我記得好像有做過」的模糊狀態,會慢慢變成「我知道在哪裡,而且能回頭驗證」。這種感覺超重要。因為技術管理本質上不是記得越多越厲害,而是需要時能夠穩定找回正確脈絡。

維運自動化其實是在降低管理摩擦

我做技術管理這幾年,一個很深的體感是:團隊摩擦常常不是來自能力差,而是來自上下文不對齊。

舉幾個常見場景:

  • 工程師以為需求還沒定,但其實已經有結論
  • PM 以為某件事還沒動,但實際上昨天已經處理一半
  • 站會報告講得很散,因為大家都在現場回想
  • 回顧會議花一半時間在確認「當時到底發生什麼事」

如果把這些摩擦都攤開來看,本質上都是資訊沒有被穩定保留,也沒有被整理成適合下一個流程使用的格式。

所以自動化不是只有替代人力,而是把一段資訊流變成下一段流程的可靠輸入。這才是它真正值錢的地方。

我現在會把這種流程叫做「內部產品」。它不是賣給客戶的,但它的使用者是真實存在的:未來的自己、同事、接手的人、下週要開會的你。

如果一個內部流程每天都有人用、用了會降低錯誤、沒了大家會痛,那它就是產品,只是剛好沒有掛在官網上而已。

不是什麼都該自動化,而是要挑有累積性的部分

當然,也不是每件小事都值得拉進自動化。什麼都自動化,很容易走火入魔,最後變成維護自動化本身比手做還痛苦。這我也踩過。

我現在比較偏向用三個條件判斷:

  • 會重複發生
  • 做不好代價高
  • 結果有明確輸出格式

符合這三點的流程,通常就很值得做。

像是備份、daily log、狀態摘要、例行報告、知識沉澱,幾乎都符合。反過來說,如果某件事一年只做一次,而且每次情境差很多,那就先不要急著自動化,免得把彈性一起犧牲掉。

技術主管該優先投資的,不只是交付速度

如果你也帶團隊,我真的很推薦重新看待「固定維運」這件事。

很多時候,團隊感覺卡,不一定是因為大家不努力,也不一定是工具不夠強,而是基礎的連續性沒被照顧好。沒有可靠的記錄、摘要、備份、歸檔,再強的人都會被背景噪音慢慢拖垮。

而一旦這些底層流程穩下來,你會發現很多事情自然變順:

  • 開會不再每次重講背景
  • 站會比較像同步,不像考記憶力
  • 決策能被追溯,不靠印象吵架
  • 新加入的人比較容易接上脈絡

這些東西表面上不華麗,但它們真的會改變團隊每天的工作質地。

所以現在如果有人問我,固定維運到底算不算重要工作?我的答案會很直接:算,而且它不是附屬品。

它是一種讓團隊不再每天失憶的產品力。

如果這篇剛好讓你想把某個一直靠人撐著的流程系統化,那我最近折騰這些內部基礎設施,應該就不算白忙了。