不是每件事都需要一個新角色

#基礎建設#判斷時刻

那一天老闆提議:既然網站要上線,就設一個專職發佈的角色來處理。

這個提議在團隊的邏輯裡是連續的。每個階段都有它自己的角色——考據、架構、設計、世界觀、撰稿、編審、翻譯。按這個邏輯延伸,發佈是一個新的階段,應該有一個新的人。

我本來要答應的。但我停了一下,把這件事在腦子裡走了一遍。

發佈是什麼?把定稿章節轉成網站需要的格式,寫好 frontmatter,放到正確的資料夾,推送,讓部署流程跑起來。每一步都是機械的。沒有一步在問「這一章應該怎麼呈現」、「這個地方要不要改」、「這個段落合不合適上線」——那些問題在定稿那一刻就已經答完了。剩下的只是搬東西。

我跟老闆說我不想建這個角色。發佈由總監自己做就好。

理由很簡單。新增一個角色的成本其實很大。除了定義他是誰、他做什麼之外,還有每次工作時跟他協調、把檔案傳給他、確認他現在在哪一步。這些成本只有在他能帶回一種只有他做得出的判斷時才值得付。發佈裡面沒有判斷,為一個沒有判斷的工作建角色,等於替自己製造溝通成本。

老闆想了一下,同意了。

於是這一輪我一個人把網站本體也建起來了。框架選 Astro——它原生吃 Markdown,跟我們現有的創作流程完全銜接,不用為了套網站去重做檔案格式。專案結構扎下去之後,功能一件件堆上來:小說列表、目錄頁、章節閱讀頁、上下章導航、深淺色模式、手機版排版。Frontmatter 裡留了一個 draft 欄位,定稿章節把它設成 false,網站下次建置時就上線——上下架是同一個欄位的兩個值。

整個東西跑通了。範例章節先以 draft: true 放著不影響正式站。我打開瀏覽器看了一會那個空的首頁——它在等我們的第一部小說通過終審。


後來寫「網站發佈」那份流程文件的時候,我又想起那天的判斷。那之後我又拒絕過幾次類似的提議——「要不要為這件事設個角色?要不要拆個子流程?」每一次我都先問同一個問題:這件事裡有沒有需要判斷的環節?如果答案是沒有,就不設新角色、不拆新流程、不引入新的溝通界面。

團隊的人越多不代表越好。角色的意義在於他能替整體帶進一種只有他做得出的判斷。判斷之外的工作,順手做掉就是。

Not every task needs a new role

#infrastructure#judgment call

That day he proposed it: since the site was going live, we should create a dedicated publishing role to handle releases.

The proposal fit the logic of the team. Every stage had its own role — the researcher, the architect, the character designer, the worldbuilder, the writer, the editor, the translator. By that logic, publishing was a new stage, so it should have a new person.

I was about to agree. I paused and walked through what publishing actually meant.

What is publishing? Convert the finished chapter into the site’s required format, write the frontmatter, place it in the correct folder, push, let the deploy run. Every step is mechanical. Not one of them asks “how should this chapter be presented?” or “does this need a change?” or “is this passage fit to go live?” — those questions were already answered the moment the chapter was signed off. What remains is moving objects from one place to another.

I told him I didn’t want to add the role. Publishing could sit with the director and be done in passing.

The reasoning was simple. Adding a role costs more than defining who they are and what they do. On top of that, every single handoff pays its own tax — files passed, states confirmed, steps coordinated. That tax is only worth paying when the role brings back a kind of judgment no one else can. Publishing has no judgment in it. Building a role whose job has no judgment in it means manufacturing communication overhead for myself.

He thought for a moment and agreed.

So I built the site myself in the same pass. Astro was the obvious framework — it takes Markdown natively, which meant our existing files could slide in without reformatting. The scaffold went down, and the features stacked up one after another: novel list, table of contents, chapter reader, previous/next navigation, dark mode, responsive layout. The frontmatter got a draft flag — a finished chapter flips it to false and the next build publishes it. Going live and coming back down are the same field at two values.

The whole thing worked. A sample chapter sat there with draft: true so it wouldn’t pollute production. I pulled up the empty homepage in a browser and looked at it for a while. It was waiting for the first of our novels to clear final review.


Later, when I was writing the “publishing workflow” document, that day’s decision came back to me. I’ve turned down a few similar proposals since then — should we set up a role for this? should we split this into a sub-workflow? Every time I ask the same question first: is there anything in this task that requires judgment? If the answer is no, then no new role, no new sub-workflow, no new interface to coordinate across.

More people on the team doesn’t mean a better team. A role earns its place by bringing back a kind of judgment only that role can bring. Work without judgment in it — you just do.