🌪️《Prologue：混亂並非來自程式碼》

Hmmm… 這節標題滿有意思的 😎。

先說說這 XAOS 系列文的起源，
去年，我剛好遇到一間剛成立的能源軟體新創。

老實說，我加入的原因很單純。
一方面是因為沒看過一間公司從零開始長大的樣子，覺得很新鮮；
另一方面也是抱著一點好奇心，順便碰個運氣看看自己會不會搭上職涯順風車。

既然又回到軟體工程師這行，
就好好鑽研下去吧，也從技術部落格開始把自己經營起來。

回到工作近況，
只能說軟體新創真的是很恐怖。。。
如果有學歷門票的話真的乖一點去大公司上班

原本覺得 Software Engineer 就是把 code 寫一寫，有什麼好吵的

錯❌
這件事涉及誰去寫、寫什麼、怎麼設計、怎麼文件、怎麼驗收、誰決定等等
種種因素導致窒礙難行
WTF

不過我也不知道好的 Teamwork 風格是怎樣
也不確定理想的 EMS (Energy Management System)平台該長什麼樣子，
但在參與開發的過程中，
我開始看見許多以前從未注意過的事情。

而《From XAOS to Platform》這個系列，就是想把這些觀察記錄下來。

不是為了給出標準答案。
而是記錄一個工程師如何從「寫功能的人」，
慢慢開始理解什麼叫做系統、平台，以及那些課堂上學不到的現場問題。

🧭《Act I：每個人手上都有不同的地圖》

要打造一個 EMS，
顧名思義就是把各種能源設備接進來，收資料、做監控、做控制、做分析。

聽起來很合理。
於是剛開始的我也覺得：
不就是把設備資料收進來，然後做個 Dashboard 嗎？

結果很快發現事情沒那麼單純。
因為同樣是在做 EMS。
每個人腦中的 EMS 長得完全不一樣 甚至是沒有。

學能源的不會設計軟體、
學軟體的不懂現場、設備、電力
再加上 ＰＭ、設計師、前端工程師、主管…
溝通問題跟團隊合作可想而知。。。
就是慘不忍睹 🫣。

而且還是新創公司。
雖然我有意識到這一定會發生問題，
但我也不知道怎麼處理。

於是乎我想：
自己走一回，以後就知道怎麼解這種問題了。（🍵

🏗️《Act II：藍圖開始失控的那一天》

團隊合作的初期，
大家對於要打造的 EMS 產品很快地達成初步的共識：
虛擬電廠、數位孿生、管理主控台、數據戰情室…等等。

這些常見的名詞聽起來都很厲害，
每個人也都能針對這些概念聊上幾句。

於是產品的輪廓似乎逐漸清晰起來。

😑 至少當時我是這麼以為的。

直到開始討論具體功能，才發現事情有點不太對勁。

舉個例子，大家都同意系統需要「設備管理」功能。

但什麼叫設備？
是實體設備？通訊裝置？還是系統裡的邏輯資源？
在哪管理、怎麼操作、平台的功能怎麼解決實際用戶問題？
前後端怎麼幫資料建模、串接？

需要落地實作時才發現，
那些口頭上的討論、腦中的想法，
沒有人能把這些化為文字、規格、設計稿。

我才反應過來。
嗯，大意了。
原來是從產品規格、系統分析、系統設計我都得自己來。

⚙️《Act III：系統不只是一堆功能》

Feature Thinking → System Thinking

既然沒有人能把產品完整的定義出來，
那我就自己拆解吧。

剛好也藉這個機會驗證一下，
過去累積的軟體開發經驗，
究竟能不能支撐自己從零開始打造一套系統。

回想以前接到開發需求，
大部分都是已經先被過濾好「有商業價值的實際問題」，
才會落到我這執行者的手上，
提出軟體解決方案並實作，
交付完、驗證後就結束。

但這次面對的挑戰是：
全部都是問題。

連從哪先開始都是個問題。

我想到的辦法就是從 User Story 開始，
規劃了 user flow、API、backend architecture、DB schema。
用以前的工作方式，
達成共識再著手開發，
行不通，哈。

這次要做的，已經不只是交付功能了，
而是一個能夠持續演進、反覆迭代的系統。

需求會改變、功能會擴充，
甚至連我們對產品的理解，
也可能隨著開發過程不斷被推翻。

但很快地，我又發現另一件事。

就算系統架構設計的再好，
也不代表這個產品就能順利地開發下去。

這個系統真正需要被設計的，
不只有 Software Architecture，
還有整個團隊的工作方式。

🕸️《Act IV：那些看不見的連結》

Not just building software, but building a team that can build software.

以前總覺得，
架構設計得好、規格寫得清楚，
接下來大家照著分工實作，
應該就能把產品慢慢建立起來。

但現實不是這樣運作的。

每個人有不同的經歷背景、工作習慣，
對於問題能理解的深淺、解決方式都不盡相同。

就別說還有最麻煩的自尊問題了。

這也是我覺得最難的地方。

即使我願意分享、即使我願意投入心力，
也不代表其他人也是這樣想。

人性是這樣，
每個人都會在意自己的工作與下一步，
卻未必會考慮到其他人需要什麼，
至於主動去思考團隊的下一步就更別說了。

縱使目標跟步驟 1.2.3.4.5 都列出來了，
結果也未必跟預期一樣。

有人覺得自己做得太多，
有人覺得某些事情不在自己的職責內。

有人只想完成被交代的部分，
有人卻得不斷替那些沒被定義的事情收尾。

然後大家都覺得自己很忙。

這時候才慢慢意識到，
團隊合作並不是把工作拆開、分配下去，
就會自然形成的東西。

因為每個人的目標、能力、期待都不相同。

如果一套工作方式只能在每個人都積極、主動、負責的情況下運作，
那它真的算是一套好的工作方式嗎？

或許真正需要思考的，
不是怎麼讓每個人都變得跟自己一樣。

而是如何建立一套協作機制，
讓不同的人能夠理解彼此、承擔責任，
並且朝著共同的目標前進。

🏛️《Epilogue：從 XAOS 到 Platform》

原本是想在一邊開發產品的過程中，
一邊記錄期間發生的問題跟故事。

結果光是應付每天冒出來的問題，
就已經耗掉大量時間跟心力。

更別說我放假還想休息。

結果系列文的第一篇我就花了五個月才寫到這。

寫部落格的難度真得挺高。。。

從加入到現在也過了一年，
陸陸續續也越來越多夥伴加入，
當然也有夥伴離開。

這一年的成果說實話不如預期，
但畢竟大家也都不是在能源軟體業界有什麼資歷的人，
光是大家都還改得動 Code 就已經值得嘉許。(X

其實現在也都是 Agent 在改

不過回頭看看這一年，
確實學到不少東西，
尤其在處理跟人有關的問題上。

至於最後 XAOS 能不能走到 Platform？

我也不知道。

不過也正因為沒有答案，
才覺得這過程值得被記錄下來。

接下來就繼續聊聊那些技術決策、架構設計，
以及一路上踩過的坑吧。

希望幾年後回頭看這些文章，
能發現自己又有了不一樣的理解。

而不是當年寫了一堆 shit code。

After all, we’re still in XAOS.