你好，我是箴亚管理顾问公司负责人，同时也是 TGO 鲲鹏会台北分会学习委员游舒帆，今天想跟大家分享的话题是“高效研发流程的第一步，打造高效的研发组织架构”。

要谈高效研发流程这回事，首先我想先跟大家聊聊高效这词，我对高效的定义是：更快的将事情做对、做好。也就是说产出要快，内容要对，而且质量要好，又快、又好、又有价值才符合我对高效的期待。

“快”，在互联网时代，通常强调的是应变得快、调整得快，这与组织架构、分工，以及决策过程有关。“好”，就是交付的质量，说得出做得到，总是能交付出可预期的成果，这与软件工程的成熟度有关。“有价值”，则是源自于方向与优先级正确，这与企业战略与目标设定有关。

因此，谈高效研发流程，我们便不能只谈研发流程本身，必须将视野拉到外部环境、企业战略与组织架构等层面来思考。

两种最高效的场景

在我过去接触过的千千百百种流程里，其中有两类场景是最高效的：

第一类，制造业的生产线。 每个关卡、每个环节都被精密计算，关卡与关卡间毋须沟通，也甚少出现停顿等待前一个关卡的状况。各关卡只需要负责完成它所负责的那项任务，内容的变化性极少，突发状况也几乎都被控制，成果的可预测性极高，可以大规模、重复的产出相同的成品。

第二类，全栈型员工。 毋须分工，毋须沟通，可以自己一个人从厘清需求、设计架构，到编写前后端代码，同时搞定测试与布署等所有事情。少了沟通这个环节，他不用分心向其他人说明自己的想法，不会有冲突，也不用相依于其他人的工作，这种状况下，工作能不高效吗？

然而，这两种场景都有很大的局限性，第一类场景无法很有效的应对高变化性的环境与需求，即便在如今智能制造的环境下，多样少量的按需生产仍有极高的局限性，想当然也很难适用于现今多变的软件与互联网环境。

第二类场景的局限性则在以下两点：第一，生产力有限，面对较大规模的工作量时，团队分工显然会更高效；第二，专业性问题，全栈型员工并不意味着所有的技能点都点满。

从上述两种极端的案例中，我们可以先了解到一个最基本的观念，那就是“流程高效的前提是对应了适当的场景，而场景，则源自于我们所面对的挑战以及所发展出来的战略与组织架构”，这与我们开头提到的又好又快相互呼应。

四种企业组织架构

前面一段我们提到了两类高效的场景，第一类是高度确定性场景，第二类则是高度不确定性场景。这个部分我将跟大家简单分享一下我经历过的几种主要的场景，以及对应的战略与组织架构。

大家可以先透过以下这张汇整表对这几类组织结构有个基本认识：

1. 功能型

讲究专业分工，基本上制造业或传统产业，大多仍沿用这种组织架构，因其所面对的环境变化性小，流程与技术的变化性也相对较小，在稳定状况下，明确的分工有助于效率的提升。

2. 产品型

又称 BU(Business Unit) 型，通常是为了快速抢占市场而组成的团队。功能型组织分工明确，但容易形成谷仓效应，彼此各自为政，不利于战略的快速推进。如果企业资金充裕，且追求快速推进，一般会让各产品线或 BU 自建销售、营销、服务等相关功能部门，并且各自进行管理，所有功能的主管权集于一人身上，决策相对高效。当然了，对应的或许是资源的重复投入问题。

3. 混合型

一家经营 5 年以上的企业，一般会具有多个产品或事业。某个产品 A 已经相对成熟，对变化的可预期性提高，此时可能会从产品型组织转换成功能型组织；而另外有个产品 B 则尚在起步阶段，仍须快速推进，产品型组织就相对适合。这种状况下便会出现功能型与产品型组织并存在企业内的状况，就我过去的经验，大多数的大型企业最终都会走向这种型态。

4. 战斗小组

当你面对极端不确定的环境，例如全新市场、新科技早期的技术探索等，组织过大的产品型团队一来成本高，二来效率也会受到限制。此时，最佳的解法通常是派出 2-3 人组成战斗小组，在这个团队中所有人都是多能工，每个人都能同时处理多个职能的工作，如同初创团队一般，小而全的高效运作。

以创业团队来说，刚起步时大多都是创始团队组成战斗小组，随着市场需求的厘清与扩张，会逐渐转为产品型，然后随着分工愈来愈清晰，制度愈来愈完善，会步入功能型，等开始切入第二个产品或事业时，就会变成混合型组织。

企业组织架构与研发组织架构如何高效匹配

前一段我们谈到了企业组织架构，这个段落我将分享研发组织架构如何与企业组织架构高效匹配。

企业在草创初期，走的大多是战斗小组模式，研发在此时还没有形成一个独立编制。但随着企业日渐成长，公司规模成长到百人规模，业务、营销、服务都成立了独立部门，研发团队也来到 20-30 人的规模，为了有效的管理与确保研发资源的最有效运用，研发通常也会被独立成一个部门，而企业内，也会自然的走向单一产品型或功能型组织。

1. 集中式的研发团队

习惯上我会称这个阶段为集中式的研发团队，这一时期基本的运作模式如下图，各部门对研发部门提出需求，研发部门则依循一套机制来排序所有部门的需求，并且按照谈定的顺序进行开发工作。

然而，企业在此时仍在追求快速成长，因此销售与营销的需求往往会优先被考虑，而服务与后勤的需求，以及研发团队针对产品或技术架构优化的需求，则往往被滞后。需求顺序会偏重支持短期的营收增长，而客户服务与产品优化等长期项目则严重被忽略。

2. 分布式的研发团队

有鉴于集中式研发团队的问题，许多企业会在此时选择扩张或重整研发团队，将一部分的研发资源放在处理各功能部门的短期性需求上，我习惯称这样的团队为功能部门研发团队；另一部分研发资源则专注于产品与技术的持续进步上，这个团队我则习惯维持研发团队这个称呼。

经过调整后，各功能部门都将拥有一个属于自己的小规模研发团队，所有的需求都可以先提交给这个团队。若需求本身较紧急，且规模较小、复杂度较低，那就由这个团队直接处理，若判断后认定为长期需求，则将需求 pass 给研发团队来评估与开发。

这样的组织架构，虽然可以同时兼顾长期与短期的需求，但那些被分配在功能部门的研发成员们则难免会有所怨言，会认为自己所做的事没有太高的技术含量，更多的是例行庶务与简单的编程工作，时间久了便会失去工作热情。我们曾经尝试过轮岗，让成员能在各团队间轮替，但在几次实践之后，发现这样的做法成效并不好。

因为所有人都倾向于做那些看起来价值更高的事，如果技术领导者在做组织分工时，已经先排出团队价值的高低，那被分派到低价值团队的成员，自然会觉得自己的工作价值不高，会觉得自己不被重视，团队的向心力、热情与使命感都会大幅降低。

为了有效的解决这个问题，我们又尝试了第三种组织架构——矩阵式研发团队。

3. 矩阵式研发团队

矩阵式组织架构最主要的特色在于，重新定义了之前提到的功能部门研发团队的角色。过去，我们指派给这个团队的任务是支持功能部门排除问题与开发短期需求，现在，我们则把各个功能部门定义成一个个独立的产品，每个产品都有单独的产品经理负责，而这个产品经理的核心任务就与各功能部门的产出直接挂钩。

例如，销售系统被定义成一个独立的产品，它拥有自己的销售 PM，目标就是让销售部门达成所有 KPI，可能是业绩、退货率、客单价提升等。

当角色从消极的支持转为积极的负责后，团队的定位就更加清晰且重要了。

此外，推动矩阵式组织的另一个观点是，产品经理可以通过改善产品，或通过运营的手法来促使业绩达成比如 30% 的增长，然而产品经理始终是产品专长，对于销售、营销、服务的理解并不见得非常深入，因此，如果能在销售、营销、服务等岗位上也设立产品经理的职务，肯定能对增长带来重大效益。

举例来说，如果销售 PM 能通过技术带来 30% 的销售效率提升，就能一次性让多个产品同时受惠；如果服务 PM 能通过技术更个性化的服务顾客，有效的降低了比如 15% 的退换货，也有机会让数个产品都得到提升。过去经验里，这些 PM 本身都熟稔技术与业务知识，能同时从两方思考系统问题，所提出的解决方案往往会比纯技术 PM 或纯业务 PM 来得更加到位。

从这个角度来思考，功能部门研发团队的重要性便明显提高了，他们能直接为公司的效益带来贡献，团队成员们有了相对清晰的目标，使命感与热情便有了非常明显的提升。

本文跟大家讨论了较多关于场景与组织架构的内容，往下几篇，我将分别与各位聊聊关于研发流程管理的选型、研发管理过程中的那些坑，以及如何打造追求更快、更好、更有价值的组织文化与人才梯队。

很高兴能与大家交流关于高效研发流程这个话题，咱们明天见。