我在“六种岗位类型”里提出一个观点，岗位就是对组织任务的分解，按任务是否明确、分配是否饱满，可以将岗位分为六种类型，每种类型岗位都有自己的风格，和管理上应该注意的地方。
有了对“岗位”和“组织任务”间逻辑关系的基础认识，我们讨论一个更具体的问题——“怎样设置岗位呢？”
比如：
如果企业按成本倒推，规定某部门只能有10万/月的工资预算，那定什么岗位，几个人，该如何决策呢？
如果部门整体绩效完成不好，但每个人又都很忙，不能加人又要解决问题，怎么办？
这些问题场景都要通过岗位分析来解决。
岗位是装好了组织任务的细胞，岗位和岗位串起来，构成了组织的晶体结构。
我有一个观点，从组织的角度看，没有完全独立的岗位，每个岗位都至少有两条“触角”，也就是说，任何一个岗位都有它的内部客户（向别人产出价值），且它自己也是其他岗位的内部客户（向别人提出需求）。这个岗位之间一环扣一环的东西，就是组织的“内部业务价值链”。
对这个概念的认知非常重要，它对HR的启发是，当要分析岗位时，先去搞清楚它在组织中价值链的闭环。
说起来挺玄乎的，做起来却很明确。
一张图
第一步，请你去画一张图。
对，画一张岗位“需求接入——岗位任务——价值产出”的图。
HR们检视下自己对岗位的理解透不透彻，看懂JD只是初级水平，你并不能做判断，能画出这个图才算上了道。
拿曾经盘点运维部的岗位举个栗子，运维部的工作非常重要，因为客户发现产品出了问题，会第一时间找运维，产品可不可用，到运维手里跑跑便知。
所以，运维岗的内部业务价值链上，前端接产品、研发，工作前置到需求讨论环节，后端接研发、客户，运维信息要及时同步，第一时间发现、解决问题，甚至预防问题的发生。
而运维部内部，可以按时间顺序，梳理出任务。
一个表
第二步，请你去填一张表。
组织任务理清了，接下来就是定岗位，那就要弄清楚，每个任务的标准是什么，岗位的边界在哪里（权力和责任）。
弄清楚任务标准，就可以明确干这个活的人，他需要怎样的能力和经验；弄清楚边界，就可以明确软性的、或者可迁移的能力和经验要求（比如，“给研发提要求”，得要敢提，懂程序猿们的语境和心态，最好主动知道什么时候提等）。
定岗
第三步，定岗。
就是说，这些事儿，交给哪些人，多少人完成。
操作上面，按照任务标准先解构出硬性能力要求（知识、经验、对工具的操作等），再描绘出软性能力要求（个性、能力、素质等）。
这会儿是不是感觉熟悉了，对，这就形成了咱们HR喜闻乐见的“岗位说明书”。
模板就不放了，网上一搜一大堆。只叨叨几个要注意的点：
1、这么做来滴，才是有效滴，不是形式化滴。
2、还记得岗位是杯子的那个比喻吗？设置岗位任务时，七分即可，不宜过满，就像杯子倒水太满就容易洒出来，你得考虑“任务忙闲不均、能力有大有小”的情况。
3、岗位任务合并时要实际一点，参照市场人才情况，能力互相的可迁移性，这世界上没有超人。
4、岗位的各种任务之间应有主次之分，核心要解决什么，对应的核心能力就得重点考察。那些需要花费时间多、成长性不高的任务（属于“任务明确且饱满的岗位”），尽量别雇专人干了，可以尝试分摊到各岗位身上。“hey，这个任务咱们大家逃不掉，兄弟们就一人担一点儿吧！”
