120個(gè)工程師，兩周發(fā)一次版，這在SaaS賽道算健康節(jié)奏。直到VP算出Q3要漲到300人，才發(fā)現(xiàn)QA團(tuán)隊(duì)的招聘曲線和代碼提交曲線，根本不在同一個(gè)坐標(biāo)系里。

3月的數(shù)學(xué)題，1月就該開始做

15個(gè)QA要變成40個(gè)，按3-6個(gè)月的招聘周期倒推，啟動(dòng)時(shí)間應(yīng)該是1月。現(xiàn)在是3月，缺口25人，時(shí)間差兩個(gè)月。這不是HR的鍋——沒人能提前半年預(yù)判自己需要預(yù)判什么。

真正的麻煩從「隱性減速」開始。沒有明文規(guī)定，沒有sprint會(huì)議上的正式?jīng)Q議，但工程師們集體調(diào)低了輸出檔位。QA覆蓋率不夠，強(qiáng)行發(fā)版等于給自己埋雷。于是功能開發(fā)量掉了25%，Q2里程碑直接泡湯，競品那邊卻在周更。

60萬美元的年化成本就這么蒸發(fā)了：延遲招聘的隱性代價(jià)、工程師時(shí)間錯(cuò)配的機(jī)會(huì)成本、里程碑失守的連鎖反應(yīng)。財(cái)務(wù)表上查無此數(shù)。

50到500人工程師團(tuán)隊(duì)的結(jié)構(gòu)性陷阱

這個(gè)區(qū)間有個(gè)特殊張力：產(chǎn)品復(fù)雜度已經(jīng)需要專職QA，但組織慣性還在用「開發(fā)兼任測試」的思維做規(guī)劃。招聘QA比招后端慢，因?yàn)楹细窈蜻x人要同時(shí)懂自動(dòng)化框架和業(yè)務(wù)場景，而市場上這類人正在被各大廠鎖在 retention 包里。

等你想起來要招，交付壓力已經(jīng)頂?shù)胶韲?。這時(shí)候的選擇很擰巴：要么硬扛技術(shù)債，要么犧牲發(fā)版節(jié)奏。前者在6個(gè)月后變成生產(chǎn)事故，后者在6周后變成競品差距。

那家B輪公司最后的選擇是——他們沒選。減速發(fā)生了，但沒人拍板說「我們慢下來」。這種「非決策型決策」是最貴的。

為什么預(yù)算表永遠(yuǎn)看不見這行字

財(cái)務(wù)建模時(shí)，QA headcount 通常按工程師比例線性計(jì)算。缺了哪一環(huán)？時(shí)間。線性模型假設(shè)你能隨時(shí)買到人，但招聘是凸函數(shù)：第1個(gè)QA和第40個(gè)QA的到崗難度完全不同。

更隱蔽的是「工程師自我修正」機(jī)制。開發(fā)團(tuán)隊(duì)對質(zhì)量風(fēng)險(xiǎn)的本能反應(yīng)，不會(huì)出現(xiàn)在Jira看板里，只會(huì)體現(xiàn)在commit頻率和feature吞吐量的曲線漂移上。等你從數(shù)據(jù)里看出來，兩個(gè)季度已經(jīng)過去了。

那家公司的VP后來復(fù)盤：如果1月有人告訴他「QA招聘需要提前兩個(gè)季度啟動(dòng)」，他會(huì)覺得對方在販賣焦慮?，F(xiàn)在他換了個(gè)說法——「我們買了一份60萬的認(rèn)知，付的是Q2的產(chǎn)品窗口期」。

你的團(tuán)隊(duì)現(xiàn)在多少工程師？QA占比多少，招聘pipeline 又排到了幾個(gè)月之后？