下属没有达到目标怎么办？我会发现他的优势，分配能体现他优势的任务，然后找一个和他优势互补的同事，协同工作。我会避免让他把时间和精力花费到他的劣势上，更不会希望他能把劣势转化为优势。

首先，让他在工作中改正缺点有可能把事情搞得更加糟糕。提升劣势，我们最好的预期是什么？他把他不擅长的事情勉强做好了。但所需要的时间和完成的质量都不如有专长的人做的好。买股票，不能只想到最好的情况，还得留点储蓄兜底，你把所有的现钱都投入了股票，万一都赔了呢，连翻身的机会都没有了。给一个人做他不擅长做的事情，最坏的情况，就是他不擅长的东西没做好，这并不奇怪，更可悲的是，本来可以做的很好的事情，都没做，再有优势，没有投入，到头来，产出为零。

其次，一个大学毕了业，读了研究生，工作很多年的人，他的劣势，为什么能被你给点石成金，转化成优势？每个人的发展道路都是不一样的，他之所以成长为今天的他，是有过程，有原因的。一个没有领导力的人，并不是今天才没有领导力，他领导力的缺失，在今天被你发现，你看到的是结果。在之前的过程中，他一步一步的错过了提升领导力的机会，或者根本就是领导力压根对他没有吸引力，他一路都是绕着走过来的。你何必赶着鸭子上架，做他力不能及的事情。

最后，精力注重到一个人的缺点上，会狭隘视野，不能让你从团队整体协作上去考虑问题。在一个团队里，不同的成员有不同的性格，不同的经历，大家的优势也不一样。有的人运筹帷幄，有的人千里单骑。只有把注意力从一个人身上挪开，放眼整个团队的时候，你才能知道如何配合最有效，才能最佳的发挥团队的威力。

在总结之前，我想提几个例外。如果没达到目标的是很新的新人，那么他的可塑造型是非常强的，可以给他更多的机会让他发展。其次是这个缺点的危险程度。如果缺点只是不擅长做某件事，那么就没必要硬钢。但如果这个缺点可能对他造成危险，或者对团队造成危险，那么就一定要本着负责任的态度，严厉的指出。就像你发现能让你孩子走上弯路的缺点那样，毫不留情，比如撒谎。另外一个例外，也是管理者自省的一个方式，就是如果同事没有达到预期，是不是自己哪里做的不好，是不是任务要求的不够清晰，是不是当了甩手展柜。

知人善用，对管理者来说，就像搭俄罗斯方块一样，认清每个人的优缺点，扬长补短的组合在一起。

2016年，在一个提升沟通能力的培训中，我第一次接触到了非暴力沟通。那时工作刚有起色，和别人打交道的机会多了，同时也暴露了自身沟通上的短板。那次培训中，我依稀记得学到了一些技巧。后来边琢磨边成长，2020遇见了《非暴力沟通》这本书，这次，它教会了我两个字：接纳。

为什么当时记下的只有一些技巧，而现在体会到了接纳？我想这和人的成长是有关系的，同一个人，不同的人生阶段读一本书，会读出来不同的感受，正像《如何阅读一本书》中说的，一本真正的好书，是一本超越了你理解能力很多的书，你每次读的时候，都会有新的发现，因为你离作者的水平越来越近了。

要想学会用爱的语言进行非暴力沟通，就得先知道是什么导致的暴力沟通？我找到的答案是排斥。一个人因为不满足一个情况，就会生气，生气的时候，就想指责别人。受到指责的人，感觉到自己没错，受了冤枉，就开始反驳。生气的人，排斥了他眼下看到的情况，因为他不想这种情况发生。受指责的人，排斥了别人的指责，因为他觉得他并没错。

人为什么会排斥呢？因为排斥是最容易的第一反应。你说我不对，你就伤害了我的自尊，让我感觉我是一个很没用的人，我当然不能让别人看成是一个没用的人，所以我排斥你说的话，我要反驳，我要争论。做出这样的反应，不需要大脑的思考，一个人的情绪很容被点燃，特别是当对方不友善的时候。所以，避免暴力沟通的手段是什么？接纳。

接纳，是一个人不让情绪牵着鼻子走的第一步，也是最重要的一步。所谓的接纳，就是不管事情怎么样，别人说的话带有多少情绪，我都接纳它，一旦你接住了，你就有了发现它，认识它的机会，就不会急着去反驳，去争辩，反而是你更加愿意去了解它，挖掘它，看看它背后到底是什么支撑的。

比如说，你看到一段代码，写的不如你的意。你这时如果排斥这段代码，你肯定会开骂，如果嘴上你忍住，你心里肯定也想，这什么玩意，写的太菜了吧。如果你接纳了它，你首先会想，他为什么会这么写呢，他当时心里是怎么想的？这种接纳的思维模式，是一个重大的转折，你会用问题去替代评价。同样的例子，同事说你的代码有问题。如果你排斥，你肯定说，你的才有问题呢，我的有什么不好？谁说变量的名字就一定得你那样起？如果你接纳了对方的话，你心里会想，他为什么会这么说呢？他的指导原则是什么？他这么说是想保证代码的质量吗？还是想保证代码的统一标准？

接纳的过程，是自我意识觉醒的过程，你开始知道自己在做什么，不再单一的话赶话，开始琢磨事情或者话语背后隐藏的东西。在《非暴力沟通》中，作者把这些隐藏起来的东西，称之为需求。你生气，是因为你的需求没有得到满足，别人生气，也是因为他的需求没有得到满足。你一旦接纳了你不愿意看到的情况，或不想听到的话，就是打开了认识人们深层次需求的大门。一旦你开始从需求的层面上看待彼此，你就会发现，彼此的心灵都是美好的。就拿代码审查举例子，你看到不好的代码而生气，是因为你对代码的质量有要求，你渴望干净整齐的代码。

更加神奇的事情还在后面，一旦双方搞清楚了彼此的需求，他们会愿意伸出援助的手，因为从内心深处，我们人类是一种喜欢帮助别人的物种，帮助了别人，能实现自己的价值，会发现自己是一个有用的人，会使一个人变得非常开心。

非暴力沟通教会了我接纳，接纳的东西越多，你会发现自己的心田被浇灌的就越多，那里会慢慢的结出爱的花朵。

你是团队的技术负责人，肩上扛了一个，销售催得紧，客户等不及，可行性模糊的项目。你对你的老板说，这个项目我规划不了，未知的东西太多了。当初我就是这么干的。如今，大大小小的项目经历了十几个，技术负责人做了快三年，学会了几个和未知相处的方法：分开已知和未知，拿替代方案减少未知，提前遇见未知，和最美的迭代未知。

分出已知和未知

分出已知和未知首先会让你成为一个思维有逻辑，表达清晰的人。如果你是老板，你听下属汇报的时候，到处模棱两可，恐怕你很难给这个下属委以重任。很多时候，未知只占很少的一部分，一颗老鼠屎，坏了整锅汤，未免太可惜了。与其说，这个项目有未知的部分，我规划不了。你可以说，这个项目里，有一部分需求清楚，方案可行，需要三十天，另外一部分，我们需要进一步的探索，目前规划起来难度大。这样一来，老板不仅知道你做了有效的工作，还会增加对你的信任。

第二个好处是客户可能暂时根本不需要那些未知的部分。很多时候，你只开发20%的功能，就能满足80%的需求，这是著名的帕累托的八二法则。一个项目，不会因为存在部分的未知就会让整体失去意义。如果你项目中，恰巧已知的部分，可以满足大部分需求，就可以先把未知的部分暂时搁置。

最后，就是你可以管理利益相关者的预期。作为技术负责人，在大家着急的时候，会让你说一个发布日期。你迫于压力，也出于对团队的保护，很可能说一个足够遥远的日子。这样做，其实是你给自己挖了一个坑。一是你很难解释这个日子为什么这么遥远，二是看似遥远的日子，在处理一些复杂度高的任务的时候，你实际需要的时间会比预期的多。所以，分开已知和未知，只在已知的部分承诺交付日期，在未知的部分一定不要做没把握的承诺，不管压力有多大。清晰的解释未知的部分，会让利益相关者感受到项目所存在的风险，神奇的是，他们会和你一起找办法。

拿出替代方案减少未知

如果未知的部分是项目成败的关键，为了避免在一棵树上活活的吊死，你可以找一些替代方案。这些替代方案，如果找的精妙，可以快速的产出部分有价值的东西，也可以为你们争取更多的时间做更加完美的方案。最为惊喜的是，在寻找替代方案的过程中，你们会更加深刻的认识到，那些是可以砍的，那些是必需留的。

但是这么做也有一个陷阱。如果你的替代方案像秋后的蚂蚱，活不了几天，千万不要在它们身上浪费时间，这只会给你们团队造成更多的麻烦。很多时候，你认为火烧眉毛的事，很有可能是有人为了倒逼你们出成果而采用的心里战术。到目前为止，我还没有见过哪个项目是真正的一天两天等不及，却见多了因为赶工而让整个团队深陷的维护陷阱，返工，以及可悲的人员流失。

找替代方案既有好处也有缺陷，如何衡量？我会问自己一个问题，这是从《逃脱构建陷阱》得到的灵感，我们是为了交付而交付，还是为了产生价值而交付？

提早探索下个未知

当项目中都是已知的时候，不要高兴的太早，等你已知的都做完的时候，一旦遇到未知，你们就会被卡主。项目进展顺利时，大部分人要低头拉车，一定要有人抬头看路，作为技术负责人，你就是那个必须要看路的人。

看路的时候，你不能只自己看。带上产品经理，毕竟路都是他指的；带上某些队员，要不然低头拉车久了，缺乏参与感。看路的目的，就是在稳步推进已知的同时，提前探索下一个未知，这样一来，你们会进入一个良性循环。当下一个阶段开始的时候，如果你按照开头说的分开已知和未知，你会发现，有不少东西都有了眉目，团队可以立马撸起袖子干。

迭代未知

我相信上面的几个办法，熟练掌握后，你可以很从容的去处理项目中的未知。但真正的能去拥抱未知，把未知转化成优势，还得在团队上下，培养迭代未知的能力。有未知的项目，就像摸着石头过河，你不知道深浅，就去摸石头，摸完就知道前面可不可以走，需不需要调整方向。普通的人，一小时摸十个，优秀的人，几百个。河都是同一条河，有的人摸索的慢，有的快。

天下武功，唯快不破。什么是快速迭代？从技术层面讲，你们一个程序员从代码提交到功能上线要用多久的时间？你们一天能交付多少次代码？交付完之后有多少原有功能照样好用？如果交付的不好，你们用多长时间修复它？从产品层面讲，有多功能你们不用开发，就能测出来他们是否真的有用？你有多少用户愿意尝试最新鲜出炉的功能并且给你们反馈？

之前的三个办法，可能会因为个别人的努力而得以解决未知带来的困扰，快速迭代的功夫，一天修不来，一个人也修不来，它需要整个组织的努力。这样的组织，一定是一个学习型的组织。

你带领的团队扩张，项目增加，你追求什么都做好，可时间有限，分身乏术怎么办？我总结出来的办法是聚焦关键，关注那些能让你们和他人变得不一样的元素。接下来从架构设计，项目管理，人员加薪几个例子中说说聚焦关键的功效。

只有最核心的领域才需要最精细的设计，这是我在《领域驱动设计》中学到的最重要的一课。当你设计一个软件系统的时候，这其中有关乎你业务成败的核心领域，这是你和别人区别开来的地方。还有很多普通领域，你的系统中需要，别人的系统中也需要。作者埃文斯很坦诚的让我们接受一个现实：那就是你的时间和精力是有限的，你不可能在所有的领域中都注入同样的心血。如果背道而驰，就是忽略了核心领域的所应得的重要位置。拿测试来讲，在核心领域，我们要尽量的多写测试，来覆盖核心逻辑，测试的数量要多，种类也要多样，单元测试，整合测试，功能测试，都得配套。而针对普通领域，比如写消息到Kafka里，测试可以少，或者都可以没有，因为他们复杂度低，出错的风险低，如果出错了，被及时发现的可能性也大。

管理项目也需要聚焦关键。当大小项目有七八个的时候，我们已经很难近距离的计划追踪每个项目。如果非得这样做，你的精力会被耗费在永不终止的上下文切换中。在计算中我们都知道，如果操作系统在不停的做上下文切换，那么就不可能执行实质性的计算任务。人也一样，我们的大脑在不同的任务中来回切换，也会降低效率。当你正深入思考某个东西的时候，被人打断甚至会让你变得心情暴躁。聚焦关键项目最重要的是识别关键。宽泛的说，关键项目一般都时间紧，不确定，复杂。一个时间宽松的项目，你大可拿出让子弹飞一会的魄力。不过要特别注意，关键项目会变，在一个阶段关键的项目，经过精心的打理之后可以变得稳定独立，而放手太久的项目，可能变得关键起来。

最后说说团队加薪。带了团队之后才发现，一个经理不可能在每个人身上都花费同样的经历来研讨应该加薪多少。如果这样做，这意味着你要深挖每个人的贡献，分析他们的成长潜力，揣测他们可以接受的增幅。分身乏术，同样的技巧，要把精力聚焦在那些去留可以在团队上产生大的变化的人。这些人，你必须细致的照顾，因为如果他们走了，你的团队就会少了锐意进取的冲劲，少了攻克难关的扎实本领。

总结下来，聚焦关键，看似是取舍，是不得已而为，其实是一种能有所成就的做事方式，这种行事方法里，你有了策略，有了重心，有了高度，有了眺望。

研发经理，有的抓产品研发，有的扛系统运维。如果你负责研发，那么产品经理将是你的关键合作伙伴。你们工作虽然有交集，却隔行如隔山，扮演的角色不同，思维方式就不同，所需的技能也不同。能够充分了解你的产品经理，与他优势互补，是你们合作构造成功产品的助推器。

产品经理是你的合作伙伴，我们可以从如何了解一个合作伙伴开始，然后再把这种办法具体应用到产品经理上。了解一个合作伙伴，我有一个框架可以用，具体分三步走。

首先是认清你们的共同目标，这是最为关键的一步。因为只有认清你们要往哪里走，才能力往一处使。倘若大家对目标的理解不同，所做的一切都将成为对方前往目标的阻力。

其次是搞明白达成此目标，不同的合作者，如何贡献他们的能力。这也是团队合作的魅力，每个人的优势都不一样，一个人很难十八般武艺，样样精通，只有拧在一起，才能完成个人无法完成的事。

最后，通过分析不同合作者，能力的共同点和差异点，来更好的认识你的合作者。共同点一般比较好理解，因为你们有共同的语言，这里要想充分的理解一个人，要把重点放在差异点上。

框架勾勒出来了，现在把问题具体到研发经理和产品经理上。你们的共同目标是什么？一般情况下，你们是想开发出一款用户爱用，愿意花钱买，能解决他们问题的产品。这个产品小到可以是一个闹钟应用，大到是一个搜索引擎。可不管是什么样的产品，它都得必须能解决一个实际问题。团队中，不论是程序员，测试员，还是产品经理，没有一个人乐意去做一个没人用的东西。

确定目标是最关键的一步，也是最难的一步。有一个小技巧，可以帮助你们找到共同的目标，就是多追问几下，追问的过程，其实一个追根溯源的过程，看似不相关的东西，往根上挖一挖，就有了联系。这个技巧有一个陷阱，就是不要挖的太深，太深了就开始虚了，别到最后，发现你们的目标是改变世界。

目标清晰了，开发出一个款解决用户痛点的产品。这需要什么样的能力？我们可以概括为发现问题，选择问题，解决问题的能力。除此之外，还包括敏捷循环使用这些能力的迭代能力。

首先要发现问题，得有人去和客户打交道，摸清出他们的需求，搞明白什么东西能给他们带来价值，以至于他们愿意去花钱买你的产品和服务。然而很多情况下，用户的需求不是单一的，而是复杂的，系统性的，有时还会受到外部因素的影响，如何从众多需求中找到最关键的？这就是第二步，选择问题，做出好的选择需要多方面的权衡，这包括竞争对手走到了哪一步，公司需要生存下来是否需要做出短期的牺牲来赢取更多的时间，某一需求的投资回报率是多少有没有快速收益的方案。经过多方权衡，需要解决的问题定下来之后。第三种能力就该派上用场，这就是解决问题的能力。通常办法是团队开发完整解决方案。验证能力强的人，会争取把这个过程缩到最短，他会找到最短路径。这一套走下来，有不得已的权衡，有为了省时而走的捷径，并非解决了所有问题，所以还要很多轮的迭代。

目标清晰，达成目标所需要的能力列举的明明白白，接下来就看这些能力都有谁贡献。作为研发经理，我们最擅长的解决问题的能力。产品经理，最擅长的则是敏锐的发现问题的能力，以及在商业，竞争对手，内部资源各种掣肘限制下的选择问题的能力。这里所说的能力，是高度概括出来的，还可以细分。比如说发现问题的能力，这要求拥有此能力的人，能够非常有效的和人沟通，通过交流，洞察并归纳出问题的本质。选择问题的能力，必定有大局观的支撑，如果只能片面的看到一方的限制因素而忽略了其他，则无法做出好的决定。

在这个框架之下，我们可以总结一下一个优秀的产品经理应该有哪些可以和你互补的优势？他深刻理解企业的商业目的，并且能通过解决客户的问题来达成此目的。他有高效的沟通能力，同理心，观察能力，能准确抓住用户的痛点。他还有足够大的大局观，能看到客户，竞争对手，企业内部运营给他框定的各种限制。他还要有影响力，能够让人看到他勾勒的愿景，并愿意为此去奋斗。

以上的思考有受到Melissa Perri的Escaping the Build Trap: How Effective Product Management Creates Real Value的启发，强烈推荐给对产品管理有浓厚兴趣的研发经理和产品经理们。

当我读马利克的《管理，成就，生活》系统学习管理的时候，受到的最大启发，是学会发扬别人的优点。接下来的管理工作中，我就开始留意一个人的优点，并且在做绩效评估的时候，表扬他们的这些优点，对于大部分下属，他们都很开心经理能看到他们的闪光点，并因此更高效的工作。可是有一个下属，在我表扬他的时候，发出了一些怀疑的声音。

当时这个下属拿到了另外一家公司的Offer，正在徘徊是否跳槽。由于他的确很优秀，我试图挽留他，说在他身上发现了不少优点，别的同事也说他工作出色。下属反问我，“我很高兴大家觉得我不错，可能具体说明一下我不错在哪里吗？”。他之所以这么问，一种可能是以为我在搪塞他，另外一种，是真的没觉得自己有那么优秀。从和这个的同事的相处中，我相信他是真的想通过更多的例子来确认自己的优秀。毕竟费工夫留一个不该留的人是不科学的。

我事先并没有准备，可我并非胡乱夸他，随机应变，找出了几个具体例子。可事后，我仍认真思考了这个问题，表扬一个人也是有风险的。如果你显得不够真诚，对方很容易理解为，你为了激励他而使用的伎俩，结果适得其反。心善的管理者断然不会为了操控别人而表扬，可怎样做才能让对方不误解你的真诚？

一直以来，我心中有一个朴素的答案：日久见人心。可在读完马歇尔的《非暴力沟通》后，我发现我们可以更加主动的让对方感受到自己的真诚。在表扬别人的时候，要说明三点：对方做了什么？你的感受是什么？你的哪些需求得到了满足？

感受和需求是达到至诚至爱沟通的两个关键因素，因为它们把你们对话的重点转移到更容易使大家互帮互助的需求上，而不是指责对方或苛求自己。运用这个方法，回到和同事上一次对话中，我会这样说：“我一直以来很满意你的工作（我的感受），这其中有你在之前项目上用Scala贡献的产品新功能，还有在当前项目里通过快速掌握Go语言对团队工作效率的提高（对方做了什么）。你出色的开发效率和学习速度，让我们的团队能承担更艰巨的任务（满足了我建设团队的需求）。”

我相信如果我的领导给我说了类似的话，我会很感激他发现了我的才能，并更加努力的为他的团队付出。这个方法之所以行之有效，是因为表扬的人，是在真诚庆祝对方的行为改善了大家的生活品质，不期待任何回报。除了让对方感受到自己的真诚，这种做法也会推动经理去深挖自己的需求，一旦一个经理清楚的知道他需要什么，并且知道各个成员的优势如何搭配起来满足他的这些需求，我相信他一定能带出一个优秀的团队。

刚从程序员转型过来做管理，我希望把事情都做好，即便是面对棘手的下属，也是想尽办法挽留。可一个下属的离开，就一定是管理上的失误吗？作为一个新手，缺乏经验和自信，不禁把问题的矛头指向自己。直到N+2肯定我的处理方式，才恍然大悟，并不是团队壮大才是成功，下属的离开，也可以归功于管理者。团队在变，人心也在变，该走的人走了，说明管理者把对下属的期待讲明白了，分道扬镳是正果。

我的这个下属，他的老板离职后，分配到了我的团队。起初，不顺，但动力十足，后来，他开始拒绝任务。我费劲找适合他的项目，可要么不是公司的重点，要么是已经分配到了比他更胜任的人手里。

持续了一阵子，我苦苦寻觅，他无奈等待，最后我给他摊了牌，对你的期待就是做好团队当下的任务。我已尽力，仍找不到和你胃口的项目。他暂时接受了。

后来公司举办创新大赛，他领头的项目没有获奖，但进入了决赛。他要求继续这个项目。我同意了，可明确的告诉他，此项目非公司当下的重点，团队不会给你强有力的支持。

没出一个月，他告知我新机会妥了，要辞职。这个决定，对他对我都是一种解脱。

他是我第一个离职的下属，给想至善至美的我，一个很大的启发，做管理，看中的不能是人头的数量，而是留下该留的，送走该走的。对留下的，像《绝对坦率》中所说的那样，深深在意但要严格要求，对离开的，打心底祝福他们会更好。