目标制定、标准衡量和人心管理 / Goal Planning, Performance Assessment, and Team Cohesion

在做OKR或者目标的制定中，不管是季度还是年度的，本意应是好的，毕竟从企业的角度来看，能让一线的员工也能感知到公司级别的战略或者目标是一件很好的事情。但是在关于目标制定、迭代和最终结果评定以及绩效发放的过程中，有可能会变形。这个问题我思考过几次，现在我稍微有一些想法了。

我想探讨的是个人的差异带来的向心力不足的问题，也就是减少团队内部猜忌所带来的的内耗。

在一个团队内，通常是存在不同级别的人员的，有初级工程师也会有高级工程，甚至是资深工程师。在这种情况下，每个级别能达成的目标必然是不同的，因为能力、薪资待遇水平的差异，注定了高级别的人员理应产出更多的成果（先不论这些成果的价值），因此在制定目标的时候，最合理的必然是有差异化的难度水平，因为对于低级别的工程师来说，要起完成高级别工程师才能完成的目标，是有些强人所难了，也对他们不公平，因此对于每个级别，甚至是每个人都能有一个专门的目标，会最大化团队的能力。

但是这也带来一定的问题：

1. 这就注定了，个人的目标在团队或公司级别的高纬度的目标内的体现有可能是一句话或者压根没体现。
2. 团队内除了Leader以外，可能某人对于其他人的目标情况和难易程度（在制定阶段）可能完全不care
3. Leader有可能没有办法面面俱到地帮助每个人审核和把控其目标是否合理，可能只是做到了目标和上级的目标是否一致

上面这些问题会分别带来一些不同的问题：

1. 某些幸运儿会拿到上一层级目标的完整词条，也就是上一层别的目标会落到某个或某几个员工身上，这会让这些人会有更大的压力和动力，相应的会更有价值感；而在上一层级目标中没有体现的人，会走向相反的方向，会更加没有价值感，驱动力可能会更加弱
2. 这个在制定目标初期并不会有任何问题，问题可能发生在过程或者结束的时候。因为在每个人的视角来看，可能会觉得别人的目标比自己轻松太多了（不论是主观还是客观），目标和职级不匹配，心生芥蒂，这是危险的种子
3. 这我喜欢称之为向上管理的一个例子。其实很多时候完成上级的目标没有问题，问题是你通过什么手段和方式来完成。如果你希望你的团队战斗力很强，那么最好不要草率的对待每个人的目标，尤其这个目标的持续时间比较长的情况下。最好能因人制宜，将目标和个人的意愿或规划做一定程度的匹配，当然这个会消耗管理者较多的时间

我觉得这些问题大多能在前置环节解决，有些在过程中也能调整解决，关键在于能否识别。这里就需要看团队或者公司的文化和氛围是否有对应的机制去接收员工的反馈。不是每个人都会主动对团队或公司的发展出谋划策的，但是要有这样的机制能接收员工的反馈，这样才能知道团队是否出了问题，这有助于某些坏事情在滋生阶段就介入处理的。

在目标制定阶段，在确定初版之后，我觉得有一个环节可以有蛮大收益的，让每个人对别人的目标做评价，这样他们可以认真去看别人的目标，这样可以在前置环节就让大家互相知道对方的目标，并且如果可以的话，可以问某个人如果xxx休假了，你可否代替她完成她的目标？一旦这个说法出来之后，这个人对于别人的目标的心态就会有些许变化了，可能就会开始带入自己是主人公的角色去思考，这样有助于大家对于目标制定达成共识。这点其实和敏捷迭代里的点数评估类似，比如某个任务，A需要2D完成，但是B只需要1D完成，这就是能力差异以及目标执行人的可替换性，其实不仅在迭代里可以这样，在目标的制定也是如此，我们不希望某个目标只能由某个人完成，我们其实应该至少保证有2个人以上可以完成某个目标，理想情况下当然是团队内每个人都可以完成任意的目标，但是出于对专业化分工的带来效率最大化的追求，通常是不会这样的，但至少我们可以保证有至少2人能完成某个目标。

在目标的制定和规划上，管理人员不能只考虑自己的目标是否能完成，应该充分考虑将团队成员充分发挥起来，整个团队一起完成目标。参与感是一个很重要的东西。这里我想要举个有趣的例子来佐证这个观点：

我们在做Scrum迭代的时候，正常是会有一个固定的Scrum master，负责组织站会、规划回顾会之类的敏捷会议。但是我们在实践过程中发现，与其设定一个固定的Scrum Master，不如让人人皆为Scrum Master，也就是轮流制，简单的实践方式是每周（假设迭代冲刺周期是1week）由不同的团队成员来担任Scrum Master。我发现这种方式带来的好处是远远大于前值的，主要集中在这么几点：

1. 每个人都能有机会成长，学会如何转从头到尾主持处理一次完成的敏捷迭代冲刺
2. 大家都会以主人公的意识来参与，当轮到别人做Scrum Master的时候你不会在旁边划水或者不怎么爱应答其发出的疑问，因为你知道当Scrum Master的感觉，也知道你提问的时候没人回应的感觉，你也希望下次你做Scrum Master的时候大家能配合你
3. 对于团队目标的追踪，你会开始上心，哪怕轮到你一次需要好几周，但是因为你已经开始注意目标的跟进了，你已经锚定了，因此你很容易就会将对应的信息听进去并且评估团队的情况
4. 团队内有管理能力的人会慢慢浮出水面，大家都得到了机会，作为管理者你可以很容易的观测到每个人在管理者的角度做事时是怎样的姿态，能帮助管理者更加容易的发现每个人的能力和定位，以及在遇到问题时候要怎样针对性的应对

我并不是倡导一定要走轮流Scrum Master的方式，我只是觉得这种方式值得一试。这个例子说明是想说明如果你希望团队成员都动起来，首先需要让每个人尽可能找到主人翁的意识，这有挺多方法能达到的，我这里仅仅举了个例子。

管理中最难的且最重要的永远是人，其次才是产品和利润（来自创业维艰），我觉得前者偏向于因，后两者偏向于果。因此我觉得好的管理是能人尽其才 🫡