传统车企和互联网思维的碰撞？V流程和敏捷开发，二者该如何选择？

V流程开发模型和敏捷开发模型，这二者该如何选择？

这或许是目前很多传统车企在转型中所遇到的问题，同时也在一定意义上代表了传统企业和互联网企业的讨论，今天我们就以互相学习为目的，来一起聊一聊这个命题。

文章中难免可能会有不准确或者有争议的地方，写出来的原因是希望可以和各位分享一同分享“车叔”的理解思路，不管结论对不对，都希望可以给朋友们提供一些讨论的话题，也同样希望获得大家的一些反馈和建议。

文章可能比较长，“车叔”会先从V流程开发模型和敏捷开发模型开始，通过一些工作中的实例，从企业文化，组织构架，研发体系，员工配置等方面来聊聊它们的骨架和灵魂

敏捷开发模型和V流程开发模型

二者之间为什么会有争论？

首先， 做为软件开发过程中应用最广的两个经典模型，敏捷开发模型和V流程开发模型，本质肯定是有所不同：

• Ｖ流程模型的核心思路之一，是把环环相扣的工作都规划好以力争一次正确（虽然实际不太可能）和制定项目时间计划。
• 敏捷开发模型的核心思路，是知道时间会很有挑战而去实时进行优先级的调整以达到同一时间内的产品力最大化。

它们两个，一个是尽量让所有事情都可控，另一个是知道不可控但是随时在争取纠正回来。如果我们在说的形象一些：它们一个像抓地过弯，另一个像漂移过弯。

写到这里，大家也许已经可以看出来，开发者对于二者的选用，为什么会有争议了：因为“抓地过弯”和“漂移过弯”，二者本身就存在很大的区别和争议。

但是，Ｖ流程模型和敏捷开发模型其实是并非相互矛盾的，下面我们就来详细的聊一聊！

敏捷开发模型和V流程开发模型的结合

首先，在使用Ｖ流程模型进行开发时，开发者也肯定会遇到问题。那么，当我们遇到问题的时候，企业还是会需要根据时间限制来调整待解决问题的优先级，这其实也算是以Ｖ流程模型为基础，添加一些“敏捷开发模型”的元素吧。

同样，在使用敏捷开发模型的实际过程，也不是说前面不分析好构架直接上来就干，开发团队同样是要分析构架和客户需求等等。

所以，敏捷开发模型和V流程开发模型，不管是主动还是被动，两者往往在某种程度上是相互结合的。

当然，上面的说法里面还是有比较明显的主要思维方式的，可以说是初步的融合。

那么，如何实现两种不同“思维方式”的深度融合呢？

“车叔”的经历还不够丰富，我就尝试着从几个浅显的方面举几个例子：

在一定意义上，企业文化就是企业里多数人处理问题的思路和方法。它可以说是最重要的，但也是最难实现的。

首先，仅靠传统V流程模型里的Ａ-Ｄ样件的迭代，开发团队少有闪失是不容易跟上整体开发进度的。同时，单靠组织频繁的会议来把各部门的人硬拉进来做快速迭代，这也无异于拔苗助长。

实际的开发过程中，其实更需要工程师在日常工作中增加横向交流的频率。比如，当需要做调整的时候，开发团队需要和相关部门提前多沟通，而不是等需求都写好了交过去后，对方说做不到。亦或者是单纯的把需求文件发过去，但是完全不沟通。

而实际上，当开发团队遇到问题的时候，需要主动进行相互间的横向沟通，并在缺少其他部门“输入”的时候，进行主动协商，而不是等到开项目节点会议的时候再去上报这些问题！

其实，很多开发公司的开发团队是具备这方面的主动思维能力的，但是想要大多数人都更多的付出主观能动性，除了激励措施之外，领导们也要更详细的告诉大家需要如何做才能获得“激励”，而方法是否正确就要由领导来把握方向。

对于习惯了传统V流程开发模型思维的员工来讲，往往容易出现“等靠要”的思维惯性：＂某部门没有把需求写完，所以我没法开始！＂

这类的话，我们都听过太多遍了吧！

当然，这里不是鼓励没有需求就硬上的行为。

但是，如果用“敏捷开发”的思维来考虑的话，开发团队应该根据有限的时间来考虑缺少的需求有可能带来多大影响：如果影响不大的话能否先开始后面在小改？影响大的话我们能不能先做一些相对可靠但是不准确的假设？如果还不行的话找项目负责人看看能不能协调一下资源调整优先级？等等！

“在有限的时间和资源内做到产出最大化”

其实很多优秀的传统项目管理人员都有这样的思维。但重要的是，他需要让团队大部分人都能理解和做到同样的思维模式，并就此而形成一种企业文化。

任何产品开发的实现，都离不开体系与流程。

而开发的过程，如果从“流程”上来看，应该尽量在项目时间节点的安排上体现出来。这也可以理解为，把原本Ｖ流程模型中的一环接一环，变成环环相扣，增加一些重叠！

上面还提到，在传统的体系里，假设，决策，和协调的工作，很大一部分是由部门领导来做的。

但是，实际上这些工作到底该由谁来拍板？

项目到了某个时间节点时，该由谁来验收？

出了问题需要跨域做trade-off的时候，谁来定？

跨部门的合作该由谁主导？

这些都存在很大的挑战！

按照敏捷开发模型或者Scrum的框架思路，开发团队里需要有人来从整体的角度来衡量整个项目。这个角色和企业里的项目总工程师，项目技术负责人的角色类似：他们需要从不同的角度和方向，把各个研发职能部门横向串联起来。这样才能避免在项目遇到问题的时候，两个相关部门的负责人单独出来讨论和协商。

虽然很多公司已经在团队中安排了类似的角色，但是常见的问题是，他们要不是每天被埋没在解决具体技术难点上，要么就是奔走在各个定期的汇报会议中。

实际上，这个角色的主要任务，是解决如何横向串联各部门，把技术难点拆解成各个部门的独立任务，然后由各部门领域的专家来做具体分析，去融入到各个跨部门讨论中，去根据项目进展和流程来给各部门工程师定义各交叉任务或者问题的优先级别，审视项目中的技术风险，并提早发现问题和调整方向与优先级等等。

项目管理，在一定程度上就是一个风险管理的过程：开发团队在项目的每一个“时间节点”上所追求的，不应该是“全绿”，而应该是“适当可控的问题量和风险”。

反过来说，如果到了一个“时间节点”，所有指标都是绿的，那从某种程度上，也证明这个“时间节点”的设置过于保守，反倒可能会拖延这个项目的开发。而这，也正是“敏捷开发”的主要思路之一：大家需要通过实时沟通来协同工作，而不是当各自完成任务之后，到了某个时间节点再去做交接。

有问题很正常，没有项目能完全按时按质交付，关键是“风险”要可控。

我们可以看到，这个虽然是项目管理相关的工作，但是也离不开由企业文化造就的研发人员去主动横向沟通。

因此，有时候我们需要把“大V”拆开，各环节之间的交叉点，就是我们要优化的重点。

比如，从产品策略到工程开发，到生产，到营销等各个环节之间，并不一定需要只有一个交接点来代表前一步里的所有内容都已经完成，它们是可以有重叠的，重要的，是把关键内容确认好，为后续的开发过程降低风险。

当然，这个“度”的把握，很需要拿捏！

上面说到，企业需要设定类似项目总工或者项目负责人的角色，由他去做横向跨部门“牵引”的工作。

此举的主要目的，是让员工在发现问题或者需要做决策的时候，不是只能单一的“直线汇报”。适当的增加横向沟通，能够把原本需要某一个领导解决的众多问题分散开。而如果企业的组织汇报线，是一条线向上的话，这样往往会导致低效。当然，如果汇报线过于分散，也会导致问题，所以掌握平衡是很重要的。

当下，大家一直在谈论SOA（Service Oriented Architecture）的重要性。其实，一个企业的组织构架也应该是“SOA”的，而这个构架的服务对象，就是开发团队和最终的产品。

构架是决定开发效率的重要因素之一！

就如同一个产品的构架（不管是硬件还是软件的构架），都是决定这个产品质量的重要因素一样，一家企业的构架，也是决定企业好坏的重要因素之一，而这一点却往往容易被忽视！

下面我们不妨举几个例子：

例１：很多公司的部长或者总监需要同时承担多个角色的任务，比如改善设计方法和使用的软件，定义系统构架，救火，定技术路线，选战略，预算，再加上一定程度的项目管理，还要确保下面的各个组的合作，最后还要进行人事管理等等。这导致的问题就是，作为管理者，他们有时自己也摸不清楚自己的“角色定位”，也或者根本无法照顾到每个角色任务的方方面面。

很少有人能够在这种情况下每一次都做出正确的决定，这可能会导致下面人还会抱怨决策不合理，同时还会抱怨自己没有职位发展空间（因为只有一条路向上）。同时，企业管理层还会觉得，我都累成这样了你们还不理解我，就知道提意见！

在这种情况下，如果其他都不调整，只是去强推照搬“敏捷开发模型”，最后的结果只会是治标不治本！因为，如果“部长”仍然对产品和技术路线以及项目进度等多方面都主要负责的话，开发团队仍然是单线给部长汇报，最后就算设立了专职的“项目经理”，他在一定程度上担任的是部长助理的角色。

如果是这样的话，重要决策仍然需要一级级向上，效率改善不大。

例２：很多传统车企开始学习互联网企业，强调组织构架扁平化，提高效率。但是，如果“汇报线”还是一条线向上，没有横向的穿插协调，那这就是一种“虚”的扁平化，甚至有的情况下还不如原来的构架高效，因为所有问题可能都要由上面的领导来负责，导致没有鼓励基层领导主动承担工作和责任。

例３：很多传统车企设有单独的前沿Research部门，但是这些团队往往是要和Delivery部门分开！例如，同样是搞电池，为什么有一波人负责前沿项目研究，而另一波人要负责实际量产，这两个组织还经常隔山涉水？我们可以设想，如果作出构架调整，效率会大大提升，也避免了有些公司还需要一个额外的“第三部门”来把前沿研究结果消化后交接给量产部门。而这，似乎也成了给传统企业的组织构架打补丁，越打问题越多。越是相互沟通密切的团队，越需要组织构架上的融合来打破壁垒！

例４：工程师对技术上的理解，肯定会对技术路线的选择有认识！但是，工程师对技术路线大方向的选择或多或少有感情因素，比如经常会觉得什么技术牛或者先进就偏好什么，但这样是否能给客户带来“价值”，是否把牛技术拼到一起就真的牛了，却往往会被忽略掉！这一点，无论是在国内还是国外车企里，都很常见。

例５：企业的组织构架是需要根据企业战略需求进行变化的。另外很重要的一点是，企业应该尽量要把需求紧密交叉的成员放在更近的构架框架里，尽量避免出现每天需要沟通的事情都要跨团队跨部门，这样能够很好的提升效率。具体各个团队成员之间谁和谁的交互更多，更需要构架上的协调支持，这也是随着企业所处阶段不同而有区别的。

简单总结一下的话，如果企业决定推动“敏捷开发”，并且希望提高效率，那么就应该尽量逐步：

＊　避免汇报线一条线向上，把该剥离的剥离开；

＊　避免为了扁平而扁平；

＊　避免单纯按照工种和使用的工具来划分团队；

＊　针对需要频繁沟通的小组进行组织构架上的集结，提升沟通效率，避免事事跨部门；

＊　根据战略需求适时调整构架。

当我们沿着上面的思路进一步分析的话，要想促进团队横向沟通提高效率，对于团队成员的经验需求也会有新的要求！

我在这里做个预测：以后，按照工种或者使用工具来划分的组织构架，会逐步转向按照部件或者功能来划分（可能很少会再有一个统一的大CAE部门），而一个部件或者功能的开发，会需要对关于这个开发的相关工作环节都一定了解的全能型人才或者说跨界人才。

比如说，做电机开发需要或多或少对于仿真／标定测试／设计等等环节有一定认知，这能从某种程度上帮助避免推卸责任，有更多的交叉和Ownership，而尽量避免＂这不是我的问题，是仿真没做好，我不管仿真＂这类问题的发生！

在有的企业或者部门里，依然会单纯按照使用工具或者工种来划分团队，比如把所有搞FEA仿真的工程师全放在一个组里，不管是做哪个系统或者部件的。但其实，使用某个工具进行开发的最终目的还是把产品搞出来，工具并不是目的，我们也不应该被工具所局限。

那么，把一些工种或者工具使用者打散之后，企业该如何继续保证开发质量呢？这就需要相对独立的专家（比如FEA专家）来从工具和方法的角度，把各个部件FEA分析的工具链和质量，尽量推动到同一水平来保证稳定性。当然，这也可能不是所有都适用，比如验证测试还是需要有明确的区分的。

而这也可以促进企业文化方面的建立，因为，相邻团队相互了解技术背景会更容易在交接的时候提高沟通效率。同时也可以在上一环需求不完善的时候，一定程度上帮助发现问题甚至协助做一些假设来填补空缺，利于V流程加入重叠之后的协作。

企业配合组织构架上的优化，加上开发团队技术知识范围的一定广度，可以让跨组跨部门合作实现高效协同。

人才的运用是实现前面几点的关键因素之一，也符合那句老话，人才是核心竞争力！

当然，如果每个人都是多领域的专家，也可能会带来其他不必要的“麻烦”。所以，关键是团队内要形成梯队，各部件或者功能团队里需要有这样的全能型人才来负责技术，也是便于横向串联时的效率．

从另外一个角度来看，现在的传统车企开始加大力度参与零部件及软件的开发过程：直接做操作系统，直接介入供应商的原材料及芯片采购，直接进行销售渠道，直接与客户沟通等等。这些跨界的方面，都非常明显的说明了整体行业内商业模型与合作模式的变化，而实际去执行这些跨领操作的人才，肯定也需要有更多跨界的经验才能适应．这样才可以实现１＋１＞２的效果，达到系统间整合效率的提升是本质。

除了这些过于宏观的方面，在具体开发中，各环节的交叉也将成为趋势。

即使传统车企不直接跨界，这方面的经验也会很大程度上帮助车企进行决策和整合。

所以，以某个领域的资历为主，加上跨界能力的全能型人才，已经开始在市场上有更大的“谈判空间”了！

V流程开发模型和敏捷流程模型，在“工具”选择上，并不存在哪个好哪个不好的问题，真正应该去讨论的，是怎样把这两方面结合起来。

两者的结合，不如把V流程当作是产品开发的基础骨架，而敏捷开发的引入，则更像是通过企业文化，组织构架，研发体系，员工水准等等多方面的结合，来给基础骨架注入灵魂，这样才能够适用于未来汽车行业的新需求和新生态！

所以，虽然前面有比喻Ｖ流程和敏捷开发，像是抓地过弯和漂移过弯。两者虽然技术路径不同，但是其背后的思维方式，可以相互结合成下图这样．

而上面提到的几个关键因素之间，也是相辅相成的关系，缺一不可。

所以，一个企业不是说“敏捷”，一下就能“敏捷”起来，这里的每一环都需要用心去培养！这些环节实际上做到的是把整个企业在横向和纵向上缕清晰。

更加复杂的系统，更多交叉领域的协作，更多变的技术迭代和不确定性，更激烈的市场竞争，更大的战略转型风险，对于传统的开发思路来说已经很难招架。因此，企业需要在研发的思路以及研发和市场的联系等各方面进行提升，才能够适应新的环境并且活下来．

传统车企转型，不光需要设定战略，还需要这些固有思维上本质的变化。对于很多大企业来说很难一步到位，这也一些公司选择另起炉灶的原因之一。

最后，如果从宏观来看待V流程开发和敏捷开发的结合的话，其实从某种意义上是在提高（或者说压榨出）员工的剩余效率。

原本按照V流程开发模型按部就班的走，总会有的环节走的快一点有的走的慢一点，那么走的快的其实就可以有时间喘口气等一等。但是当加入敏捷思维之后，有空闲或者处于等待状态的人员则需要提前往后走一点，也可能要去帮帮慢的。

这基本是一种让大家都闲不下来的方法，这在一段时间内可能会比较容易提升效率和效果，但是要长期维持下去，企业还是需要在经济上给出激励和奖励。从这个角度看，也是为什么传统企业会比新企业略难一点推进敏捷开发的原因。

其实，当把上面这些文字写出来之后，我感觉这篇文章不仅仅是在对比敏捷开发和Ｖ流程开发的区别，而在某种程度上是在聊互联网模式和传统车企业模式。

假设对两种流程工具的讨论，同样能够适用于对互联网模式和传统车企业模式的讨论的话，那么沿着上面的思路看下来，互联网模式和传统车企业模式，或许最终还是需要进行融合，形成类比”敏捷的V流程”的模式。