整理人力招募的起手式 準備篇：確認需求、條件、定位、市場狀況。

零、準備篇：確認需求

確認人力需求

招募前，先問這些問題：

• 這個角色的定位是什麼？主要任務？產出如何量化？
• 這個角色需要的技能、人格特質，包含硬技能、軟技能

更進一步的問：

• 這樣職能在市場多？市場哪裡有這樣的人？類似的職務？職稱？
• 薪資水準？如何衡量的？
• 所需技能能否自己培養？這樣的職能能做多久？
• 他的職涯規劃 (Career Path) 是什麼？

內部的共識：

• 上層對於這個職務工作產出的認知？薪資範圍？
• HR 對於這個職務的看法？

工作描述

都問過這些問題之後，可以開始準備 工作描述 (Job Description, JD)，一般會有兩個要寫：

• 任務 (Mission)：工作內容與範圍，要達成的目標
• 技能 (Skills)：所需要技能，分成必要、與加分

任務通常是目的導向，需要較多 軟技能，包含實際執行任務、溝通、表達、協作、團隊合作、組織能力、自我學習 … 等；技能通常是基本能進入的門檻與條件，大多是 硬技能，例如要會寫某種程式語言、要能演奏什麼樂器 … 等。

技能是技術人的檢驗第一關，寫需求要注意的是：

• 要得越多，相對應的薪資期待就會越高。
• 要的技能越獨特，就越難找。
• 技能的 深、淺 自己心裡要有一把尺，例如什麼叫做 精通 Java、Cloud 專家？
• 寫得越多，面試檢驗就會越複雜，也會被社會大眾檢驗。
• 寫得越多，面試題目越難設計。
• 寫得越清楚，越容易找到適當的人，反之亦然。
• 對於這些形容詞心裡的尺要很清楚：初階、技能、經驗、專業、資淺、資深、專家、大師

寫 JD 的同時，心理對於這個角色的定位最好有清楚的輪廓，包含他在組織的位置、薪資範圍、未來發展性 … 等面向。

完成這些部分，可以請 HR 在 JD 描述做一些包裝，增加公司文化、產品介紹、福利 … 等。

更多任務與技能的說明，參閱： Role And Responsibility

英文？

要考慮一下 JD 是否用英文寫，好處是可以做適度的篩選，看不懂英文的人根本就不用考慮。但要面對的現實是，通常來應徵的人要求也會相對比較高，這樣的狀況，要事先跟 HR 以及上層管理者溝通好，避免因此浪費時間。

公司、產品、客戶介紹

一般 JD 只有針對角色的技能、任務做說明，招募除了這些，另外很重要的面向還有：

• 這家公司是做什麼的？
• 產品是什麼？
• 客戶是誰？

透過梳理這些，讓自己、讓面試者更能夠清楚認識彼此，找到長久合作的共同目標。

曝光管道

確認前述的狀況，寫好了 JD，接下來就是 JD 放哪了？人力銀行是最常見的做法。

這幾年軟體工程師很喜歡放在 Github 上招募，主要目的是讓吸引工程師的注意，覺得公司有著工程文化的特質。

底下是幾個常見的管道：

• https://jobs.github.com/
• https://github.com/DevOpsTW/jobs/issues
• https://github.com/golangtw/jobs/issues
• https://github.com/f2etw/jobs/issues

職等

這個角色資淺、資深、專家的定義與差異，以下這些問題要想過：

• 資淺 至少的條件是什麼？技能？經驗？薪資範圍？職等？Title？
• 資深 至少的條件是什麼？技能？經驗？薪資範圍？職等？Title？
• 專家 至少的條件是什麼？技能？經驗？薪資範圍？職等？Title？

關於資深、專家、大師請參閱：Senior Software Developer, 也可以思考 Developer, or Engineer 的差異。

職等 每家公司定義不一樣，有些甚至屬於機密，只有人事、管理者才知道。大部分理由都是因為跟薪資有關係，薪資在台灣通常屬於機密，所以對價的相關資訊也就變能不能公開。新創事業 (Startup) 通常不會有清楚的職等、薪資範圍，也不會區分管理職或者工程職的職別，因為事業初期，求生存是主要重點，職等、薪資範圍、職別通常會在企業發展到一定階段後才會開始討論。

有些新創是依附在既有的事業體系之下 (像是併購事業、新創事業)，所以沿用既有的人事制度也是很常見的，至於制度是否合理、適用，要看新創事業的發展狀況，如果發展的好，就容易取得話語權，自然就有機會建立自己的制度，否則大多都只能仰賴既有的制度。

問題

底下整理一些會遇到的問題，不管是對內、對外、對上、對下。

Q: 對內：招募資料的寫法、格式、包裝問題。

這要跟 HR 有密切的溝通與協作，有些東西要適度包裝，像是公司的經營模式；有些東西則不要，像是工作內容、技術需求、薪資範圍，這些要越清楚越好。

Q: 對內對外：職務名稱的定位？像是 DevOps Engineer 是什麼？SRE 是什麼？

跟我共事過的人大概會知道，我對 名詞 很挑惕。所以名稱我也都會特別思考其意義，同時也會跟 HR 以及上面的人說明。

DevOps 雖然這個詞普遍是針對文化上的定義，不是職務上的，但實際執行面上來講，他是有必要的、有專業度的、有技術鏈的，換言之，不是一般開發人員可以做的。很多人會說可以從 developer 中培養，這道理反過來說也行，我也可以從 Operator 培養，但重點是，培養要時間，當要即戰力的時候，要的是專業、經驗。所以實務上 DevOps Engineer 是一個工作職務。SRE 也是。

另外盡量不要創造新名詞，因為會造成招募上的困難與矛盾，間接地作繭自縛。

結論

確認人力需求、條件、進行上層溝通是招募前的準備工作，就像開發軟體的需求管理一樣，需求不清楚，接下來的方向就容易做白工。下一個聊的是 萬事起頭難：面試名單從哪來？

延伸閱讀

系列文章

• 聊聊人力招募
• 零、準備篇：確認需求、條件、定位、市場狀況
• 一、萬事起頭難：面試名單從哪來？
• 二、見面談：招募第一關 面試
• 三、深度對談：價值觀
• 四、客觀談論：薪資
• 五、最後確認：報到時程
• 六、到職後：訓練、目標、評核
• 面試常見的問題
• 管理必經之路：遣散、解僱、辭呈

站內延伸

• Role And Responsibility
• Senior Software Developer
• Developer, or Engineer