人力招募 - 零、準備篇:確認需求、條件、定位、市場狀況


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


零、準備篇:確認需求

確認人力需求

招募前,先問這些問題:

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

更進一步的問:

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

內部的共識:

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

工作描述

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

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

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

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

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

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

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

更多任務與技能的說明,參閱: Role And Responsibility

英文?

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

公司、產品、客戶介紹

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

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

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

曝光管道

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

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

底下是幾個常見的管道:

職等

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

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

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

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

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

問題

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

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

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

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

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

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

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

結論

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


延伸閱讀

系列文章

站內延伸


Comments