|
|
# 第188讲 | 张嵩：从心理学角度看待小中型团队的管理
|
|
|
|
|
|
你好，我是张嵩，作为一个架构师出身的管理者，刚被“赶鸭子上架”的时候，我更喜欢别人称呼我为架构师而非总监/CTO，原因是技术管理，特别中型技术团队的管理方法需要一段时间去摸索与分析，并非能一蹴而就。而当时的我，充其量只能算是在做技术管理的架构师，而非技术管理者。之后，我也将一些在架构领域养成的思维面模式，如习惯于权衡得失，应用到了管理中，慢慢形成了自己的管理风格。
|
|
|
|
|
|
《未来简史》中说过，“我们以为自己懂得很多，原因在于我们把存在于他人大脑中的知识看成自己的了”，因而我希望能尽量地享受群体思维带来的知识，而非无知。我从大学时代开始就接触心理学的基础理论，如今，我会更多地将它运用于生活的方方面面，包括职场，例如技术管理。在本专栏之前的文章中，熟稔于管理之道的技术管理者们已经将各种管理经验及实践案例讲述得很详尽了，我自觉已无能力更上一层楼，因此本文将以另外一个角度，即心理学来切入技术管理，抛砖引玉。
|
|
|
|
|
|
其实，这也是我转型技术管理者之后的常用的一个分析方法，俗话说“当局者迷，旁观者清”，有时候跳出管理的维度，站在一个非本领域的角度，如心理学角度来看待问题，会带来许多思考与领悟。另外，在本文中你可能会发现很多问题在日常中自己都碰到过，甚至解决方式都异曲同工，毕竟虽然思考角度不同，但殊途同归，万变不离其宗嘛。
|
|
|
|
|
|
技术管理的方法论关联性很高，很难做到降维，因此接下来的内容直接以心理学理论来推导，而不以管理方法作为主线来扩展。
|
|
|
|
|
|
## 一、自我服务归因
|
|
|
|
|
|
根据自我服务归因理论，人都会习惯性地把好的结果归因于自己，把坏的结果归因于其它。例如面试中，你拿到了offer，可能会认为原因是自己基础扎实、思维快，如果与offer失之交臂，你可能觉得是因为面试官问的问题太偏/问的东西在实战中用不到等。
|
|
|
|
|
|
与此类似，技术管理人员容易把效能低、进度推进缓慢等归因于团队成员缺乏能力或者不够卖力等；团队成员会把获得奖励(例如加薪)看作是公平的，而对进度缓慢的看法会觉得是同事原因、任务目标不可及等。
|
|
|
|
|
|
这些现象在心理学中的术语叫自我服务偏差。团队成员容易高估自己对群体成功的贡献，而低估对失败应该负的责任。因此成功时，大部分成员会认为自己做出了很大的贡献，如果没有得到薪酬提升或奖励，就极有可能会觉得不公平，引发嫉妒与不和；而失败时，则容易责备他人，并且影响团队的氛围。
|
|
|
|
|
|
因此在实际工作中，作为一个技术管理人员，在出现任何问题时，首先要思考：我的行为导致这问题出现的占比有多少？(在此建议大家可以反思下最近一次问题。) 而非直接归因于团队成员或者情境，否则当问题主因并不在团队成员时，很容易造成团队成员的心理落差。
|
|
|
|
|
|
不过，在我看来，团队成员容易产生的自我服务偏差这点，其实既有好处也有坏处，而利弊占比取决于技术管理者的管理方式。原因在于，团队氛围的好坏很大一部分取决于团队成员对自身的评价和公司对他的评价。自我服务偏差会导致成员对自身的评价较高，如果从正常的管理角度而言，大家都更倾向加以赞赏与奖励，甚至为了整个团队的稳定，会让团队成员“吃大锅饭”，让团队的士气尽量稳住。但是这种做法却容易对其他的自认为表现更好的团队成员产生伤害，于是逐步地影响到整个团队的氛围，久而久之轻则带气工作，工作效率降低，重则优汰劣胜，最好的一部分人逐步离职，整个团队分崩离析。那如何才能够避免这情况的发生呢？
|
|
|
|
|
|
我们先从个人角度来分析，之所以出现服务偏差，一种解释是这是我们加工和记忆个人信息的副产品。我们常常会不自觉的将自己与他人做比较，去注意、评价、回忆自身与他人的行为，而这增加了出错的机会(Chambers & Windschitl)，因为我们更容易回想起自己做了什么而不记得自己没做过什么(Sicoly)。对于这种知觉错误，部分解释是：我们渴望评定自己的能力(Dunning)、我们寻求自我证实(Swann)、希望提升自我形象(Sedikides)。堵不如疏，知道了偏差的原因，我们就可以有的放矢，我建议做四件事情：
|
|
|
|
|
|
* 1.即时反馈(Lichtenstein & Fischhoff)，通过在事情进展过程中的即时反馈，我们可以降低团队成员的过度自信，因为清晰的反馈信息有助于矫正偏差。
|
|
|
* 2.分解任务(Kruger & Evans)，对大任务的规划总是更容易陷入规划误区，(Zauberman & Lynch)，把大任务拆解成小任务，有助于减少团队成员的服务偏差所导致的问题。
|
|
|
* 3.让团队成员养成反向思考的习惯，从你认为错误的观点中寻求能证明它的方面。因为按照验证性偏差的观点，一旦你认为一个观点可能正确，你会找出各种理由来证明它，让它看起来更加正确。
|
|
|
* 4.定期一对一沟通，肯定团队成员的能力，同时在保证不伤及自尊心的前提下指出成员的不足之处，要注意对事而非对个人。并针对个人的形象提升，给出对应的成长计划。同时要拒绝大锅饭，在确保判断无误的情况下合理进行分配。
|
|
|
|
|
|
## 二、错误知觉
|
|
|
|
|
|
上一段内容中，我提到了“确保判断无误”这个词，为什么要强调它？主要原因在于我们的知觉很容易受到误导。
|
|
|
|
|
|
不知道大家是否有过这样的经历，当发现一个员工连续在一些事情上犯错后，我们会不自觉地更多地关注到他后续的错误行为，例如上班时不认真干活而在看不相关的资料等，但与此同时，却觉得其他有同样行为的员工是在做完本职工作后扩展学习。
|
|
|
|
|
|
出现这种现象的主要原因在于，我们的信念和预期在很大的程度上影响我们对事件的建构与看法，例如有消息说美国实施紧急法案后中国股市会回升，这时相信这个消息的人会以美国不行了、美股跌了中股会上涨等理由证明这是正确的，并且对反向的信息越来越封闭(Jelalian & Miller)，而相信股市会下跌的人，会以全球金融不行了、中国出口受影响等理由证明这才是正确的。
|
|
|
|
|
|
这种现象其实很容易出现在各种评审会议、技术讨论等现实工作中，比如很多时候技术并非只有一条道能达成结果，但是如果多个研发有不同的思路，大部分情况下都会想法设法去证明基于思路的方案才是对的，同时陷入对其它方法的批判中，事实上双方的方案可能只是取舍方式不一，并无绝对对错。我们的先入之见会强烈地影响我们对事情的判断和解释。
|
|
|
|
|
|
另外，大部分人还会陷入“信念固着”的困境中，即使支持这个信念的证据被否定，但信念本身依然会存活下来，并可能会愈发固执。一个陷入信念固着的研发，当他支持的技术方案被否认后，他并不会去考虑其他人方案的可行性，而是努力地在原先的方案中抽取可行的部分，凑成新的方案来争辩，即使新方案依然是有问题的。因此，建议大家在团队内推行以下思考方式：“如果我是一个持相反意见的人，我是否会同那些与我信念不一致的人得出同样的结论呢？”
|
|
|
|
|
|
除此之外，错误知觉还有其他表现形式。心理学的一些研究表明，我们的记忆系统并不是一个储藏过去事实的地方，我们的记忆，实际上是在我们进行回忆时重构的，它会受到当前所持态度的严重影响(Loftus)。而且有研究数据显示，人们总是将过去错误的判断回忆成基本上是正确的(Tetlock)，也就是即使一开始判断错了，却依然会当做是几乎对的。打个比方，某个人分析股市，他早期判断可能是腾讯游戏类不行了，股价肯定会下跌，等到某一天腾讯股票涨了，他却会认为“我几乎是对的，腾讯游戏类确实不行了，要不是因为微信起来了，它股价肯定就跌了”，在专业术语上讲这种也被称为过度自信。
|
|
|
|
|
|
这种现象在技术管理者身上，就很容易出现误导信息效应，也就是很多时候态度改变后，就可能会坚持认为自己一直以来都是这样想的。比如在与团队成员相处时，因为某个时间点对方的行为或彼此的关系变差，技术管理者很容易认为这个人从一开始就很糟糕或者彼此的关系一开始就很差，即使一开始的评价是正向的，也就是当前情感状态容易影响到记忆中的情感状态(Safer & others)。
|
|
|
|
|
|
因此，针对团队成员的判断，最好的方式是进行记录，不要受到自己情感状态变更的影响，相信自己所记录的，而不要以之前可能不是太了解之类的理由让自己处于一个错误的判断中。
|
|
|
|
|
|
## 三、基本归因错误
|
|
|
|
|
|
上文中提到针对团队成员的判断，相信大家都有自己的一套判断方式，但是这边要提出一个技术领导者很容易犯的错误，包括我自己在内。
|
|
|
|
|
|
通常情况下，我们都会做出很合乎常理的归因，但是我们会习惯把他人的行为更多地归结为内在的特质以及态度，很少去考虑环境的影响限制，即使这个影响非常显著。原因是在于我们观察某个人表现的时候，那个人是我们的焦点，情境相对而言处于不可见的状态。但是我们观察自身的时候，会更多地去关注需要作出反应的情境，因此情境是可见的。
|
|
|
|
|
|
而情境的不可见容易给技术领导者带来误判，例如这个团队成员当前的状态如何，是否陷入对未来的迷茫？他的家庭生活/成员近期是否发生了变化？他当前是否对某些事务有意见？各种各样的情境很容易给团队成员带来巨大的改变，作为技术领导者，应该对这块了如指掌，否则将难以做出正确的判断以及补救。
|
|
|
|
|
|
就如同我们所观察到的，近期当父亲的团队成员很容易赶不上迭代，甚至在需求评审中走神，这时如果不清楚近况，就很容易陷入对他们的误解中，而如果能在这种时候给予对应的关怀，减轻短期的工作量，引导赚奶粉钱的思维等，等团队成员熬过新生儿最让人疲惫的前几个月，他们的状态反而会更加良好甚至爆发性增长。
|
|
|
|
|
|
## 四、自我妨碍
|
|
|
|
|
|
限于篇幅影响，我选择了一个技术管理者的自我陷阱作为最后内容，它很常见，而我们作为技术管理者，需要克服它来得到提升。
|
|
|
|
|
|
所谓的自我妨碍，指的是人们习惯设置障碍来阻挠自己成功，以达到保护自尊的目的，大家先别急着否认，可以试着看完后回忆下。
|
|
|
|
|
|
前面讲过我们习惯把失败归为外因，以达到保护自身形象的目的。例如曾经年少的时候在考前各种玩耍而非学习，一旦考砸了就能把原因推到玩乐耽搁了学习而非能力不行上，一旦考好了则可以提升自己聪明的形象；再比如做一些项目没成功是因为一开始没认真去做，而非能力不足等等。
|
|
|
|
|
|
而研究者们发现，人们为此会做以下事情：
|
|
|
|
|
|
* 减少对重要的事情的准备(Rhodewalt & others)；
|
|
|
* 给对手提供一些有利条件(Shepperd & Arkin)；
|
|
|
* 在任务开始时不好好干，以便不对自身产生过高期望(Baumgardner & Brownlee)；
|
|
|
* 在关系到自我形象的困难任务并不会尽全力(Hormuth)，等等。
|
|
|
|
|
|
因此，在我们自己接手一项有难度的事情时，需要尽量去克服这种心理，同时需要使用各种方法来帮助团队成员避开这个陷阱。
|
|
|
|
|
|
## 结语
|
|
|
|
|
|
本文中谈到的从心理学角度看技术管理，其实主要都是针对人的层面，如果从对事、对团体等角度来分析，还包含说服、多人组成的平均水平降低、群体对决策的影响等非常值得探讨的话题。
|
|
|
|
|
|
作为技术管理者，需要关注的问题点着实很多，但是我相信方法更多。时代在不断地改变，新加入的团队成员的想法也在不断地改变，然而时代并不会主动来满足我们的团队管理方式，而是我们需要根据新时代团队成员的变化去不断地调整策略。
|
|
|
|
|
|
## 作者简介
|
|
|
|
|
|
张嵩，TGO鲲鹏会会员，九年互联网工作经验，2014加入他趣，先后从事微服务体系的构建、搭建技术梯队及构建研发体系等。同时从事多年互联网中小型公司顾问角色，为公司提供针对当前情况的技术/效率优化方案及实施，积攒了大量技术与应用结合的实践经验。对基础平台构建、机器学习、架构规划及实施、k8s等有深入研究，开源爱好者，Go语言及多个开源项目的contributor。
|
|
|
|