为了完成同一个目标，团队需要不同职能的人合作。干大数据这一行，我就拿大数据团队来说，我们有个团队，它的任务是找到客户网站里最应该被修复的Javascript错误。团队里有产品、项目、研发经理，前后端、数据、机器学习、质量控制工程师，设计师。有的时候，我觉得这很奇妙，都说隔行如隔山，这么多不同背景的人竟然能拢在一起做一件有意义的事情。奇妙之外，也有挑战，特别是交流受阻的时候，毕竟大家受的教育，擅长的领域都不一样。跨职能团队能高效合作，最关键的就是说别人能听懂的话。

什么人会说别人听不懂的话

有的人不是故意让别人听不懂，只是他们没意识到，沟通的好必须要说的人说的明白，听的人听得进去，少一样都不行。这些人通常都特别认真，你给他说听不懂，他会重新给你解释。

还有的人是懒，懒的解释，他们觉得解释等于浪费时间，应该有专人做培训的事。我团队里就有这样的人，他给新来的产品经理介绍现有功能。解释过后，别人还是不懂，他就觉得浪费时间了。产品经理应该找其他的同事搞明白之后再来找他。

再有就是不懂装懂的人。他们生怕被发现不懂，就用华丽的辞藻，缥缈的概念给自己打掩护。话绕老绕去，就是不往关键的地方说。我之前一个同学本来邀请大家去参观他家的大别墅，可去的路上给我们饶了几十个弯，说是离家远，等真正看到他的大别墅的时候，发现根本就是平房几间。

最后一种，就是骄傲的人，说别人听不懂的话，是为了炫耀自己懂的东西很深奥，听不懂是因为太弱，这样他会感到一种把别人比下去的优越感。

为什么要说别人能听懂的话？

说别人能听懂的话，表示对别人的尊重。只有互相尊重，才能营造信任的氛围。外地人和你聊天，用你的家乡话问候你，说明别人在乎你，对你做好了功课。你有了被人重视的感觉。接下来就会觉得这个人是安全的，你可以信任他。如果一个团队里， 大家互相不尊重，觉得对方做的东西很低级，那这是一个互相鄙视的团队，一个缺乏信任的团队。如果产品经理，不想着把客户的需求解释清楚，觉得工程师是一伙骄傲自大的家伙，只会沉浸在代码里，那就不要期待着工程师能做出来符合需求的东西。反过来，如果一个工程师，觉得产品经理就嘴上厉害，动不了真刀真枪，就不乐意把代码关联到业务上，就不要期待着产品经理能带来有用的客户反馈。

说别人能听懂的话，有利于提升工作效率。有些话是能推动项目进展必要的话，有些话是无用话。像在沃顿商学院的《运营管理导论》中介绍的那样，提升效率，就是减少浪费。在生产产品的时候，工人们在工位上的移动，都是浪费，因为他们在移动的时候，是没有产出的。不清晰的话，无用的话，浪费的不仅是说话的那几分钟，它还会有放大效应。因为讲的不清楚，就给团队带来不确定性。人们会它把不确定性当成一种威胁，会牵扯更多人，更多的时间去消除这些不确定性。如果这种不确定性，是真实存在的，比如不知道什么方案能解决用户的痛点，那么需要迭代把它们变得清晰。但如果这种不确定性，是因为工程师对一个项目经理说要用一种非常纯粹的函数式编程方式把错误给Log下来，那么这种不确定性，就是人为制造的不必要的恐慌。

如何说别人能听懂的话？

说别人能听懂的话，要了解别人擅长的领域，倾听别人的需求，提升自我的表达能力。

首先了解对方擅长的领域，熟悉别人圈子里的话。我转行做了研发经理的时候，发现和产品经理的对话更多了，在团队过渡期的时候，产品经理可能都不到位，比如说离职了，这时候自己也得学会扮演产品经理的角色。作为研发经理，你对产品经理知多少？我找到一种了解别人的框架，总结下来就是：在达成同一目标的时候，你们各自的专注点是什么？你们各自的贡献是什么？搞明白别人的贡献，你就找到了别人擅长的领域。产品经理擅长的领域是解释为什么我们要做这个项目，为什么它能满足客户的需求。在这个领域里，他们的日常语言主要围绕在客户，需求，痛点，项目的动机上。明白了这些后，我慢慢的学会了他们圈子里的话。

其次是倾听，搞明白别人的疑惑。当一个人需要解释的时候，那个人本身就处于弱势地位。他可能怀疑，自己的能力才足导致听不明白。如果你火上浇油，又给人解释了一通不相关的东西，只会让人更加迷惑，更加怀疑自己的能力。让别人充分的表达出他们的需求，他们的目的，他们认为最重要的东西，他们所期待的细节的数量。这让你不仅显示出你对别人的尊重，而且能让你有的放矢，增加沟通的有效性，减少无用话。

对别人做足了功课，传递了你的尊重，明白别人的需求之后，接下来就看你能不能把你擅长的东西，用简答易懂的话说出来，最简单的话，莫过于现实生活中大家都在经历的事情。比如说你在优化缓存，缓存有什么用呢？应用到生活中。缓存就像一个电冰箱，与其每次跑到超市买东西，你把超市的东西存在冰箱里，每次用的时候，去冰箱里找就好了。生活能手，会把最常用的东西放到冰箱里，大部分时间都能在冰箱里找到想要的。这是因为学透了，可以关联类比了，可以把知识从一个专业领域，翻译到一个大家都能听懂的生活领域。我给大家一个挑战，看你能不能用大白话讲清楚乘法的交换律，为什么甲乘以乙等于乙乘以甲？

结语

说别人能听懂的话。往小里说，能展示你对知识掌握的熟练程度；往大里说，能代表你是一个什么样的人，它能彰显你的谦虚，对别人的尊重，对别人感受的照顾。上面说了这么多，对你最有用的东西是什么呢？

扁桃体发炎能导致嗓子疼，话说的多了也会。带团队，人越多话就越多，除了多喝些水之外，还有什么办法能保护好嗓子呢？那就是多听，让别人多说。我就是经常嗓子疼，寻医问药的时候遇到了一本这样的书《教练的习惯》，教人少说多问，不仅能保护嗓子，还能帮助团队成员更好的成长。

《教练的习惯》一共介绍了了七个问题，让管理者和团队成员进行更有效的对话。一方面帮助管理者更省心，更高效的带领团队，另一方面帮助团队成员更有深度的思考，实现自身的成长。

启动：心里想什么呢？

这个问题可以让队员快速的进入深度交谈，因为它开放，直接，专注，能唤醒一直萦绕在心间的思绪。你们不用花上十分钟的时间去谈论天气，谈论你最近看的电影。跳过这些热场的闲谈，直击大家都关心的问题。

选择：还有其他的吗？

这个问题让你们发现新的可能性。引导队员去多想想替代方案，可以让你们有更多的选择，帮助你们更好的决策。

在队员介绍完了他的解决方案的时候，你问他还有其他的方案吗？这样会引导他更全面的思考。

对于管理者来说，多问这个问题可以保持自我控制，保持一颗好奇心，如果你没有准备好，当别人思考其他选项的时候，这个问题还可以帮你争取更多的时间。

专注：什么是你真正的挑战？

追寻真正的挑战能让你们抓住问题的根本。把注意力往真正的问题上引，而不是第一个出现的问题上。作为管理者，如果只是单纯的答复队员提出的问题，你可能会掉入下面的几个陷阱：

• 解决了错误的问题
• 你做了你的团队应该做的工作， 增强依赖性
• 工作完成不了，成为团队的瓶颈

这个问题虽好，但不要傻乎乎的当别人问你订书机在哪里的时候，你问他真正的挑战是什么。在下面的场景中，你可以问这个文题：

• 当一个人描述很多问题的时候，对他来说，时间紧，任务重，钱少，队友不给力，需求不清晰，没有一件事是好的。你有种窒息感，你可以问，”如果你在这里面选一个问题专心解决，哪一个是你真正的挑战？“
• 当队员开始说八卦，嚼舌头，发牢骚，无病呻吟，说第三者的时候，你可以问，”你要直面自己，我知道有很多事情在发生，对你的真正的挑战是什么？“
• 当有人高谈阔论，只提大家，不提他自己的时候，你问他真正的挑战是什么。

根基：你需要什么？

这个问题可以给队员营造一个安全的环境，让他表达自己的需求，可以帮助他深层次的思考。否则，当一个人处于危险中，他会为了保护自己，选择逃脱。

你的需求是什么？这个问题可以增加安全指数

• 与其命令他要做什么，你在帮他解决问题，所以他知道你是好心愿意帮助的
• 你认为他可以自己找到答案，所以增强他的自主感
• 增强他的重要性，因为你让他先入为主

然而，并不是所有的成年人，都能清晰的表达自己的需求。一个真正成熟的人，是明知道自己的需求可能会被拒绝，还能勇敢的，清晰的说明自己的需求。

偷懒：我能帮你做点什么？

当队员遇到困难的时候，与其直接给出帮助，要问他你可以做些什么。这看似是一个偷懒的问题，其实它有两个厉害之处

• 你强迫对方给你一个直接清晰的请求，而对方在思考如何表达自己需求的过程中，也会把问题想的更清楚，甚至有的时候，他突然明白了，说，“呀，原来我根本不需要帮忙，我已经找到答案了”
• 让管理者自己保持好奇心，避免管理者自提供自以为有用的帮助，

提供帮助的人可能无意，但是当你帮助另外一个人的时候，对方会觉得自己地位降低。所以在帮助之前问对方也是一种尊重。

我有一个队员。他远程办公的时候，限制比较多，要给孩子喂奶换尿布。如果我直接给他提供帮助，一是把他的活给干了，更有可能把他的权力抢了。到时候，我不开心，因为我做了下属应该做的东西。而他也可能不开心，因为在没有得到他允许的情况下，就占了他的位置。倘若他主动提出要求让我帮他，那么就不存在抢位置的问题。其次也可以增进两人的联系。他知道老板愿意帮忙而不是单纯的给他下命令。

战略：如果这个行，那什么不行？

当你的队员超负荷运转，却还在接受新任务的时候，你要问一下，这个可以接受，什么要拒绝？这个问题的威力是

• 你真正承诺的是什么？
• 把你必须舍弃的东西找出来，这些舍弃的东西可以让你专注在你的承诺上面

战略是一个被人滥用的词，当你所有的项目都是战略性项目的时候，意味着项目没有重点。战略的本质是在承认我们精力和资源有限的时候，接受什么，放弃什么。放弃是为了更好的接受。

当你的上级给你加项目的时候，最好用的回答是积极的说出不。所谓积极就是，这个我当然可以做，可是这样恐怕得耽误另外一个事。如此一来，你们便进入了战略性谈话。

学习：什么对你最有用？

学习最大的敌人是遗忘，而这个问题一是可以打断遗忘的进程，二是让对方去回看自己学过的东西，主动的思考，才能把知识真正的变成自己的。为什么这个问题有用？

• 谈话结束的时候，用最后的篇幅问一个一个学习的问题，可以增强双方对整个交谈有用的好感，因为人们往往注意的是结尾，这个结尾的影响力，要比过程重要。
• 帮助大家找到最有用的带走
• 使他个人化，面前的这个人他却学到了什么
• 给你反馈，让你知道对方真正接受到的信息
• 培养学习氛围，让对方知道这是在学习，而不是批判，是开放式的
• 长期以来，坚持不懈的问这个问题，让你成为一个有用的人

到最后你可能会疑惑，作为管理者，我只问了问题，我是一个有用的管理者吗？

如果不管对方水平如何，也不管对方所处的情景，我劈头盖脸的就是问问题，那么我不是一个好管理者。但如果我能根据情况，真心的出于好奇问出问题，之后用一连串的的问题去引导对方思考，最后知道如何停下来，那么我就是一个优秀的管理者，不仅没有把自己搞枯萎，而且让队员们绽放！

在你离开之前，这篇文章对你最有用的是什么？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

分出已知和未知

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

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

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

拿出替代方案减少未知

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

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

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

提早探索下个未知

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

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

迭代未知

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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