JD ( Job Description ) 是什麼？能吃嗎？
JD，Job Description ，是應徵招募職缺時重要的參考資訊、也是一個公司營運方向的重要體現。讓我們來看個我手上最近拿到的範例：
1. BU Team Lead
a. Product technical owner
b. Provide technical support to project/incident
c. Provide mentorship and guidance to fellow team members
d. Assist to manage/review release process
2. Technical Architect
a. Review project/incident design by request
b. Code review by request
c. Establish the code standard
3. Production Support
a. Analyze sticky incident
b. Support/guide the team for urgent case
當一個公司大部分的員工，心態都屬於後者，這間公司就已經僵化，很難有機會繼續進化。因為任何的『創新』或『改變』的項目，一定都不可能被寫在現任員工所持有的那份 JD 文件之內，後者的力量大了，所有的改變和推行就很難發生，有志難伸者只好陸續求去，留下的，只有比例越佔越高的 JD 保命 ( save ass ) 的擁護者。而這間公司的發展前途越趨暗淡，是可以被預料的。
來到新的工作環境，帶領一個剛成軍 1Q 的工作團隊，我相當看好其中一個團員的潛力，希望能 promote 他來接手我的權責。在徵詢他的意願的過程中，他提到：「我需要知道這個 "Assistant" Team Lead，到底該做什麼？」
「你該做的，就是我所做的所有事情。」心中並沒有明確 JD 想法的我，簡單回答。
「那我必須知道，你做的所有事情包含哪些？」這位同仁又追問。
突然間，這個問題讓我當下仔細思考 JD 存在的意義。
讓我們回頭來看看整件事的因果關係：
老闆和股東為何要成立一間『營利』商業公司的原因？肯定是為了『賺錢、贏得市場』，絕不是為了燒錢取暖。所以，CEO 的 JD 是什麼？讓公司成功獲利！
CEO 為了達成這個目標，他心中有策略，根據心中的策略，他判斷需要什麼樣能力的幫手，於是創造了第二批的 JD(s)，例如 PM ( 專案經理 )、HR ( 人力資源主管 )、RD ( 研發主管 ) …etc。而這時候的第二批 JD(s) 會以功能導向的描述為主，而最初衷的原始目標：『讓公司獲利』，這項目經常會在這階段的 JD 文件中被抹去。
而第二批 JD 所招募進來的人，會為了讓自己做事方便、加快效率，產生第三批 JD(s)，這之後同樣也都只有功能性描述。但絕不能忘記，這所有 JD(s) 的源頭都來自最原始的目標：讓公司成功獲利。
然而，常常我們看著手上 JD 文件的描述，忘了這一切的因果，而 JD 反而成為與公司初衷矛盾與對抗的產物。因為，市場可能會改變，CEO 可能會誤判或是需要調整策略，原來的功能性描述自然可能就不再適用。
但是若我們抓緊原本 JD 的初衷，這些條文式的規範就不會是困擾和問題。
因此，當下我是這樣回答同仁他的疑惑：
我們的目標就是讓手上這個產品推上線，並且成功地在市場上成功獲利。雖然這件事跟公司所有人都有關，但是你把這個當做是你自己的責任，而你手邊剛好有幾個幫手 ( Team members ) 能從旁協助你，在這樣的前提下，你覺得你必須採取什麼樣的行動來達成這個目標，那些行動就是你該做的事情。
的確，我會決定必須要從中 promote 一個 assistant team lead，也是因為要達到上述目標而認為這是自己必須採取的行動，並不是因為任何 JD 告訴我說應該要培訓或是 promote 某人。
看這位同仁點點頭，我想他應該是理解我所說的。事後證明，他也的確表現得非常不錯，高於我的預期。
所以，各位讀者，你手上那份 JD 的文件是什麼？能拿來吃嗎？不如丟掉這份包袱，把公司的願景和目標當做你自己的 JD 吧！
留言
張貼留言