软件设计：表达组织中的上下级关系

正在策划一个产品，其中要用到企业中人员的上下级关系。

上下级关系，直觉上只是个简单的树状结构，如果不深入思考，容易将之简单化，其实，这里面还是有很多麻烦事的。例如，有些企业，某些人的上级不止一个，属于多领导，虽然有些口头上的分工，但分工并没有非常明确，还有的时候，一个人可能会有兼职，如某车间主任兼职工会主席，他就属于两个不同的管理条线下，还有些企业，对排名，特别是领导的排名很重视，可在兼职的情况下，在不同的岗位下，排名是不一样的，等等。

怎么表达企业里面员工上下级的关系，兄弟们主要分成了两大阵营，相互之间都说得有道理。

方案A：就直接用人表达上下级关系，至于这个人的岗位是什么，只当成一个不重要的辅助信息。这样做的优点，一，可以清楚地表达出谁是谁的领导，谁领导谁，一目了然；二，符合我们在工作中的认知，我知道我的领导是谁，至于他的岗位是什么，我并不太关心；三，如果用岗位表达上下级，对于那种事业部的组织架构，可能几乎需要对每个员工设置一个岗位。

方案B：用岗位来表达上下级的关系，岗位A的上级是B岗位，如果某个员工属于A岗位，那么他的上级就是B岗位的员工，谁在B岗位，谁就是他的领导，如果B岗位有多人，意味着，他的上级有多个。这样做的优点，一，如果有多个员工属于同一岗位，在实施的时候就不需要为每个人都设置他的上级；二，如果某员工离职（特别是管理者），对组织架构没有任何影响，只要将个别员工设成这个岗位就行了。

争论了很久，最后方案B获胜，产品经理决定采用。因为方案B方又抛出了两项优势，一，用岗位表示上下级更符合HR的思维，在实施项目的时候，跟HR讨论更容易，也就更顺畅；二，透过现象看本质，现在 会并不是养家臣的年代，人跟人之间的上下级关系，并不是人的关系，而是岗位的关系，你是我的领导，因为你在这个岗位，软件要表达现实业务才能提高灵活性。

最后，做个总结吧。为了让软件具有更好的可扩展行、可维护性、灵活性，要尽量表达出业务的本质，因为业务的本质变化的概率小，而表象变化的可能性大，也更可能遭遇难以处理的异常情况。

上例中，岗位的上下级关系是本质，人跟人的上下级关系其实是表象。企业中上下级的岗位关系是相对固定的，只要没有组织架构的变更，一般不会变化，可人跟人的上下级关系变化的可能性大得多（如离职、升职、调动等）。

如果软件表达的不是业务的本质，而是表象，那么很有可能在使用中会遇到某些你现在无法预见的、无法表达的特殊情况。例如，假设某人兼职两个领导岗位，车间主任（上级是制造总监）与工会主席（上级是行政总监），车间组长的上级是车间主任，所属高管是制造总监，而工会会计的上级是工会主席，所属高管是行政总监，这时候，方案A是无法表达这种关系的。方案B很容易表达出这种关系：

如果采用方案A，如图，李会计与钱总，孙组长与赵总的关系无法表达出来。