技术领导力实战笔记_62_第49讲_|_打造高效的研发组织架构：高效研发流程那些事（一）
你好，我是珍亚管理顾问公司负责人，同时也是TGO鲲鹏会台北分会学习委员。
尤舒凡今天想跟大家分享的话题是高校研发流程的第一步，打造高效的研发组织架构。
要谈高校研发流程。
这回事儿。
首先我想先跟大家聊聊高校这词儿，我对高校的定义是更快的，将事情做对做好。
也就是说，产出要快，内容要对，而且质量要好，又快又好又有价值，才符合我对高校的期待。
快在互联网时代，通常强调的是应变得快调整得快。
这与组织架构、分工以及决策过程有关。
好，就是交付的质量，说得出做得到，总是能交付出可预期的成果。
这与软件工程的成熟度有关，有价值则是源自于方向与优先级正确。
这与企业战略与目标设定有关。
因此，谈高效研发流程，我们便不能只谈研发流程本身，必须将视野拉到外部环境、企业战略与组织架构等层面，来思考两种最高效的场景。
在我过去接触过的千千百百种流程里，其中有两类场景是最高效的。
第一类制造业的生产线，每个关卡每个环节都被精历计算，关卡与关卡间无需沟通，也甚少出现停顿。
等待前一个关卡的状况，各关卡只需要负责完成他所负责的那项任务，内容的变化性极少，突发状况也几乎都被控制，成果的可预测性极高，可以大规模重复的产出相同的成品。
第二类，全站型员工无需分工，无需沟通，可以自己一个人从理清需求、设计架构到编写前后段代码，同时搞定测试与部署等。
所有事情少了，沟通这个环节，它不用分心，向其他人说明自己的想法不会有冲突，也不用相依于其他人的工作。
这种状况下，工作能不高效吗？然而，这两种场景都有很大的局限性。
第一类场景无法很有效的应对高变化性的环境与需求。
即便在如今智能制造的环境下，多样少量的按需生产仍有极高的局限性，想当然也很难适用于现今多变的软件与互联网环境。
第二类场景的局限性则在以下两点。
第一，生产力有限，面对较大规模的工作量时，团队分工显然会更高效。
第二，专业性问题。
全站型员工并不意味着所有的技能点都点满。
从上述两种极端的案例中，我们可以先了解到一个最基本的概念，那就是流程高效的前提是对应了适当的场景。
而场景则源自于我们所面对的挑战，以及所发展出来的战略与组织架构。
这与我们开头提到的又好又快相互呼应。
四种企业组织架构。
前面一段我们提到的两类高效的场景，第一类是高度确定性场景，第二类则是高度不确定性场景。
这个部分我将跟大家简单分享一下我经历过的几种主要的场景，以及对应的战略与组织架构。
我在文中放了一张图，汇整了常见的四类组织结构，他们的优缺点以及适合的场景。
一、功能型讲究专业分工，基本上制造业或传统产业大多沿用这种组织架构。
因其所面对的环境变化性小，流程与技术的变化性也相对较小，在稳定状况下，明确的分工有助于效率的提升。
二、产品型又称BU型，通常是为了快速抢占市场而组成的团队。
功能型组织分工明确，但容易形成谷仓效应，彼此各自为政，不利于战略的快速推进。
如果企业资金充裕且追求快速推进，一般会让各产品线或BU自建、销售、营销服务等相关功能部门，并且各自进行管理，所有功能的主权集于一人身上，决策相对高效。
当然了，对应的或许是资源的重复投入问题。
三、混合型一家经营五年以上的企业，一般会具有多个产品或事业某个产品a已经相对成熟，对于变化的可预期性提高，此时可能会从产品型组织转换成功能型组织。
而另外有个产品b则尚在起步阶段，仍需快速推进，产品型组织就相对适合，这种状况下便会出现功能型与产品型组织，并存在企业内的状况。
就我过去的经验呢，大多数的大型企业最终都会走向这种形态。
四、战斗小组当你面对极端不确定的环境，例如全新市场、新科技、早期的技术探索等，组织过大的产品型团队一来成本高，二来效率也会受到牵制。
此时最佳的解法通常是派出两到三人组成战斗小组。
在这个团队中，所有人都是功能工，每个人都能同时处理多个职能的工作，如同初创团队一般小而全的高效运作。
以创业团队来说，刚起步时大多都是创业团队组成战斗小组，随着市场需求的理清与扩张，会逐渐转为产品型。
然后随着分工越来越清晰，制度越来越完善，会步入功能型，在开始切入第二个产品或事业时，就会变成混合型组织。
企业组织架构与研发组织架构如何高效匹配。
前一段呢，我们谈到了企业组织架构这个段落，我将分享研发组织架构如何与企业组织架构高效匹配。
企业在草创初期走的大多是战斗小组模式，研发，在此时还没有形成一个独立编制。
但随着企业日渐成长，公司规模成长到百人规模，业务营销服务都成立了独立部门，研发团队也来到二十到三十人的规模。
为了有效的管理与确保研发资源的最有效运用，研发通常也会被独立成一个部门。
而企业内也会自然的走向单一产品型或功能性组织。
一、集中式的研发团队，习惯上我会称这个阶段为集中式的研发团队。
这一时期基本的运作模式是各部门对研发部门提出需求。
研发部门则依循一套机制来排序所有部门的需求，并且按照谈定的顺序进行开发工作。
然而，企业在此时仍在追求快速成长，因此销售与营销的需求往往会优先被考虑。
而服务与后勤的需求以及研发团队针对产品或技术架构优化的需求，则往往被滞后，需求顺序会偏重支持短期的营收增长。
而客户服务与产品优化等长期项目则严重被忽略。
二、分布式的研发团队，有鉴于集中式研发团队的问题。
许多企业会在此时选择扩张或重整研发团队，将一部分的研发资源放在处理各功能部门的短期性需求上。
我习惯称这样的团队为功能部门研发团队，另一部分研发资源则专注于产品与技术的持续进步上。
这个团队我则习惯维持研发团队。
这个称呼经过调整后，各功能部门都将拥有一个属于自己的小规模研发团队，所有的需求都可以先提交给这个团队。
若需求本身较紧急且规模较小，复杂度较低，那就由这个团队直接处理。
若判断后认定为长期需求，则将需求pass给研发团队来评估与开发。
这样的组织架构虽然可以同时兼顾长期与短期的需求，但那些被分配在功能部门的研发，成员们则难免会有所怨言。
会认为自己所做的事儿没有太高的技术含量，更多的是例行数务与简单的编程工作，时间久了便会失去工作热情。
我们曾经尝试过轮岗，让成员能在各团队间轮替，但在几次实践之后发现，这样的做法成效并不好，因为所有人都倾向于做那些看起来价值更高的事儿。
如果技术领导者在做组织分工时，已经先排除团队价值的高低，那被分派到低价值。
团队的成员自然会觉得自己的工作价值不高，会觉得自己不被重视，团队的向先力热情与使命感都会大幅降低。
为了有效的解决这个问题，我们又尝试了第三种组织架构、矩阵式研发团队。
三、矩阵式研发团队。
矩阵式组织架构最主要的特色在于重新定义了之前提到的功能部门研发团队的角色。
过去我们指派给这个团队的任务是支持功能部门排除问题与开发短期需责。
现在呢我们则把各个功能部门定义成一个个独立的产品，每个产品都有单独的产品经理负责。
而这个产品经理的核心任务，就是与各功能部门的产出直接挂钩。
例如，销售系统被定义成一个独立的产品，他拥有自己的销售PN,目标，就是让销售部门达成所有KPI,可能是业绩退货率、客单价提升等当角色。
从消极的支持转为积极的负责后，团队的定位就更加清晰且重要了。
此外，推动矩阵式组织的另一个观点是，产品经理可以通过改善产品或通过运营的手法来促使业绩达成，比如百分之三十的增长。
然而，产品经理始终是产品专长，对于销售、营销服务的理解并不见得非常深入。
因此，如果能在销售、营销、服务等岗位上，也设立产品经理的职务，肯定能对增长带来重大效益。
举例来说，如果销售PN能够通过技术带来百分之三十的销售效率提升，就能一次性让多个产品同时受惠。
如果服务PN能够通过技术更个性化的服务顾客，有效的降低了。
比如百分之十五的退货率，也有机会让数个产品都得到提升。
过去经验里，这些PM本身都熟人技术与业务知识，能同时从两方思考系统问题所提出的解决方案，往往会比纯技术PM或纯业务PM来得更加到位。
从这个角度来思考，功能，部门研发团队的重要性便明显提高了，他们能直接为公司的效益带来贡献。
团队成员们有了相对清晰的目标，使命感与热情便有了非常明显的提升。
本文跟大家讨论了较多关于场景与组织架构的内容。
往下几篇呢，我将分别与各位聊聊关于研发流程管理的选型，研发管理过程中的那些坑，以及如何打造追求更快更好、更有价值的组织文化与人才梯队，很高兴能与大家交流。
关于高校研发流程这个话题，咱们明天见。