研发Leader成长手册

原文地址：研发leader成长手册（一）转载，研发Leader成长手册（二）转载，研发Leader成长手册（三）转载

近来和一些担任研发leader的同事和朋友交流中，发现部分同学，在研发leader的岗位工作上遇到了瓶颈。具体的问题，有个人发展空间上的，有工作内容上的，有时间精力安排的，有对外合作配合的，笔者仅以自己过去的经历和对leader工作的理解，分享一下对成为一个成功的研发leader的视角、观点。

研发leader的工作内容，可以分为以下几个方向：

技术方向工作
规划方向工作（目标、计划、执行、制度等）
协调方向工作（跨部门沟通、跨部门项目协作）
团队方向工作（招聘、培养、沟通、团建、宣传等）

在这几个方向上，分4个主题，逐个来分析、探讨。这4点交融在leader的工作中，因此每个方向探讨时，会有互相交叉的部分。

技术方向篇

在技术工作方向上，容易出现的三个误区：

A. 技术leader是团队的产出核心，其他人辅助工作
B. “我”是做技术的，产品、运营做的好不好，不关我事
C. “他们”技术不行，培养太花时间，等他们做完，我早做完了

下面我们来刨析这三个误区，看看这么做leader工作会带来什么问题。

01.技术leader是团队的产出核心，其他人辅助工作

作为研发团队的leader，首先要做好技术方向的工作，这是这个岗位的最基本职责；大部分研发团队的leader，都是因为技术工作做的比较好，而被提拔为leader，给予晋升空间和发展空间。但是技术leader的职责不仅仅是技术方向的工作，还要承接更多的岗位职责，大部分leader感到工作瓶颈，都是在非技术工作上面。

在技术方向的工作职责之外，其他的职责，是初晋升研发leader所不了解、不擅长的，此时如果没有得到很好的帮助或自己思考想清楚，工作便会出现一个迷茫期，不仅影响自己的发展，也影响团队的整体产出。笔者也未幸免，曾经在非技术方面折腾过一段时间，深为苦恼，甚至怀疑自己是不是应该回去做技术专家，而不是去带技术团队。

我从这个坑里爬出来，最直接、最重要的一个因素，是意识到了研发leader的岗位职责变化。研发Leader的岗位职责是要看团队整体的产出效率，而不是看个人的产出效率。作为曾经的研发好手，在技术问题攻关、代码编写质量、速度方面，是自己的长项，晋升leader也是因为这些方面的强项，被公司、上级所认可。这会给晋升的leader们一种错觉，技术能力和项目产出是自己的主要贡献。

在这种“leader观”下，会不幸的形成以自己为技术中心、其他团队成员协助工作的模式；项目里最难、最重要的部分，由leader攻关、实施；leader成为团队最忙、负载最大的同学。这种情况在早期阶段，依然可以运转一段时间，但是随着时间的推移，因为leader其它工作职责的加入，把leader已经被技术工作占满的时间、精力，轻易的给“引爆”。

团队成员遇到了工作的问题、招聘面试量的增加、和PM沟通讨论产品方案、和业务方开会讨论需求、开展晋升绩效的沟通、团队工作汇报的准备等等，会迅速的开始消耗leader的时间精力，使得leader主导的技术攻关、项目攻关，出现延期、失败，而团队其他人由于技术能力问题、分工安排问题，不能有效支持项目推进。此时，Leader不得不面对这个现状，为了摆脱这个“陷阱”，做出选择。

A. 拒绝技术工作外的管理工作，来保障技术工作的完成；
B. 投入时间做好管理工作，但技术工作陷入混乱；
C. 对管理工作敷衍，依然把主要精力放在技术工作上，保障技术工作的完成。

笔者当年走过由A到C，再到B的过程，所以在今天的工作里，对团队里的技术leader，非常能够理解他们遇到的工作上的问题。下面我说一下我自己的经历。

刚开始，我对自己被提拔为技术leader非常兴奋。作为一个疯狂的技术爱好者，这种晋升，我认为是对技术能力和产出的一个认可，非常有成就感。我把这次晋升，当成了一个奖励，丝毫没有意识到随岗位的变化，我的职责也变了（当然也没有人真正严肃的对我说，我的职责变了，要求的能力模型变了）。也丝毫没有意识到，除了技术能力，其他方面我都没有达到一个leader的能力要求，处于“不知道自己不知道”的状态。于是更以加倍的热情，投入到开发工作里，绝大部分时间都是在做开发，少部分时间分下任务给团队其他人。

由于是团队leader，HR开始安排更多的面试工作，自己部门的、其他部门的，在面试工作的时间上，基本增加了一倍以上；项目经理、客户（内部需求方和外部客户）开始找我沟通项目的安排、进度，会议的量开始增加…… 是的，各位leader今天遇到的问题，我也没意外的遇到了。我热爱技术工作，我是技术极客，干嘛让我把时间花到这些“虚”（不是写代码，都是虚的）的事情上呢？I reject！

但是拒绝不了多久，就被我的老板谈话了。这些事我不参加、不做，对应的伙伴们，自然就要找我的老板投诉了。当然这也不难沟通，作为leader那些事是要做的，只是我不喜欢，那如果还要做leader的话，就得改变自己啊！价值观是杠杠的，调整自己认真对待技术以外应该承担的工作。但是我的精力客观上是有限的，白天用了40%-50%的时间在这些问题上，技术工作就只能继续用自己的夜晚时间来补充。熬夜到12点后，成为一个常态。【曾经有一回，在公司加班到1点，开车回家的路上，我睡着了…着了…了，以60KMPH的速度，撞在了前面一辆现代SUV上，还好相对速度不那么大，车损人未损。阿弥陀佛，如果不撞上这辆车，我撞上的，将是50米前方的两个水泥路障，当时在施工建设地铁，阿弥陀佛，救命之恩！】

好吧，知道不能这么下去了，我在认认真真的想，我是不是该回去做程序员？我是不是根本就不适合做管理？ 在这种不坚定、不明确的状态下，对非技术类的工作，进入一种敷衍的状态，开会时经常两个耳朵听着，两只手在看着屏幕敲代码…… 不知道当时的同事们有多想骂我，在此对你们说声sorry！然而我一直没有下定决心往回撤。因为人都要上进，没干好的情况下往回撤退，我岂不是懦夫。隐隐的感觉到，我自己遇到了“瓶颈”，我需要突破自己。也就是说，进入了“知道自己不知道”的状态。

转机出现在一次去广州出差的路上，在机场买了一本《领导阶梯》，完全是偶然的在机场买了一本。里面明确说明了一点，作为首次晋升的leader，根本的转变，是我从个人贡献者，转变为一个管理者。两者的差异，在于职责上，Leader要对团队的结果负责，而不是对Leader自己在其中的比例负责。进一步，我做了以下的思考。

假如我们团队有6个人，我个人超强，一个人贡献团队40%的产出；其他人平均每人贡献12%的产出（合计算100%）；假如我通过管理工作，让团队的外部环境井然有序、任务明确，并致力于指导、提高团队成员的能力，让每个人的产出，提升一倍，我自己的个人贡献因精力转移降低60%，降到16%；此时我们相对以前，整体的产出是（16% + 24%*5）= 136%。这样，我做为leader的杠杆效用，就出现了：通过我的工作，团队的整体产出增加了。

懂得这个逻辑无比的重要，能让自己下定决心转型，做好外部工作，做好内部指导、培养工作，通过自己的工作提高团队的整体产出，给团队每个人带来成长。对leader的考核，应该是团队的整体产出情况，而不是leader个人做了那些具体的事。

因此，技术leader在技术工作上，应该把精力转移到那些体现leader价值、高杠杆率的事情上。包括：

和产品经理或项目经理沟通、明确项目需求，让团队的技术工作不乱
系统架构设计、核心算法设计、主要性能攻关
提高团队成员能力、引进合适人才

02. “我”是做技术的，产品、运营做的好不好，不关我事

这个观点虽然我们一看就知道不合价值观，但是在实际的工作里，却是一个挺常见的现象。作为技术leader，保障在技术上把产品、运营的需求，用代码给做出来，变成产品、服务。

一般来说，我们都清楚产品经理对自己的产品目标负责、运营经理对自己的运营方案效果负责；那么作为研发的负责人，我们可以独身于事外、对产品和服务的实际结果，不加关注嘛？

很抱歉的说一句，笔者也曾经有过这样的思维。我负责技术团队，确保技术团队的战斗力，把交给我们实施的需求，都给实现了，就起到了研发这个环节的责任、体现了研发的价值。直到有一次和高德的总裁董振宁先生请教，他对我说：从公司角度看，无论是做技术的、产品的还是做管理的，负责人们都是业务干部，业务做没做好，是考核干部合不合格的标准。

一席话激起千重浪，深刻的击中我自己的认知盲点。对于干部，公司的期望是完成业务目标，拿到业务结果；我们不能在业务结果不好的情况下，说我们产品设计是没问题的、我们开发交付是没问题的，这不叫责权明确，对于干部来讲，这叫甩锅，而且锅只能是给老板来接。

03.“他们”技术不行，培养太花时间，等他们做完，我早做完了

我不知道有多少leader们，有没有心里想过、嘴里说过这句话。笔者心里想过，嘴里没有说过。作为因技术能力强、技术产出高而在team里被提拔起来的人，有实力说这句话。客观的实际工作里，也有这样的情况，我们要不要自己动手，取代团队成员应该完成的工作？

我认为是不行的。

首先，精力是不允许的。Leader还有很多其他方向的工作，在写代码这个非常耗时间精力的事情上投入，会严重影响其他工作的展开。一个团队，如果leader不能打理好内外环境，很快就会进入效率降低的阶段。取代他们的职责，是拆东墙补西墙，团队整体的产出依然下降。

其次，对成员的发展不利。遇到困难不能克服，就让leader来做，那成员是很难成长起来的。我们的成长，70%来自于工作。遇到困难时，也是他们成长的最好机会。此时做为leader，应该是花时间帮助他，指导他。这也花时间，但是和直接自己取代来做不一样的，团队成员的能力会因此提高，给将来团队的整体实力、产出提高打下了伏笔。这样既推动了项目的完成进度，也提高了团队的成长。

笔者曾经经历过这个阶段，当时公司成本控制，招聘的同学的技术能力在行业里偏低，水平一般。大部分的工作也是我在做。后来我改变了策略，不管如何，把任务分给他们，约定完成时间。到项目周期的1/3时，我会review下所有人工作的进展情况，分情况进行不同处理：

A. 进展符合预期，不管他了，让他继续往前做。
B. 进展高于预期50%以内，给予指导，在这个项目上，给他建议，提高效率。
C. 进展低于预期50%以内，拿过来我做，追赶上项目工期。

真正落到C选项的，实际很少，大部分在A和B里分流了。对于A种情况，对应的工程师会给予更多的项目和职责，快速成长起来；对于B种情况，对应的工程师能够有效得到帮助，能实实在在的提高自己的工作水平；对于C情况，如果不能带起来，就只能优化了。

最后，如果用这样的思维思考，团队内的氛围会比较差。成员不能承接自己本应该承接的工作，得不到成长锻炼的机会，没有有效的产出，会很容易产生不安全感；人在不安全感的情况下，容易会去互相推脱责任，互相指责、力求自保，诉求最基础的“我没错”的安全需要。

这种氛围下，团队就带散了，有能力的人会离职、转岗，没能力的人会力求不犯错，做为leader的老板，不得不出来解决这个团队的稳定性问题。还好，笔者没有这么干过：）

综上所述，我给研发leader们三个建议：

在技术工作上，当退则退，保持30%的精力，在某个技术方向上做深，利用业余时间提高技术广度。保持技术深度和广度的同时，留出精力去做管理性的工作。充分挖掘团队资源，去完成团队任务。
作为技术leader，身在技术，心在业务，始终站在业务成功的角度思考问题。
为团队培养人才、引进人才，优化不合适的人才；是团队建设永远正确的真理。

规划方向篇

规划这个词，对很多leader来说，是个伟大而又玄乎的词，经常的会听到“咱们先做个规划”、“年度规划”、“季度规划”，规划是个啥东西，怎么做对？怎么做好？

不过有一个好消息是，在整体公司组织中，作为技术团队leader角色时，是执行角色；技术团队leader主要是承接部门经理或总监安排的任务，体现执行方面的能力和效率，还不需要做高大上的“规划”。

那读者可能要问，既然如此，这篇文章你写个啥？笔者想说，虽然不需要做规划，但是总得有能力理解上级做的规划，理解执行的任务来自什么。我们从这几个层面来看规划：

企业级规划
事业部级规划
职能部门规划（成本中心）、运营部门业务规划（利润中心）

我们分别来看一下，怎么来理解各层级的规划。

企业业务规划

企业的规划一般来自三个方向：

业务规划：业务规模、收入
人力规划：供给“人才”，实现收入的目标
财务规划：资金流、成本、利润

01. 业务规划

业务规划是指公司的业务规模收入方面的计划。贝壳在2019年，定下的目标是GMV达到2万亿【百度上能公开检索到，这不是泄漏公司机密哈】，当然还有其他指标，不过核心的是业务的GMV指标。商业企业是一个经济组织，其目标一定是商业目标，大白话就是钱；业务规模、增长率、开拓新市场等，无一不回归到商业利益上来。

在这里解释一下，企业的直接目标是商业利益，但长远目标和存在的意识，不是商业利益。企业的使命和愿景，是存在的意义和看得到的未来，一般不会是商业利益；贝壳的使命是有尊严的服务者和更美好的服务；贝壳的愿景是服务2亿家庭的品质居住平台。因使命和愿景，是一个公司更长久的意义，不是规划出来的，而是创始人的理想、企业社会责任和价值的表达。

企业级的业务规划，比较简单，一下就能看懂。如果企业的目标很长很难记，那对几万人的公司，就是个灾难。

02. 人力规划

人力规划，主要关注的是用什么样的人来完成业务收入。 人力规划和财务的规划是有关联的，因为财务需要控制预算，保障资金流健康。在合理的人力成本预算下，HR制定人力政策，和Leader们关联比较大的，是年度HC有多少、调薪幅度有多少、绩效考核方案怎么做。

郑云端先生曾说，HR的三板斧是：招聘、培训和激励；在规划上，基本也是围绕着这三个方面进行展开。通过招聘、培训和激励机制建设，来“供给”实现业务需要的人才。

03. 财务规划

在财务规划上，我认为最核心的是保障资金流稳定，其次是成本控制。 资金流是企业的血液，企业业务好好的、员工好好的，看似一切健康无比，血液不流动了，会瞬间倒下。我们知道的OFO、互联网金融的崩盘，主要都是资金流出了问题。

获得资金流的方法，主要是公司自身业务收入（造血能力）、融资、贷款，当然也有创始人的自有资金，笔者有个朋友，曾经卖了北京房子，作为创业资本。大部分的CFO，不是在找钱，就是在找钱的路上。

除了资金流保障、成本管理，近些年管理会计兴起，代表是全面预算，对业务规模收入进行测算、各类费用、成本、资金进行测算，通过预算分配资源，实现目标。

事业部级规划

事业部可以理解成一个不太完整的公司，一般情况下独立核算。事业部作为一个业务单元，一般在业务方面完全自主、人事和财务方面有一定的自主权。

01. 业务规划

事业部的业务规划，首先是对公司业务规划的拆解；一般拆解后，整体会超过公司的业务规划。事业部的业务规划，除了收入的目标外（比如南部战区目标XX亿GMV），还要有支持业务发展的中长期能力建设目标。

对于能力建设目标，举个例子，如贝壳效率工程的SaaS HR团队，承载支持加盟体系关于组织、人的信息化，通过把加盟商、经纪人等的信息化做准、做好了，才能和贝壳平台做更好的连接。这就是对业务的一个中长期能力建设，对未来业务目标的提升，起着长期而又重要的作用。

02. 人事规划

事业部在认识规划方面，首先是在企业人事规划的范畴类，不能违背企业的人事规划（偶尔出现事业部挑战规则，突破企业人事规划的现象也存在）。人事规划基本是在招聘、培训和激励三个方面。

在招聘上，事业部的人力HC预算，一定在企业规划之内。实际操作上，事业部负责人有很大的动力通过人力扩充，加速业务的增长。美团曾经经历过这样一个阶段，业务快速增长时，公司HR发现控不住事业部的人员规模。因为事业部的负责人也是集团的高管，有比较大的权限，突破HR政策。

在培训上，一般是成熟的组织比较重视，对应的培训预算、培训内容和培训方法也更完善。目前在我的工作经历中，贝壳当之无愧是最重视培训的一家。在贝壳一年多的时间里，我接受的培训是以前的一倍多。

在激励上，一般是制定公司的绩效管理办法，通过绩效考核，为优秀的人才提供更好的变动薪酬和晋升空间。另外，通过对运营的绩效规则的设定，激励运营方向的员工，获得公司期望的业务结果。

事业部的人事规划不细展开，因为事业部也不是我们技术leader工作的界面。

03. 财务规划

事业部的财务规划，相对做的比较细，对收入、成本要做比较准确的预测，编制收入预算，测试业务规模、收入； 并且按月进行滚动，按实际发生的业务规模、收入，进行预实对比，调整后继收入预算。

同时对费用预算、成本预算进行编制。费用预算和成本预算要看各个公司实际业务（生产的产品、提供的服务）的情况，发生的费用和成本类型大不一样。

事业部的财务规划，最后反应在三张表上：资产负债表、现金流量表、利润表。

技术团队规划

我们依然用“规划”这个高大上的词吧，技术团队主要在做执行工作，但执行工作来源于企业一层层的规划。

BTW，做C端业务和做B端业务，在公司的决策-执行上差异很大；做C端业务，公司一般很重视扁平化，让一线呼叫总部炮火支持，因为C端业务，对于一线员工，理解起来不那么困难，容易共情。而B端业务高度复杂，理解判断困难，一般从上到下的决策比较多。在B端公司，理解逐层的规划、决策的能力很重要。

01. 业务规划-任务转化

企业做业务规划，可能会有个大会宣讲；事业部的规划，可能事业部总经理也会内部进行宣贯；对于技术leader来说，这离自己要执行的任务，还是遥远。这种情况下，技术leader不能等待，而是主动出击，在任务还没有分配下来时，主动和自己的上级沟通，了解规划需要拆分成的任务，甚至参与拆分的过程，向前迈一步。

这样的好处，是技术leader避免了被动承接任务。人在被动接受时，总会带着怀疑和不解的。IT行业从来都很紧凑，当任务分发下来时，已经把上线日期都规划好了，没有太多的时间buffer，让技术leader了解前因后果；技术leader不能在内讲清楚上下文，技术团队就会沦陷为一个干活机器，终日忙碌中，知道自己干什么，不知道自己为什么而干，也不知清楚懂干的事有没有价值。这样的团队，怎么会有积极的氛围呢？怎么不回逐渐进入一种焦虑呢？

往前迈一步，参与规划到业务的转化过程，是我对技术leader的一个建议。这些拆解好的任务，就成了研发团队自己的“规划”。

02. 人力规划 – 丰富多彩

人力可能是公司出规章制度最多的一个部门，每一个规章制度，都影响着团队的运作。如考勤、招聘、调薪、晋升、绩效、等等。这在《团队工作方向》里进行展开，下面简单提下招聘和考勤两个重要的场景，本篇不再细述。

技术leader对于招聘工作务必上心，给自己的团队招聘优秀的人才，是leader一个很重要的职责（不是HR的职责），而且在人才选拔上，除了保持团队的梯队合理外，要敢于请进来专业能力比自己强的人。作为技术leader，走向管理岗位，就需要接受团队里专业比自己强的人存在，给他们发挥的空间。

在考勤上，由于从事技术工作的人不少是夜猫子，喜欢晚上安静的时候干活，平时加班也很多，我推崇“自由”的考勤制度。做技术工作，如果自驱能力不够好，很快产出就掉下去了。技术leader发现后，通过绩效管理、辅导的方式，能够有效应对。考勤“自由”，是对工程师的一种信任，当然如果违背信任，对应的惩罚代价也很大。

技术leader一定和自己接口的HR或HRBP，保持高频沟通，来保持团队在人事规章制度上，即使自己不知道，也有人来监督、提醒。

03. 财务规划

对于技术团队来说，财务规划一般就是要做好预算费用的编制和控制。 在技术团队，涉及的预算，一般包括：

行政办公设备预算
工具软件license预算
团建预算
差旅预算
测试机、短信通道、云服务等预算
其他

笔者初作预算时，头脑嗡嗡响，一是想不到有那么多预算项目，二是不知道怎么去做，设定多少预算额度合适。这主要是因为隔行如隔山，请教一下做过预算的前辈、自己耐心做几次就熟悉了。

综上，本文概要介绍了业务规划、人事规划、财务规划，帮助技术leader去理解公司的规划，进一步自己参与规划拆解为研发任务的过程，提供一定的知识基础。

协调方向篇

协调方向的工作非常广，涉及到方方面面，我们在公司的协作中，到底为什么这么难？不探究本质，是难以找到解决方案的。笔者认为，协调遇到的困难，本质的原因，是组织内天然存在的部门墙。本文从部门墙维度，来看部门的协作、项目协作的改进。此篇和技术团队Leader有关，但是其实延伸的更远，更多职业阶段，都受到协调工作的“苦难”；同时也探讨下，如何在工作里，利用部门墙，使之产生不一样、难以抗拒的价值。

01. 什么是部门（团队）墙？

给部门墙下一个定义，因多种因素产生的部门间不能有效协作的隐形障碍，并对公司整体目标达成产生伤害。部门墙可以归纳出以下几个主要诱因：

目标不同产生的部门墙
信息不透明产生的部门墙
观点不一致产生的部门墙
节奏（优先级）不一致而产生的部门墙
专业理解不一致而产生的部门墙
因主导权竞争而产生的部门墙

在复杂的中大型企业里，为了完成业务，制造产品或提供服务，需要不同能力、技能和专业的人，进行系统性的配合，才能完成。这些人才因业务不同而分开、因职责不同而分开、因地域不同而分开、或因管理规模切分而分开；形成不同的部门和团队组织。

每个团队自组建那一天起，他就是一个生命体，有自己的意志、灵魂，有自己的欲望、思想；有自己的新陈代谢，有自己的生老病死。每个team成员，都是其中的一个器官或细胞，只不过和我们所熟知的生命器官形态、功能并不一样。

在从事工作的18年后，我回忆了所有我工作过的团队、部门，很不幸的是，没有一个团队或部门，是没有部门墙的；在存续的生命周期里，都对外产生了协作的或大或小的问题。部门墙和企业文化无关、和员工素质无关，是企业多部门、多团队组织的自然存在。

02. 部门墙的典型事例

先看看因目标不同而产生的部门墙。举一个身边的例子，2019年技术部门启动了UC的重构项目，因这个系统发生过多起公司A级故障，非常影响公司业务的稳定开展；产品部门启动了HR体系数据治理，要把人事数据的准确率提高到99%；这两个目标对于公司，都是很有价值、有必要去完成的项目。

但是这两个目标产生了对产品资源和研发资源的竞争；UC的重构优化是需要产品经理的；人事数据治理也是需要技术的；双方对对方的资源投入都不满意，以至于投诉到了我这里。产生部门墙的后果也很严重，产品团队要把负责UC优化的PM给撤出来，减少对UC项目的支持；结果让两个团队之间剑拔弩张。

后来通过沟通，保障了一个全职的PM，来推进UC的重构、优化，同时研发团队优化资源调配，加大对数据治理项目的支持；最终两个项目，都完成了自己的目标。

下面看一个信息不透明产生的部门墙例子；我刚进一个公司，负责一块新业务时，研发团队刚刚组建（5个人），而此时产品已经有6个人了。这在我看来是有问题的，意味着产品要么做的设计没有资源实现，要么产品在非常低效的产出。我刚来负责这个部门，当向PM团队提出这个问题时，PM团队不愿意关于这个问题进行深入的沟通，只是反馈我们都很忙，工作量都很满。

这样的信息不透明，产生的结果是很负面的，后续的解决过程，几乎一直在对抗的负面状态；后来我思考这个问题，可能是因为我的比较重的技术背景，让PM团队不愿意接受我来lead，于是调整姿态，以逐个具体产品方案的review，来降低信息不透明的问题，通过3个月的持久努力，解决了产品和技术团队的配比问题。

这里再举一个节奏不一致导致的部门墙问题，去年我们启动了一个业财对接的项目；财务对这个业务的核算非常重视，因为业务规模比较大；而此时，业务部门的重心放在业务的规范和线上化上，也认同业务的核算是必须要做的，但是得先让业务系统跑顺起来。在持续了9个月的时间里，业财对接一直低效的推进，财务的数据规则、流程规范，在业务系统里得不到落地。这是典型的两个部门节奏不一致导致的部门墙，过程中也是非常痛苦，业务负责业财对接的团队，士气低迷；而财务同事，也非常泄气。

直到今年，业务系统把财务核算纳入到整体系统规范、标准化中来，提高了优先级，和财务部门的目标优先级相匹配，这个项目才有了起色。

这样的例子太多了，我想各位读者静思一下，能列出的实际例子，比我列举的更多、更丰富，有很多的因素，能够撞上“部门墙”，降低部门效率，扰乱团队的合作氛围。

03. 如何跨越部门墙

没有一个组织，不希望团队、部门间能够无间的协作；站在公司层面，都是公司的资源，有效的把资源转成公司的产出，才是公司这个组织所期许的。对于无处不在的部门墙，我们如何能够有效的跨越呢？笔者据自己的经验，列出以下几个方法：

个体主动放弃防御心理
在对外寻求合作时，务必提前把事情想清楚
在支持外部发起的合作时，务必努力去把信息接受全
站高一层，跳出当前部门，从更高的层面看协作

个体主动放弃防御心理

这对于职场里的每个人，都非常有价值。防御心理使得我们只想听那些我们想听的话，而错失其他信息的输入、曲解外界的信息输入。在对外的沟通中，不预设对方的态度、目的，以避免形成成见，以空杯心态迎接外界。这能够最大限度的让我们接受外面真实的信息，减少误判。

笔者在这方面，也踩过很多坑；无来由的怀疑对方的动机和目的，以至于在具体工作配合上，采取不信任、消极的态度。时而反思自己，方能减少这样的错误。

对外寻求合作时，把事情想清楚

合作从来都是难的事情，尤其在信任不足的场景下（如果有信任，那合作是很快能达成的，不需要检查那么多合作的预置条件），对此我们有必要把合作的目标、计划、资源、价值想的清楚了，去对外沟通。每个团队、部门都是繁忙的（大部分情况下），自己准备充分，是对别人的尊重，是获得支持的有效方法。

我们的技术部门和公司的基础架构平台有非常好的合作，去年我们把团队所有的公共技术组件资源，都转交到了基础架构平台，以响应公司的基础技术环境统一建设的号召。但是我们团队的技术人员，非常希望通过基础技术组件的建设，来提高自己的技术能力和视角。因此我们创新性的提出“合作共建”的方法，主动提出参与基础架构平台的系统建设，即为基础架构平台提供资源的支持，也为我们部门的技术发展、技术组件引进，提供了可能，对技术团队的稳定、成长，有很好的帮助。

在支持外部发起的合作时，务必努力去把信息接受全

在外界需要我们配合协作时，作为负责人，我们将最终要判断要不要合作、投入多大力度合作。这是一个决策机制，依赖信息准确、丰富。不仅仅对方把信息push过来，同时我们自己也要主动的去沟通获取重要信息，判断是否有价值做、是否有资源做。当然，既要根据信息做出正向支持的决策，也要做出负向支持的决策（不见得所有的协作都是有必要的）。

近期我们启动了一个项目，看似非常紧急，调动我们团队的工程师加班加点，一阵猛如虎的操作以后，发现这事情好像也没有这么重要；再回过头来Review时，确认是可以长线做的，不是异常紧急的项目。这是典型的一个信息没有完全接受，做出的一个决策结果。

建议可以结构化的对外接受信息，从以下几个方面主动获取信息：

清晰的目标价值（最好是数字表达的目标）
明确的进度计划
需要的资源投入
完成后如何评价项目价值（最好也是可衡量的数字化价值）

站高一层，跳出当前部门，从更高的层面看协作

最重要的事，一般放在最后讲。我认为这是跳出部门墙进行合作的最有效办法。在二维空间，部门墙是拦路虎，迂回到很远才能越过去；但是如果升维到三位空间，部门墙就是可以跳跃过去的。

站在跨越了部门的更高维度思考，可以让我们避开二维的“部门墙”思维陷阱，在更高的维度看，A和B同时在一个新的“组织”里，是内部的关系。

Leader如果具备更高维度的思考能力，或做这样的尝试（这是个难的事），对自己个人的提高、发展是大有裨益的。在外界看来，这个leader的格局很高，做事公正无私，跨部门合作也容易产生更有价值的成绩，实在是发展、晋升的必备良药。

04. 如何利用部门墙

既然部门墙如此客观的存在，那就没有利的一面嘛？凡事都有两面性，我们应当合理的利用部门墙。

首先，部门墙容易产生“领地”意识； 对于领地意识，是个有好有坏的典型。一方面，“领地”意识导致别人难以进入，提供更好的方案；另一方面，“领地”意识产生极强的责任心，很宝贵的责任心。 我承认我也是有“领地”意识的，效率工程是我们的“领地”，这里出现问题，责无旁贷，不需要公司push，我们就回去解决；而同时，也确实限制了其他部门对效率工程方面的贡献。

其次，部门墙使得决策延长、不靠谱的决策被挡住。 一个部门内的事情，可以很快、高效的决定，但是也不会有人来review；跨部门的协作，天然的就加了这样一道机制，让另一双眼睛来审视，决策是否正确、是否可以更好。

最后，部门墙让部门的不同意见、看法产生碰撞，如果能够因势利导，这样的碰撞也许能够碰触比原来不一样的思考、决策，甚至是创新。 部门之间的碰撞越大，说明分歧越大，分歧越大，为了弥补分歧，就要提出更好的方案，来覆盖多方的分歧。这岂不是创新的温床？

综上所述，部门墙的弊端，在技术Leader这一职业阶段，会比部门墙的利端更大；但是随着职业的发展，有效利用部门墙，会带来意想不到的价值。