编辑导语：在高度分工，密切协同的组织内，虚线管理是组织设计中不可或缺的一部分，它符合这个层级的团体的做事逻辑，利用好它能够提升团队的专业度，有利于组织的成长。但合理的设计体系对于虚线管理的建设有着重要的作用。本文就虚线管理的作用和设计逻辑以及如何应对其尴尬处境进行分析，一起来看下。
继上一篇文章《是分是合？探讨影响研发组织设计的主要因素》之后，我们再探讨一下研发体系中的虚线管理的话题，先从一件有意思的事情说起吧。
前段时间我有一个同学找我，说碰到了一件工作上的事情，让我帮着拿拿主意。为了简单的的把这个事情讲清楚，我做了一个图辅助一下。
我同学Mr.Y是某公司研发中心下的一个部门经理，下面有个项目组，做了一次项目迭代，整体效果很不好，bug率、NG率都很高，上线后问题依然不少。他想采取惩治措施，整个团队绩效扣10%，团队特别有问题的扣30%。
但是，当他复盘整个项目的时候，觉得管理的问题最大。什么问题呢？其中，前端问题最严重 ，bug率和ng都是前端出现的，就是他所说的要扣30%的问题团队，但是因为自己的前端Mr.AF有事不能参与，前端开发人员Mr.BF是临时从另外一个部门调过来，最开始Mr.BF是非常不愿意参与这个项目的，是被负责前端开发的职能负责人Mr.F硬派过来的，前期的项目风险也是大家一起沟通过，需要Mr.F一起协助控制的。
Mr.Y和Mr.F就绩效问题沟通，Mr.F说如果真要扣Mr.BF30%的绩效，他也不能阻拦，但是这个项目本来不是Mr.BF的职责范围，属于过来救急的，如果这么处罚，Mr.BF有意见是其次，后面再协调别人参与到Mr.Y的项目难度很大，也就是说没人愿意参与部门A的项目了。同学Mr.Y很纠结，按照实际工作效果应该重罚，但考虑其他因素好像重罚又不妥，问老谭该怎么办？
我相信这个问题绝对不是个例，这在我们工作中还是经常会碰到的，是选择铁面无私，秉公执法，还是做个老好人，自认倒霉呢？
其实，分析这个事情还是先从绩效的作用开始。绩效考核的目的到底是什么？绩效考核的目的是为了企业和员工的共同进步，为了更有效的完成组织发展的目标。绩效考核是面向过去，当下发生的行为。但绩效的作用是面向未来所产生的影响。
回到这个案例，如果Mr.BF是自己Team的同事，重罚是应该的，警告一次长长记性，未来争取避免少犯错误，把工作做好。但现在对于Mr.Y来说，和Mr.BF合作关系是临时性的。对于Mr.F来说，Mr.BF虽然长期接受Mr.F的管理，但仅局限于专业能力这条线上的。
这样不留情面的处罚，绩效的影响好像对他俩都没什么好处，Mr.Y增加了获取资源的难度，Mr.F增加了职能管理的难度，损失明显大于获利。所以答案也就显而易见的了（最终同学选择了和大家一视同仁的处罚，并对绩效做了沟通，既表达了对工作的不满，又保留了一定人情，不影响后面的合作）。
一、为什么需要虚线管理？我们今年也实行了多线考核的模式，但我也发现了这样有趣的现象，往往不是直属领导反而打的分数越高。为什么会有这样的情况发生？但多线考核和虚线管理虽然有一定关系，但并非一个概念，考核是我对这事有评价权，但管理更多的承担着一种团队责任。
虽然说虚线管理没有直线管理那么直接，约束力和控制力更强，但缺少虚线管理又几乎是不可能的，特别对于我们这种对团队协作要求很高，技能高度细分的研发岗位来说，没有虚线组织和管理，其运行效率和成本就是很难平衡的。
以纯直线管理的研发组织为例，一般情况下我们要么是按照职能、专业来划分（如左侧职能式组织结构），或者按照做的事情来分（项目式组织结构），当项目或组织变得很大或需要广泛的跨部门运作时，第一种单一的职能式的管理模式是难于协调的。而项目式的组织架构人和事有了对应关系，但这个组织架构的问题是忽略了不同岗位的专业细分，同时项目因为有其生命周期而让组织变得极其不稳定。
管理主要就是管人和管事，是管人重要还是管事重要，这个很难有定论，因为事是人做的，人是做事的。很多企业现在实行实线和虚线双线管理模式，既要保证业务执行，又突出专业职能的作用。
二、研发体系的虚线管理逻辑既然职能式的管理结构使得协作变得困难，而项目制的管理结构又让组织变得极不稳定，那么将二者融为一体，各取所长，一虚一实就很好的解决了这个问题。
第一种设计逻辑：通过职能部门实现人力资源管理，通过项目小组实现虚线管理。
对于小规模的公司或者项目型的公司，项目管理制是一种极佳的组织形式。职能部门作为实线管理，肩负培养专业化人才，输送人才，人才晋升的职责。而作为虚线管理的项目组，只需要以项目目标为核心，通过项目管理的制度流程对参与到项目中的人进行协作、绩效考核，而不用过度参与到管人的事务中。
这种管理模式不论对于职能部门来说还是对于项目组来说都有一定的抓手，对团队成员有一定的约束力。但是项目经理虽然是项目的老大，但他并没有人事权，相对职能部门对于人员约束就弱一些。当一个项目变成一个长期的固化的业务时，此时也可以把实线关系和虚线关系调换，一般情况下，业务部门是直线管理，而职能部门则为虚线管理。也就是说，业务部门中的相关职能首先向业务单元经理汇报(“实线”)，再向公司职能部门汇报（“虚线”）。
第二种设计逻辑：实线是以业务为核心，具有共同的绩效目标；而虚线是以职能为核心，实行专业化的辅导。
当然第一种设计逻辑是以稳定的业务形态为基础的，各业务之间有着明显的边界，或者相对比较独立。以研发为例，事业部的研发更多的是为了其业务目标而形成的敏捷的研发前台组织，而总部的研发更多以中台研发以及创新产品研发为主，这种组织形式更多出现在强调业务敏捷的互联网公司。
事业部组织具备研发职能后，研发中心的定位就非常的尴尬，最终可能导致研发中心除了输送人才，做一些基础平台的开发外，没有其他的研发工作。另外，研发资源被固化到业务组织内，资源的协调和相互间的复用就变得极其困难，控制不好就会存在大量的重复开发造成资源的浪费。
第三种设计逻辑：IPD（集成产品开发)模式，它使用重度矩阵式的管理结构，以职能部门作为实线管理，以产品开发团队作为虚线管理，但产品开发团队具备绝对的管理权限和绩效权重。
IPD模式强调产品团队Leader和成员有项目权力和责任，职能部门经理（资源经理）关注于建立优秀的部门，而不是日常的决策。IPD看似是项目制组织模式的一种升级，其实PDT比项目组拥有更多的自主权和决策权，PDT的每个人代表着自己的职能部门并能自主决策，产品线可以快速的组建并调配资源，当产品验证失败或者进入生命周期末期，又很容易解散*，因为每个人所在的职能部门是稳定不变的，不会让PDT的人员缺少归属感，它更加适合具有高度市场导向创新的产品研发型的企业。
同时IPD的模式也更加适合那种需要广泛复用技术能力、产品模块、业务组件的产品体系，就像造车一样，不论是宝马3系还是宝马5系，产品的创新不可能从每个零部件开始。
如果组织有高度复用的需求，事业部的模式就很难实现，而IPD的模式可能就相对容易。当然也可以采用事业部和IPD混合的模式，事业部作为PDT的发起者，把和自己相对独立相关的事务装在一起保证敏捷，将那些需要组织内共享的部分作为总部职能部门进行协同。
说到复用，我前段时间写的《啥都复用不了，还谈什么狗屁中台！》的文章火了，十几家媒体转载，还被人人产品经理社区评选为本年度热文。在这篇文章中，我也提到了组织设计对于复用的影响。在IPD模式下，实线组织负责复用；在事业部体系中，虚线管理负责复用。
三、虚线管理的尴尬如何解？曾经有同事特别抵触虚线管理，认为做好了功劳不是自己的，做不好擦屁股的活都是自己的，何必呢！这种观念越往基层越普遍，因为从执行的角度来看，责任越清晰、事情越单一执行效率越高！但这也从一定程度上反应了虚线管理的尴尬：
- 没有人事权，无法形成太强的约束，缺少管理的抓手；
- 如果给对方带来好处还好，如果管理工作和他直线工作冲突，可能会被轻视和无视；
- 职责边界如果界定不清晰，容易和直线管理产生冲突；
- 好事不找你，总是在问题出现的时候来刷存在感，虚线管理往往缺乏成就感。
为了保证虚线管理的有效性，发挥其完善组织职能的作用，化解虚线管理的各种尴尬，这就需要合理的设计并建立起制度进行保障，总体思路如下：
- 根据自己业务的形态和发展的阶段，选择合适的组织架构模式；
- 管理必须有抓手，要么管人要么管事（如果像刚开头Mr.F那种既不管人也不管事，只是专业指导，其地位就很尴尬）；
- 团队内要明确直线和虚线，明确直线和虚线的管理边界，上下级之间要达成共识（很多人都不知道自己还有个虚线上下级，工作内容也不清楚，这就很尴尬）；
- 虚线管理需要更高的职位级别以及领导力的保障，其效果才能保障（为什么很多公司搞中台架构搞不下去，没有一把手在顶层的强大推力，这个虚拟组织及管理很容易被架空!平行组织之间的虚线管理是相对弱势的，虚线领导也无积极性可言！）；
- 绩效权重不看实线和虚线，更重要是以哪个为核心目标就分配更多的绩效比例（比如在IPD模式下，PDT虽然是虚线管理，但其绩效权重应该是非常高的）。
- 对虚线管理设置有效的激励手段，让其感觉做的事情有意义，或者对自己的发展有帮助，丢掉虚线管理就是背锅侠的错误意识。
总结一下，虚线管理是组织设计中不可缺少的，特别在研发这种高度分工，密切协同的组织内，它符合专业的人做专业的事的逻辑，通过主线之外设置多种辅线来完善团队的职能，提升团队的专业度，有利于组织的成长。但虚线管理往往缺少有效的抓手，把握不好，可能就出力不出成绩，最终让虚线管理形同虚设，没有发挥应有的职能。
所以合理的设计组织，建立起有效的制度体系，对于虚线管理设计有效的激励制度和发展通道，获得组织认可，才能让虚线管理更有效力。
#专栏作家#
菜根老谭，*CGLT_TAN，人人都是产品经理专栏作家。经历程序员、技术Leader、产品经理、研发Leader等多种岗位。现负责某科技公司整体产品研发，擅长企业IT架构及互联网产品架构。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
