人类不是机器。
我们可以编写一个程序，让机器严格按照我们的预期运行。如果程序写得好并且机器足够强大，它可以在无需干预的情况下运行数十年。
但人类不能。
人与机器的区别在于他的感性和模糊的理性。
人可能会懒惰、自私；他们也可以追求和给予——但这不是无条件的，需要激励。
人们聚集在一起形成一个独特的实体：人群。管理的本质是群众的组织——组织起来的群众称为团队。
无组织的群众就像一盘散沙。虽然他们满怀热情，但也只是昙花一现。
就像流水总是落到地上一样，人本能地倾向于惰性（可能是身体节能的需求），在做事时倾向于“活在当下，避重就轻”有问题。想想你的团队中有多少问题反复出现。每个人都有黑眼圈，日复一日地解决同样的问题。
在群体交往中，人们总是容易以自我为中心，常常从自己的利益和角度来看待问题。另外，语言本质上是一种模糊理性的工具，使得群体沟通效率总是那么低下，有时甚至严重阻碍项目的进展。想想您的团队中有多少会议时间超过两个小时。
人天生就健忘，尤其是在群体中。 团体进行的项目总是会失败，除非有专门的人/组织持续推动。团体的热情从来不会持续超过三分钟。今天日本首相去拜鬼，我们气得把丰田车砸了，明天就忘了；这次会议上我们说要重构X系统，明天就没有人再提了。
管理主要解决团队的效率问题：当前效率和未来效率。
技术管理真正的挑战在于，虽然“人不是机器”是管理的原因，但管理的结果并不是把人变成机器（流水线生产）。在技术管理领域，机器管理可能会提高当前的绩效，但不利于未来的产出。
我们应该做KPI评估吗？
之所以问这个问题，是因为软件技术管理的KPI考核很难做。
目前，软件仍然是一个“非标准化”产品——它的每一个输出都是创造而不是复制，它的好处无法通过像螺丝钉一样的标准化生产和测试机制来衡量。
此外，软件的好处也被抛在了后面。软件的价值在刚上线时是无法体现的。它的价值是在使用过程中逐渐体现出来的。
所以我们不能简单地用当前的产品输出速度来衡量效益：有可能这种所谓的“效率”是以牺牲未来的稳定性和可扩展性为代价获得的，就像有些企业的“繁荣”是建立在巨额债务。
有的公司使用代码行数、千行bug率、单元测试覆盖率、上线bug数等数据作为KPI指标。不是不可能，但并不理想，很容易形式化，也很容易被钻空子。
KPI考核的目的是什么？最后被淘汰？升职？是的，但不完全是。
领导人脑子里不能只有“评价”——这是政治懒惰的表现。
最好将“评估”这个词从你的脑海中彻底删除。然后用 OKR 替换 KPI。 OKR 关键是他这里强调了一个O，就是目标——这就是关键。
许多球队没有目标。
“怎么可能？我们每个月都加班才能满足这么多需求！”
这是一项任务，而不是目标。
任务是公司或上级下达的硬性要求，是公司业务的支撑要素。完成这些任务是每个团队的职责——但这是公司的目标，而不是你的技术团队的目标。
比如，公司（或业务部门）今年一季度的目标是开发一个大客户，而开发大客户就属于今年的战略目标。对于你的技术团队来说，一项艰巨的任务是为至少一个大客户完成私有化服务部署和定制开发——但这只能算你的技术团队的任务（放在KPI中）——作为一个技术人员团队，这不能作为目标。
技术团队的目标必须从技术角度来设定——这并不意味着技术团队的目标可以不管公司的目标而异想天开。相反，技术团队的目标必须从技术角度来制定。支持公司的目标。
比如，公司在开发大客户方面面临哪些技术难点，可以从哪些方面来提高效率？这些都是技术团队需要重点关注的。大客户需要做私有化部署，甚至使用自己的私有云。技术上能支持一键私有化吗？各大客户都有很强的定制需求，那么我们的基础平台能否支持快速定制呢？
这些目标看似与特定月份的任务无关，但它们是项目成功和长期绩效改进的关键。
从技术角度支持公司业务，提高工作效率，是技术团队的价值。
然而，理想很丰满，现实很骨感。大多数中小型公司迫于生存压力，不得不疯狂开发和迭代产品，却没有足够的资金支撑庞大的技术团队。结果，少数技术人员整天忙于死板的工作，除了搬砖没什么用——但这也不排除另一种情况，那就是技术团队本身（组长）把自己定位为搬砖——感动人，主动放弃思考。
一个团队从KPI转向OKR需要勇气——尤其是在人力资源不足的小公司。设定目标本身就是一个挑战。需要对团队、制度和未来业务进行深入思考和综合考虑。还可能涉及到其他团队的配合，需要说服上级和其他团队支持你的工作（对于沟通能力差的技术经理来说是一个很大的挑战），并承受不确定性带来的失败——相比之下这些挑战，当上级说的时候做1的策略显然要舒服得多。
技术目标的另一个挑战是实施过程是探索性的。比如我们的目标是做服务）等等，这些技术看似都有标准化的实施方案，但在实际项目使用中还是会遇到不断的挫折（不像螺丝的生产，如果你生产十字槽，你永远不会产生直凹槽）。所以在这个探索过程中，如果用“考核”的心态来管理团队，你会发现要么KPI无法设定，要么贡献最大的人得分最低。探索的性质决定了 KPI 本身的主观性。
主观KPI会带来不公平、缺乏说服力、钻空子等一系列问题。
然而，主观不确定性确实是人类与生俱来的特质。人不同于其他动物因为有理性，人不同于机器因为有感性（主观性）。
我们只想用一个理性的框架来框定团队的行为，却不知真正能让团队保持战斗力的是情感。真正让红军战士无私绝望的，是他们对眼前黑暗社会的痛恨，以及对自己看不到的光明未来的向往。
OKR的目的是让团队知道自己的目标（O）以及如何评估目标是否实现（KR）。
有管理者挂在嘴边的一句话是：“我不想看到你们加班的过程，我只想看到结果！”这句话虽然有一定道理，但不能作为中层管理者的座右铭——如果一个团队只有过程而没有结果，那么要么是过程和目标完全不同，要么是遇到了重大障碍却没有做到。得不到支持。这是一起重大管理事故。
技术管理的主观性可以通过记分卡形式的KPI来补充。记分卡的设计主要记录和考察成员主观能动性的表现（需要事件的支持），作为后续绩效评估的补充。 。另外，如果做KPI考核，建议时间维度以季度或半年为单位，而不是每月或每年——几个中小型项目一般一个季度或半年就可以完成，而且一些大型项目还可以实现阶段性目标，方便会员做出更全面的评估。
如果必须进行KPI考核，建议考核粒度只达到团队而不是个人，个人层面由团队负责人独立把控。
技术团队的KPI考核不仅很难做，而且讨论和争议的量在传统行业也是少有的。每个公司都有自己的文化和价值观（对于中小型公司来说，往往是自己价值观的旧版本）。技术团队是否进行KPI评估（甚至如何进行）往往不是技术团队的决定。从个人角度来看，KPI并不能给团队带来太大的效率和质量提升。从技术团队的效率和质量来说，最关键的有两点：
过于严格和死板的KPI往往会适得其反。尤其是与月薪挂钩的方式，最让技术人员反感，很可能导致员工离职。一些高层（非技术）管理者可能会觉得这正是他们想要的：通过薪资相关措施激励关键人员，淘汰闲置人员。实际上，这会导致三个严重问题：
这种机制一方面会给整个团队造成紧张、压抑的氛围，导致团队整体效率低下；
一旦直接涉及到工资，无论是团队成员还是团队领导都会尽力避免这种风险——对于领导来说，他宁愿团队中没有人得到额外的工资，也不愿有人被克扣工资。结果就是各个团队都绞尽脑汁钻空子，要么在KPI设定上趋利避害，要么搞砸了工作质量。没有人愿意承担困难且不确定的项目——人的本性首先是规避风险，而不是追求额外的回报；
毕竟上层的人（领取额外工资奖励的）只是少数，每个月基本都是固定的一两个顽固分子（或者说工作狂）。结果就是这些固定的一两个人感觉很幸福。 ，往往会更加努力地工作，而其他（大多数）人不仅不那么努力，而且常常站在对立面，导致团队分裂。
一个有效团队的管理者需要实行一定程度的专制主义。
大家都喜欢讲“民主”，讨厌“专制”——但这只是满足大众心理需求的语言伎俩。
中国自古以来就是一个专制政府。今天我们称之为“人民民主专政”，就是多数人对少数人的专政。如果没有这一层专制政府，马上就会变成少数人对多数人的专政。
适当的独裁可以提高团队协作和生产力。一个只讲民主而不讲专制的团队几乎一事无成（印度式民主）。
但反过来，过度专制会导致团队僵化，领导说一没人敢说二，成员极度无力感会导致没有归属感——团队属于领导者，不是他们的。
比如，一个团队必须有规章制度。这些规则和规定通常由领导者起草。
如果领导默默写一个规范，扔给团队，我们以后就去做；或者如果扔给团队讨论，讨论会来来回回，不同的声音都会被领导一一否决，最后我们还是按照规范来。 如果领导只想执行制度，这是过度的独裁主义。这种军事化的管理方式并不适合技术管理等创造性劳动组织。
经过大家讨论、同意、敲定后，规范就成为团队的规范，必须以专制的态度去执行。如果规范要求需求上线，则必须经过多个测试流程，并且必须经过谁的批准。结果张三的一个小需求没有经过必要的测试环节就上线了。这种违反规范的行为必须受到相应的处罚（如通报批评）。 ），否则规范就会逐渐被大家忽视，团队就会进入平庸的民主状态。
建筑师也必须实行一定程度的专制，否则他们的建筑设计将难以实现。然而，在很多公司中，架构师没有足够的权利要求每个系统严格执行其架构设计（尤其是跨团队工作时），所以一般只有性格坚强、坚持不懈的架构师才能完成自己的夙愿（或者架构师是善于向上管理），利用上级的权威行事）。
优秀的领导者能够更好地把握专制与民主的尺度，即让团队保持较高的执行效率，同时又不扼杀成员的主观能动性。 “人民民主专政”是一项伟大的制度创新。这是一种在民主与专制之间寻求平衡的政治制度。在团队管理方面，我们应该多多学习。
团队之间也存在民主和专制的问题。我们现在谈论敏捷，喜欢建立“自我管理”的敏捷团队。但现实的一个问题是，这些团队过于强调团队本身的独立性。他们不仅不接受其他团队的管理，也不接受上级（通常是这些团队的）的管理。上级不太关心他们），这就导致团队之间的沟通和协作成本很高。高昂的沟通成本反过来又导致团队之间不愿意沟通，因此您经常会发现这些团队中的每个人都执行许多相同的基本职能。 。
我曾经工作过的一家公司曾经专门组建过一个架构组（或者说基础设施组）来解决这个问题，但是失败了。问题是这个架构组的成员和其他敏捷团队之间没有有效的互动，他们没有权利治理其他团队。有的团队遵守这个架构组所做的架构设计，有的团队则不遵守；他们创建的基础设施也不一致。很少被其他团队使用——因为这些人只是为了建设基础设施而建设基础设施，而他们生产的东西往往不能满足业务需求。
更好的方式是从每个团队抽调一些技术骨干（或者技术经理，抽调的人在团队中必须有相当的发言权），组成虚拟架构师团队。这些人在技术上代表了公司的核心，代表了各个业务团队的利益。这个虚拟团队需要由这些团队的直接报告来领导。这样的团队不仅拥有相当大的权利，而且代表了实际业务团队的利益。他们制作的建筑设计和基础设施能够更符合实际需求。
想一想，你们公司的团队是在践行希腊城邦式的民主吗？
团队之间存在沟通障碍。
如果你参加过跨团队的项目，你会发现团队之间的沟通和协调是多么麻烦，尤其是当几个团队不在同一个办公地点时。
经常发生的情况是，A队的张三需要与B队的李四协调某项职能，但李四却被调去做其他事情。可惜的是，张三要等李四，王五也要等张三。
A组的张三做了一个功能模块，B组的李四也做了一个类似的功能模块。
A队的张三将某个数值四舍五入到小数点后两位，而B队的李四则四舍五入到小数点后四位，最终导致报告出现了一分钱的错误。
......
对于跨多个团队的大型项目，需要建立专题项目组，并从各个团队抽调人员组成临时的、以项目为基础的虚拟团队——否则这个项目往往会成为一个无头项目，没有一个一般的负责人来全程跟进。
虚拟团队由项目经理领导（可以不是全职，比如技术负责人或者产品负责人兼职，但他需要对整个项目全面负责）。另外两个重要角色是产品经理和架构师（架构师不一定是全职的，比如可能有某个主模块的兼职主程序员） -这两个角色各自负责项目的业务和技术正确性。
由于虚拟团队是临时组建的，所以有些角色是兼职的，有些人并不清楚自己所承担的角色（例如产品经理承担了项目经理的角色，但并没有意识到自己所承担的角色）应及时审查项目进度和潜在潜力（资源分配问题）也会导致无头项目风险。没有明确角色定义的群体不能称为团队。团队建设者（通常是上级领导或上级领导授权的人）在组建团队时必须公开声明关键角色候选人以及（更重要的是）其职责范围。
正是因为这些全局关键角色的存在，虚拟团队才能打破团队沟通障碍，实现项目团队成员之间的整体理解和步调一致。
虚拟团队中的成员处于不稳定状态：一方面要关注项目组的事情，另一方面又要关注原来物理团队的事情团队。工作交错的情况经常发生（特别是在人力资源紧张的小公司），这种交错常常让人无所适从，让团队成员抱怨不已。另外，由于虚拟团队在归属感方面存在先天劣势，虚拟团队管理者必须更强才能维持团队的团结。为了“物化”虚拟团队，有意将成员与原来的实体团队隔离，虚拟团队往往会退入“小暗室”（尤其是在项目冲刺阶段）——这种隔离使得虚拟团队成员的成本他们之间的沟通被降到了最低限度，他们和原来团队之间的沟通成本也大大增加了。
有一群技术经理，他们永远是团队中“最忙”的。他们每天加班到最晚。他们始终是处理在线问题的人。他们每个月的任务也是最多的——总之，无论多小，只要自己能做，就绝对不会让别人做。奇怪的是，他们的团队总给人一种杂乱无章的感觉，事故频发，每次成绩都不高。
很多技术经理还没有完成身份转变。他们把所有的时间都花在执行特定的任务上而不加思考。他们缺乏团队组织，团队事务无人跟进。团队成员遇到障碍。没有人协调，也没有人考虑重构系统中的顽固Bug。
他们认为只有敲代码才是真正的工作，其他一切都是想象的。
有两件事值得思考：重要但不紧急的事情和紧急但不重要的事情。 组长必须花大量时间思考和处理重要但不紧急的事情，而不是整天救火。
别人注重当前效率，但Leader更应该关注未来效率。
团队中每个人的特点是什么，需要培养哪些人作为团队的骨干和接班人？
当前系统存在哪些问题？为什么会存在这些问题呢？我们什么时候应该安排如何处理这些问题呢？
之前的迭代暴露了什么样的问题？当前的工艺规范是否应该改进以及如何改进？
对于未来公司的发展，我们团队需要提前做好哪些准备？
早上，张三抱怨A队李四负责的模块没有进展，推不动了。我必须去看看吗？
王舞的编码水平怎么样？你想看看他写的项目吗？
这周你会带大家去哪里流浪呢？
......
技术团队的灵魂是技术——技术本身就是点燃团队热情的火花。
有些人在谈论团队文化时，更多地从“道德”层面（公司层面）思考某个团队应该具备什么样的文化，比如“顾客至上”、“奋斗青春”等。
文化是从内部产生的，而不是从外部冠冕堂皇的。
比如“客户至上”可以作为技术团队的行为准则，但不能作为技术团队的文化核心——除非他们是技术支持团队。强加外部属性作为其文化的核心，会让团队成员感到被忽视（甚至被歧视）——想想如果销售团队每天喊着“我们是一群技术极客”会有什么反应？
文化必须来自于群体的独特属性。技术人员的独特属性是技术。他们对技术的热爱让他们进入了这个行业（至少在最初），技术输出会给他们带来无上的成就感。
缺乏技术氛围的技术团队是没有灵魂的。一个没有灵魂的团队很难产出优秀的东西，日复一日地上演悲剧。
技术领导者的职责之一就是想办法为团队营造技术氛围。
技术分享会应该成为团队日常工作的一部分。分享会的目的不是让大家掌握一些深奥的东西——一两个小时能聊什么——而是调动大家的技术热情和开放性去分享，同时也可以作为一个交流的平台。日常忙碌中的一杯茶。护发素。
分享会可以定期或不定期举行，最好不要限制范围（有的公司会做一些需要与公司业务或技术栈相关的软性限制，这样会让人感觉太功利而失去兴趣）。
分享会一般在全公司范围内召开（当然也可以在团队内部召开，因为有些人觉得分享的内容平庸，不想大规模表达）。
为了鼓励大家参与，可以有一些奖励机制，比如考核加分或者晋升。
另外，Leader还要对团队提出更高的技术要求，比如代码审查，这就要求代码的质量；压力测试、渗透测试等，这些都对系统的质量有要求。
月度任务项中应安排一定比例的技术任务（如系统改造、基础设施建设、顽固Bug处理等）。这些任务比日常业务任务更具挑战性、更复杂。它可以锻炼人，激发大家的兴趣。
有了技术氛围的火，就可以追求第二品质：商业氛围。
技术团队大部分属于业务团队，大部分开发工作也是开发业务系统，但并不是每个人都对自己团队负责的业务非常熟悉。有些人可能常年只负责某个模块，甚至可能不了解完整的业务闭环。
面向业务的技术团队对业务的冷漠是团队的又一悲剧。由于缺乏对业务进一步探索的积极性，很多人一直停留在业务的某个环节，对业务流程只见树木不见森林，在设计时无法顾全大局系统——这种情况是基于功能的（对于项目以外的组织中的团队尤其如此。例如储值卡业务涉及制卡、储值、消费、车队卡、家庭卡等。制卡、储值、消费还涉及到不同的入口（如手机、POS机），而这些环节可能是由不同的人维护的，如果他们对储值卡业务根本不感兴趣，他们没有动力去了解整个业务闭环的每一个细节。
对生意漠不关心的原因有很多。例如，该业务不盈利，属于公司的边缘业务；或者业务系统是历史遗留下来的，不是亲生儿子，bug太多；或者可能大家根本不了解这个业务。我不知道有多少人在使用这个业务系统。
Leader需要让大家知道团队所负责的业务的价值，比如某项业务上个月赚了多少钱，某App这周的下载量增加了多少等等，人们不感兴趣在没有价值的事情上。
对于历史遗留系统，团队应该有一个更清晰的计划来解决遗留下来的顽固问题（当然，如果这些问题不影响使用，给大家的日常生活带来麻烦（没完没了的bug），那就另当别论了）事情） ）。
只有团队对业务感兴趣，才有可能追求第三种品质：服务氛围——只有每个人都有以客户为中心的意识，“客户至上”才不会只是一句空话。
技术氛围、商务氛围、服务氛围是递进关系。前面的比较基础，也比较重要。技术团队可以没有服务氛围，甚至可以没有业务氛围，但不能没有技术氛围。
注意，这个顺序与公司层面的追求相反。公司层面必须是服务（客户）->业务->技术。正是因为这个原因，很多企业无法了解技术团队的特点，忽视技术团队的现状，强迫技术团队与公司水平保持一致，并在技术团队中大力提倡“客户至上”，让技术人员感觉公司根本不关心技术团队的死活。
