如何才能做好一个基层管理者？这个问题想了很久，想写一篇博客，但是一直难以下笔。第一，怕得罪人。第二，确实没有足够的实践经验。

思考再三，最后还是决定先写一点，看看大家的反响吧。为了不至于被曾经和现在的leader误会，开写之前都告知这一想法，以免被当成背后小人，呵呵。

我们先从一个所谓团队管理方面的游戏开始吧：

游戏人数（10人或以上），分为两组完成。

游戏时间：5分钟。

胜负判定：需要达到目的，且游戏中耗费的纸条越少得分越高。

第一组游戏：

道具：写着一串数字（15-20个不同的数字）的纸条，每张上的数字串不完全相同，但是所有纸条上有一个相同的数字。只有一张字条上写着 ：任务目的是找出所有纸条中的相同数字。

规则：游戏开始前，所有人都不知道道具的任何信息也不知道游戏目的。所有人都不能说话，只能通过纸条传递信息。任何人可以成为信息的发送者和接受者，可以发消息给所有人。

第二组游戏：

（更换另一拨不知道游戏信息的人参加）

道具：道具和第一组游戏相同。

角色：P角色一名，L角色一名，其余人角色都是D。

规则：P角色先得到写有游戏目的的纸条，但是他只能和L角色通信；L角色可以和所有人通信；D角色不可以和另外的D角色通信，只能和L角色通信。

游戏的设计基本是比较客观的。在整体看到这个游戏设计后，我想大家一定可以猜想到游戏的结果。

第一组游戏结果：

在毫无规则的信息传递过程中，有价值的信息（游戏目的）很可能被淹没。因此，在5分钟内，每个人基本上都忙着写纸条，看纸条。

拿到含有目的信息的人，很可能盲目的认为所有人都知道目的，因此他可能只是把自己的数字试图告诉另外的人。其余的人的信息只有一串数字，因此他们也只可能互相传递毫无价值的信息或者自己的数字给对方。

在游戏规则设定的信息不公开的情况下，这个游戏一定是失败的。

第二组游戏结果：

因为规则引入了层次结构，最上层的P角色知道游戏的目的，他可以告诉他的唯一联系人L，告诉L游戏目的是什么，让他把这个消息带给所有人。

第一种情况：P会先把目的告知L；L会先让D们先知道目的。然后，D让所有人把信息统一，D很容易统计出来。这种模式一定可以得出结果，但是耗费的信息量很多。并且计算任务都在L处，他会是任务失败和成功的关键，同时也是瓶颈。

第二种情况：P把目的告知L；L制定达到这一目的的方案：L把自己和P的字条中相同的数字算出来，连同目的告诉一个D，并让他以同样的方式，依次传递给所有的D，最后一个得到信息的D很容易得到共同的数字，任务完成。

第三种情况：如果允许在每张纸条上续写信息的话，那么按照第二种情况，应该只需要一张纸条就可以达到目的。

游戏的目的是什么？

我记得培训师当时说：这个实验验证了两个观点。第一，第二组游戏中的管理结构（三层结构）是最佳的组织团队架构；第二，任务下达后，基层管理者制定可执行方案，团队成员不需要过多的相互沟通，严格按照方案执行，这样的合作是最高效的。

那么，你觉得呢？

我想起来了罗振宇在《罗辑思维》中说的一个故事：

如何证明蜘蛛的视觉是在腿上？

拿一只蜘蛛，放到桌子上，静止状态下，拍一下桌子，蜘蛛马上跑走了。第二次，把这只蜘蛛拿来，拔去它几条腿，拍一下桌子，蜘蛛不动了。

因此得出结论，蜘蛛的视觉器官长在腿上。

是的，我想说，开篇说的那个管理学实验的结论纯粹是扯淡。当然，在管理学理论里，有学者认为三层结构已经是最扁平最高效的管理结构。某种程度上我也认同，这里讨论的不是整体结构，而是基层管理。

我以前的公司推行敏捷，也曾经参与敏捷推广的整个过程。我先说明我个人的拙见：敏捷绝对不是照搬一套所谓的管理实践和技术实践。但是对于团队建设，敏捷的思路是对的：

（1）消除组织阶层，扁平化结构；

（2）信息公开；

（3）快速反馈。

说到这里，那么怎么才能做好基层管理者呢？

首先，必须明确基层管理者是为团队所有人服务的。因此，他并不是严格意义上的纯粹管理角色，更多的是服务的角色。

第二，做好和上层的沟通。PO（Project Owner）指定任务后，需要和团队完全公开任务的信息，并且引导大家共同分析和制定达到这一目的的计划。如果任务不合理，需要作为协调人和PO进行沟通，比如申请必要的资源、延长交付日期等信息。当然处理来自客户的压力时，需要另当别论，下篇再说。

第三，主动承担来自PO的压力，减少PO和项目上对团队过分的压力，保持团队健康的开发氛围。同时，当团队需要去Challenge别的团队或者处理来自别的团队的Challenge的时候，团队管理者应该客观地处理，合理的沟通，减少直接Challenge到具体团队成员。好的leader一定是在践行：有责任我先抗，有功劳大家一起享。

第四，作为基础管理者需要有一定的技术积累，如果团队内没有Tech leader，他必须能够承担Tech leader的责任。例如，帮助团队克服技术难点；制定研发的各项标准，但不要过分涉及微小的细节问题，要鼓励并信任团队成员可以做到最好。

第五，管理的目的不是让所有人都满意，必要时需要果断剔除团队内的“不良分子”（残忍但重要）。

第六，基层管理上一个非常大的忌讳是：不患贫但患不均。如果在团队内，由于私人关系或者某种原因导致利益分配严重和贡献失衡，那么这个团队一定会逐渐瓦解。当然，平均主义就像XX主义一样，在道德和理论上都已经破产了，我说的基础必须是建立类似于资本世界规则的团队公认的内部规则。

第一篇简单列出了我认为做好一个基层技术管理注意的几点（再次说明，仅仅是我认为，可能不对哦，所以欢迎交流）。但是深入分析如何做好管理还需要考虑很多。这一篇中，我主要从另一个侧面分析基层管理：利益分配。

我没有学过管理学，相关的书也读的很少。客观的说，虽然我热爱诗歌和艺术，但我曾经是一个对于非理工学科持鄙视态度的理工男。

在所有的非理工学科中，我最欣赏和感兴趣的就是心理学，准确的说是积极心理学。

我认为，好的基层管理就是把积极心理学的方法和理念应用到团队建设上，当然，我并没有系统的学习过积极心理学，对其了解基本上来自哈佛的公开课《幸福课》。不过我觉得从积极心理学的角度，管理团队重点在于：怎么以开放和积极的态度管理一个团队。

深入讨论之前，我们必须明确：任何团队之所以称之为团队，是因为他们的利益趋同性。

首先，我们有必要先说明团队内的组成，分析角度是贡献和获取的比例。

真实世界的任何团队，都会存在三种划分：

（1）贡献 > 获取；

（2）贡献 ≈（约等于） 获取；

（3）贡献 < 获取。

套在我们的基层软件开发团队上，就是你的付出和你的工资和技术成长是否合理。在我们讨论的基层软件开发团队内部，这三种人的比例和变化趋势就是这个团队的健康度。

完全公平的利益团队是不存在的，就如同上一篇最后的一条中说的那样，平均主义理论在现实世界里根本不成立。那么我们怎么办呢？

我们先来说说第一类同学，也就是贡献比较大的同学。必然，这一类人心理会不舒服，不平衡。所有人都会表示理解，甚至团队内贡献小于获取的这类人都会表示同情。那么，我们要怎么平衡他们呢？

最直接的办法是给他理所应当的收益。可是你要知道，开发团队内付出多少，根本就不可能精确衡量的。我们只能给出一个相对客观的分配。而且，这种满意度完全是个人的感觉，要知道本性上人的欲望是无穷的。

换句话说，只要团队内一个人认为自己的贡献大于收益，他就可以要求增加配比，那么他会慢慢变成第三类同学。但是，用一句大牛的话说：一个公司的竞争力完全取决于这个公司的大牛比例。如何留着这类技术强人，并且在适度的范围内让他满意是至关重要的。

关于这一类人，我们先讨论到这里，先让我们这位同学委屈一下，过一会儿我们给他一个合理的解决方案。

第二类人，贡献约等于获取的人，其实团队内如何处理好这类人是也是维系团队的关键。简单来说，基层管理者要做的就是如何引导这其中有潜力的人成为第一类人，并且给他一个相对满意的激励，让他继续努力为了团队贡献更大的能量。如果他安于现状，那么适当的给予鼓励和鞭策。如果他消极怠工，有发展为第三类同学的趋势，那么我们的管理者就有必要拿起你的“大棒”了。

第三类人，这类人的处理需要管理者更多的软技巧。单纯减少他的收益，肯定解决不了问题。你要知道降工资可是件要命的事，在心理学上即反向激励。很可能的结果就是这类人越来越怠工，贡献越来越小，或者和管理者和公司决裂等等。显然，这类人有他们特殊的贡献，或者曾经也是第一类同学。他们的处理和第一类同学一样很难用简单的方式处理。

那么怎么办呢？

我们想象一下，在一个会议室里：第一类同学坐在角落里斜着眼看着第三类同学；第二类同学泰然自若的坐着看热闹；第三类同学趾高气昂的翘着二郎腿谁也不理谁。

这时候，如果你是一个管理者，要进去面对他们，你该怎么办？

在我们再次讨论前，需要分析一下个人对于公司的价值以及公司为个人付出的成本：

公司的运营是有大量的隐形成本的，而且对于产品是软件或者科技附加值的公司是一种非常复杂的核算过程。

作为后工业革命的主要力量，IT产业的成本核算完全和工业时代完全不同，工业时代仅靠生产多少成品，分析利润转化率，统计厂房、工资等成本，基本的加减法就可以计算。

现在成功的公司可能只需要10个人，几个月，就可以开发一款软件，或者定义一种新的有价值，且难被复制的商业模式，那么你可以把公司以相对个人而言的天文数字卖出，或者吸引VC进行商业运作。

因此，后工业时代，高技术和含有高信息量的人的价值是无法估量的。不过，并不是所有的IT行业从业者都具有这样的核心竞争力。尤其在中国，IT行业的基层员工更多的是被看做工业时代的生产线工人。

在公司角度，公司高层的技术人员，决定公司产品核心价值的人，无疑属于高核心价值和高附加值的人才，他们的待遇也不仅仅是工资还有很多更具诱惑的激励。但是在我们今天讨论的基层开发团队，大多数的是从事具体研发的“屌丝”们。对于他们的工资衡定更多的是依靠HR部门基于公司的各种信息划分等级，在等级内根据部门反馈的情况进行调节。

同时，个人的成本更多的是参考平均成本来定价的。公司的除去工资以外的所有成本，包括水电、桌椅板凳、加班费、各种福利等等全部都是平均到每个人头上的。

分析到这里，你也许可以大概知道我的意思：在公司基层的小范围内，你的成本基本是默认平等的，而你的价值则取决于你的部门管理者对你的技能认知和贡献认知。在创业小公司也许有差别，但在大公司则基本上是这样的。

在了解了大公司的薪资衡定之后，我们继续讨论团队上面遇到的问题。
团队内部，如果没有特别的情况，可调整的范围完全掌握在基层管理者手里，薪资虽然决定不了团队的凝聚力，可是如果处理不好，绝对会对团队造成致命的打击。

其实，员工关心的不只是数字本身，他们关心的更多是自己的内心感受。就如同央视去满大街问人家：你幸福吗？从事基层软件开发的同学他们的内心感受关乎他们能否长期在一个公司工作，以及能否投入多少热情的关键。当然，任何公司都是不允许员工谈论自己的待遇的。但是实际情况是，如同在真实世界里一样，越是遵守规则的同学越是容易被欺负，某些敢于打破常规的人总是想方设法获取别人的信息，以给自己谋求更多的利益。

俗话说：不患贫，但患不均。这个均可不单单是平均的意思。这个“不均”是人内心的心理感受。

其实一个团队内部，个人的能力大家都会有一个客观的认识。如果能力相当的人，由于某种非正常原因，待遇差别比较大，不仅仅是影响着两个人的工作心态，而是关乎整个团队对于领导者和公司的信任感。

当然，在任何的公司，老板最希望的员工都是，老老实实工作，给多少都很知足的员工。这种人是有的，但是如果即使把这种人放在一个分配不公平的团队内部，他也会慢慢的改变，变得不安分。因为他能感知，自己的收入并不是和辛勤劳动直接相关的。

那么，我们该怎么办呢？

其实，我的想法也很简单，也许也很单纯。有两类员工，一类只在乎钱，一类在薪资基本合理的情况下更在乎自己的个人成长。

我的第一个想法：只关乎钱的员工，是必须有一定限制的，因为他们会想尽各种办法给自己争取利益。如果不做限制，那么他们一定会成为第三类员工。

关心成长的员工，即使现在的薪资不太满意，或者不公平，但是只要他们可以不断从团队汲取到提升机会，他也会在一定的时间内安分的工作下去。但是不公平的状态，只要一天不解决，这个人对团队和管理者的信任感也不会太强。

是的，技术培养也是一个留住人才的关键。但是并不是培训那么简单。任何人都有一个认识：一个挫的技术培训师和一个好技术培训师带来的改变是天壤之别。并且一个人在公司的成长，培训所起的作用非常的有限。

真正关心成长的人，他会有非常高的自我学习动力，因此他们关心的也许不是培训本身，而且他们获取的知识也不是来自于培训：知识来源于一颗求知欲强烈的心。

如果一个团队内有几个技术比较强的人，而且他正好是一个愿意分享的人，那么这种人的存在，会直接决定关心自身成长的人的决定。

我的第二个想法：团队内技术比较强，且愿意分享的人，这个人是公司必须要留下的。因为他的留下，会影响一部分安分的更关心技术成长的员工，这是一个多赢的局面。

对于某些给团队和项目做出特殊贡献的员工，应该适当给予激励。某些比较自私的团队管理者，认为团队所有的重大成果，第一贡献者都是管理者本身，甚至会做出与员工争利的情况，如果出现这种情况，这个管理者马上会出现对团队失控的局面。

我的第三个想法：对于确实为团队或者项目做出较大的贡献，但是在无法打破工资结构的基础上，可以给予其一定的Title，或者申请一定的特殊贡献奖励。这种正向的激励对于团队的长期发展是有益的。

说道Title和级别，这个一般在团队都是公开的，如果给予一个能力根本就不符的人更高的Title，对于团队的伤害可能比打破薪资结构更加可怕。很多团队，对于这一点一般都是管理者一个人拍脑门决定的，根本不会公开。

我的第四个想法：对于Title的评定和级别升级，我的想法应该是公开竞聘。在团队内部把自己的贡献和自己的能力公开竞聘。一般情况下，可以拿出代码质量，代码量，解决技术难点的量，都是客观的数据来决定。

此外，对于第三类员工其实还有另一个情况：他的技术能力和现有工作的匹配度不大，管理者也没有对其进行适当的调整。对于这一点，员工个人的意愿也是决定这种情况解决的关键。从另一个方面，基层管理者，应该对于团队内部各个成员的技术能力有全面的了解，尊重个人对于自身成长的意愿。在此基础上，进行适当的调整。如果管理者仅仅依据个人判断，甚至不去了解，那么这个员工的负面心理一定会持续增强。

我的第五个想法：周期性的让员工就自身成长有表达的机会，团队根据实际情况为其提供适当的发展空间和机会。