该文章的起源是某好友在微信中问了一个问题。而这个问题在整个圈子里面最终也没有一个让人信服的解释出来。当时我给出了一个答案，好友表示不能接受，而后群中引发了一定的思考与讨论，在此我简单的记录一下讨论的结果和思路，同时会给我出改良后的分配建议。
这个问题是这样子的：
一个项目组5个人，项目完成之后，老板给了2个苹果。在这种情况下，项目经理该如何分配？
备注：
1. 苹果价值不菲
2. 苹果不可分割
看似很简单的问题吧？但当我深入对这个问题进行思考，以及看了群中的各种建议和想法后，我才发现我一开始将这个问题简单了。
我一开始给出的答案是这样子：
根据项目组中的人员性格，将2个苹果给予性格最强势的两个人，后续再以其他方式弥补团队其他人员。
我之所以给出这个建议的原因是，项目组中，保持人员稳定和军心稳定是最重要的，而性格最强势的人员比较容易成为最不稳定的因素，所以在无伤大雅的情况下，优先满足这些人，而后再满足其他人员，从而保证团队的稳定，以及为了下一次的项目做准备。
（这个分配方法有问题，后续再详谈）
而好友的作法是这样子：
将其中一个苹果给予本次项目贡献最大的，而另一个苹果，从过去的失败的项目（或者说没有奖励的项目）中，选出一个贡献最大的人，将另一个苹果给他。
这个分配方法的出发点很明确——“对于员工来说，没有失败的项目；失败都是项目经理的，你们是最棒的。”
这个作法的出发点看起来很明确，并且也是有很大的正向意义，但这个分配方法的缺点也是有的。这个问题也请等到后续分析完成后一起来说。
到群里面后，不少朋友也给出了自己的想法，总结了一下有这么几种：
- 苹果扎成汁，每人来一口；
- 如果不能全部覆盖，就宁愿不要；
- 在现有基础之上以一个比例来分配，比如4:3:2:1或者6:2:1:1
- 私下分，不要公开，想怎么分都行。
分别说一下每种想法我为什么都不赞同。
- 都说了不能榨汁了，你们还要搞平均主要，就不怕大锅饭吃死人么？在说，如果这个苹果是一个指标，一个编制，还怎么平均？
- 不要？这个是企业啊，你不要兄弟们还要呢。凭啥你为难兄弟们就被自愿放弃啊，这是PM的磨难，又不是小兄弟们的。你这么做真的合适么？而且在企业中，一旦这种行为发生，9成9会被定位“刺头”，以后项目还怎么干？
- 各种比例看似OK，那么这就会牵扯出另一个问题，你的绩效怎么算的？如果是板砖还是很简单的，1000块就是比999块要强，写代码或者其他脑力劳动，你如何界定两个实力相当的人的排名？
- 这是我见过最差的方案了。所有的流言蜚语或者无闹猜测，都是在信息不公开的情况下产生，大家恨不得都把自己扒光了给别人看的时候，你去搞这种神秘，完全是留人口舌，自己给自己挖坑。
所以，这个问题真的没有那么简单。
我们来看一下这个问题所涉及到的项目管理的哪些方面？
- 人员绩效。这个不用说了，是所有的基础的基础；
- 团队建设。绩效分配（简称分赃）是团队建设中非常重要而且非常难的一个过程，做得不好下次你的项目大家分分钟撂挑子你信不信！
- 团队激励。这个可以看作是2的背后的原因，但因为太重要所以单独拆开看一下。
- 项目经理个人能力。这个就不说了，最直接的因素。
下面来一个个讨论。
人员绩效
简单的四个字，不知道难倒了多少英雄好汉。脑力劳动，尤其是研发人员，绩效怎么算，这向来没有标准答案。从一开始的KPI到现在理性的OKR到被一些HR奉为银弹的360度考核，目的都是为了解决人员绩效考核问题，但真的解决了么？
好像没有。KPI不说了，早就被喷的体无完肤。OKR虽然在企业管理方面很好，但是归根到底也只是一个定性的指标，无法以无二义性的数字来表示。360度就更不说了，虽然对员工的考核是全方面，但耗时太长而且参考的指标太多，做一次都能伤筋动骨，你想要时不时做一个来反应员工的表现？HR不累死员工也累死了。
所以看起来这个进入了一个死胡同。
团队建设
又是一个看起来简单，做起来才发现不是那么回事儿的四个字。
团队建设包括从一开始人员选择、配合到后期的绩效考核等，原本这些都是有迹可循。但，有两个现实的问题需要解决：
- 团队成员很大程度上不是你决定的
- 参见“人员绩效”
说白了，人不是你定的，绩效确定也是一个很难的事情。
也许你能很好的让团队面对冲突并解决冲突，最终达成为了项目目标而努力奋斗的局面，但是你能保证你在分赃这种事情上面，团队也能和面对冲突那样，向着同一目标前进么？
再理论化一点，本例中的项目奖励其实是一个“零和游戏”，里面是一定要有赢家和输家，永远不可避免。面对这种情况，你如何能够化对抗为合作？
很可惜，你不能。
团队激励
团队激励是什么？团队激励是需要放到一个大环境中看，而不是放到当前一个项目中去看的名词。
如果从一个单纯的项目来看，项目完成了，再给予一些项目奖励，这明显就是增加了项目成本，是不可取的。所以这个项目奖励一定要从项目集或者项目组合的角度去看才行。
既然从这个大范围去看，那么项目奖励的目的就很明确了，那就是给在项目集或者项目组和中其他人员传递一个信息——跟着我干，有肉吃。
既然是这样子，那么项目经理对这种激励的选择和分配，该注意的除了公平之外，还有就是公开。只有这样子才能更好的达到这个预期的目标。
同时，项目经理为了更好的传达这种激励的用意，还需要注意以下几点：
- 实时性。对整个团队（大团队，并非项目团队）的刺激，一定要及时。最好能项目完成后立即进行奖励，这时大家对该项目的过程还历历在目，在大家的心中还是一个活生生的项目。此时给予奖励，很容易将大家的情绪激发起来，并形成一个传播效应，从而更好的激励。试想一个项目过去二年半了，你的奖励到了，员工对项目的记忆都成了简历上的谈资，这种时候的激励效果能如何，有待考察；
- 不能100％覆盖。对于项目过程中的奖励，一定要广泛覆盖，只有这样子才能让大家更好的形成“团队”的概念，从而更好的将项目完成。但，一旦项目完成，这种激励就已经不再必要了，此时就是应该以一个较大幅度的对个别人进行奖励；
项目经理个人能力
这个不谈了，所有的问题都是人的问题，项目经理如何能搞定人以及搞定自己，就成为了非常重要的事情。
OK，现在我们根据上面的四点，我们有了一个基本的信息可以做一些推理和想像：
- 金额大
- 不能100％覆盖
- 时效性很重要
- 需要根据个人表现来进行分配
好了，现在回头看一下我的作法的问题：
- 没有根据绩效进行分配，而是过分考虑团队的稳定，这种作法对真正作出贡献的团队成员很不公平，容易丧失人心；
而好友的作法问题在于：
- 没有时效性。对过去“失败”的项目的骨干进行奖励，是一个非常有人情味的作法，但对于远久以前的项目，到底有多少人还记得，还能达到项目奖励自身的目的？这个是有疑问的。
- 从1中又会引发另一个可能的问题，由于是远久以前的项目，对于没有亲身参与那段工作的人，对那些时间内的事情不了解时，其实会形成一定的“暗箱操作”的感觉。
好了，说到这里，最关键的部份来了，如果现在让我去做，我会怎么做？
我的作法有点开上帝视角了，有些点针对当前项目是无法完成的（其实也可以，但效果会较差且难度较大），所以这个作法恐怕更多的是针对未来的项目。针对当前项目也可以，但效果不会比新项目好。
- 项目初期就告知项目奖励金额会较大，且不是每个人都会有，并将项目奖励的意义明确告知，从一开始就做到透明；
- KPI不是不能用，而是不能只用KPI。项目中每个人做的事情是已知的，针对已知的工作完成情况进行纪录（一定要是可以量化的纪录，比如完成时间，千行代码的Bug率等），并作出初步的KPI分数；
- 权重的分配。杠杆说了KPI要用，但KPI权重不能是100％，至多到60％，其余的可以引入“工作态度”、“出勤率”、“内部互评”等方式填充；
- 最终项目成员的得分是根据不同模块的不同权重进行计算得出，是一个分数，保证可以排名；
- 最重要的一环。根据排名，选出第N名和第N+1名员工（N是奖励份数），若两个人最终得分差距很小（5％以内），则牺牲性格较弱的人，将第N份奖励给与性格较强的人并对另一人进行安抚，否则第N份奖励给予第N名即可；
- 若奖品不同，则根据奖品价值从高到低排序，根据排名正序发放即可。
多说一句，为何我会将性格纳入到考虑范围内。
还是那句，团队稳定最重要。当两个人贡献在伯仲之间的时候，性格较强的人更容易成为不稳定因素，为了使整个团队的稳定系数达到最高，此时必需要牺牲另一个性格较弱的人，否则很容易让性格较强的人产生更多想法，从而影响团队稳定，甚至团队其他成员的稳定。
虽然有点腹黑，但是针对项目经理自身而言，这种做法也是迫不得已，毕竟项目经理的绩效要通过员工表现，从大局来看，这也许是最佳的选择。
注意：牺牲性格弱，只是暂时，后续一定要有其他的方式弥补，并且这点一定要在开始就告知，并且一定要实现，否则下次项目经理真的就没法干了。
