最近不少车企在推动敏捷开发，加上听了一个网上关于这个话题的讨论，就正好顺着这个话题聊一聊．关于敏捷的话题有太多人聊过了，这个话题也太大，也有太多这方面的专家．大家多聊聊，相互学习．
这一篇文章里有车叔过去的一些思考，算是结合在不同公司工作后的一些想法，也基本算是车叔到目前为止在技术和管理方面工作的一个总结，同时给在海外打拼的这些年头划一个逗号．车叔工作的时间不短也不长，所以肯定有考虑不周全的地方．但是仍然想写出来的原因是希望可以和各位分享一下车叔的思路，不管结论对不对，希望可以给朋友们提供一些讨论的话题，也希望获得一些反馈和建议．
今天文章可能比较长，车叔会从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流程"的模式．（似乎是废话，说着简单，实际太难）
