迭代亮点成就创新

迭代亮点成就创新

摘要：面对外部环境风起云涌的变化，为了适应新时代，为了前进发展，持续创新是公司必做的选择。研发团队作为技术公司的重要组成部分，承担着创新的重担。本文结合所在团队的创新实践经验所总结的一套方法论（品鉴-模仿-迭代-成就创新）进行阐述。同时也会阐述【BE-DO-HAVE】思维模式在团队创新中的应用。

一、前言

在知识浅消费时代，把各种所谓的好文章、好文档、好电子书加入藏经阁（TODO LIST、收藏夹、点关注）已经成研发人员的一种“通病”。在加入藏经阁时，就已经变为“欲望奴隶”，想着空闲时间再去深入学习这些。公司每个月也会有一些亮点成果的展示，如何把这些亮点成果为我所用、为团队所用，而不仅仅被收藏或者作为一次快消品。如何在自己的团队中基于前人的亮点成果进行创新，值得思考。

       直到有一天读到一句话：The difference between ordinary and extraordinary is just that little “extra”(普通和非凡的区别仅仅只是那个小“额外的”)。这句话像闪电一样击中了我，平凡和不平凡之间不过就是多做的那么一点。同理，亮点和创新也就是再往前探索的一步之别。

二、创新方法论

      在过去的几年中，所在团队也为部门、公司贡献过很多亮点成果，同时也有基于其他团队的亮点成果进行深入再探索，最后也形成了一些创新项。在创新实践中也总结了一套创新方法论：

图1 创新方法论

（一）品鉴亮点

乔布斯说：“佛教有一句古话，叫做初学者心态，拥有初学者的心态是一件了不起的事情”。品鉴亮点需要抱着这种心态，在品鉴的同时请不要忘记薅“羊毛”。

1、学套路

部门的亮点工程每期都会认真看，并梳理、分门别类。其中很大比重的一类亮点工程为贴合自身团队的优化性总结，整体思路如下：

                                                             图2 优化性总结流程

       我在团队内部也经常做一些分享，也和团队成员探讨过如何做一些亮点工程，很多人的回复是：找不到切入点。若是掌握这个套路，其实做亮点工程也没想象中的那么难。

1. 不止眼前的“苟且”

很多时候，项目遇到的技术、业务问题千篇一律，但是解决方案姹紫嫣红。也许同样的问题，你已经有相应的解决方案，但很可能给出的解决方案不是最优的。品鉴亮点，能够在你“山穷水尽”之时，提供更优的解决方案思路，从而让你感觉“柳暗花明”。结合亮点中的方案及自身实际情况，在亮点之外可能会发现“又一山寨”。

1. 提效率、增质量

对于团队来说，高效率、高质量一直是所追求的。但是追求的道路上拦路虎层出不穷，让我们疲于应付。亮点工程也有很多这方面的总结，结合研发环境、业务模式、管理模式等方面总结下来如下：

                                                                图3 提效增质流程

另外，在品鉴亮点的同时也是对我们已有经验的改进。正如所说：当经验不变而事物改变时，经验就成为绊脚石。

（二）模仿亮点

毕加索所说：模仿是人类一切学习的开端，然后才是创新，最后是你的自主。模仿不是一成不变，也不是不要自我，而是在学习别人积累的经验，然后内化成自己的，成为更好的自己。

1. 博观而约取

亮点工程很多，里面的方案是否合适需要审慎地取用。而不是一股脑的全部拿来模仿着使用。把亮点分几个专题，筛选出适合的，让团队成员以自组织的模式，深入研究，避免走马观花现象。

1. 照虎画猫

在团队的分享时，经常给团队成员说：好的设计、优秀的代码不用去别的地方找，JDK就是最好的参照物。比如：JDK8中新增的Stream流式处理，你是否可以照虎画猫“描”一个简单的流式处理器。很多时候“笨拙”的模仿，也是快速成长的诀窍。模仿不是不要自我，而是在学习别人积累的经验，然后内化成自己的，成为更好的自己。

1. 广而告之

模仿的过程就是一个内化的过程，最终让从亮点中汲取营养为我所用。把这次模仿的心得、经验分享出来，是对知识的又一次加深。用胡适的话说：发表是最好的回忆，分享也是发表的一种方式。

（三）迭代亮点

迭代是重复反馈过程的活动，而每一次迭代得到的结果会作为下一次迭代的初始值。基于已有的亮点成果进行迭代，就是站在巨人的肩膀上创造。

结合业务参数配置中心产品（简称：CC）自身实际案例，在参数的测试环节，把场景测试组件不断的升级迭代，最终可达到满足各种复杂业务场景测试，少配置、零代码开发即可支撑。

 图4 场景测试框架迭代

1. 迭代要趁“早”

有团队成员说可编码式挺好的，类似模板一样，代码的复制粘贴，稍加改动也不费时间，就可支撑相应参数的测试场景。最后迭代出的配置式、红黄绿式，只是从可编码改为可配置、通用配置，也节省不了什么时间，为何要迭代？

改变有时候不是因为我们做的不够好，而是外部环境变了。CC的研发模式当时已明确为“外敷内服处方式”研发模式，外敷即零代码开发模式，内服处方即低代码开发模式，那么团队人员的角色就转变了。外敷模式需要前端人员全部承担，后端人员解放。这时候配置式就是为了配合零代码开发模式，前端人员不需要写后端代码及测试代码就可完成整个参数的设计、配置、测试、发包、上线工作。

在感知到外界变化后，要趁早迭代我们已有的成果。让其更符合我们产品规划、资源规划。

1. 迭代要有节奏感

设计、研发产品是需要节奏的，在汽车、手机行业节奏感尤为明显，每个新机型的发布，很多亮点都是在已有功能上进行的迭代，不是一蹴而就的达到现在这个效果。

整个测试组件的迭代按照下图的这个节奏感，也是受限于每个时期的资源、认知、外界环境变化。

图5 场景测试框架迭代节奏

1. 迭代要有不完美主义精神

无论是产品、还是设计，只要它还只是停留在头脑中的想法、文档中的描述，当与他人分享时，很多人都会迷失在语言表达的过程中，甚至每个人理解的完全不是同一事物，毕竟“一千个读者眼中，有一千个哈姆雷特”。

只有快速迭代出来一个基础的产品，不求完美。在此产品基础上进行阐述我们的构想，那么可能一千个听众眼中，只有十个哈姆雷特了。同时这也是一个快速试错的有效机制。

迭代过程中不要求面面俱到，要坚决摒弃完美主义精神。先完成，再完美。

（四）成就创新

       上文说到的基因重组式复杂场景测试框架简单介绍一下。设计原理：结合“乐高”原理，基于零代码及底代码设计以及场景的抽象、重组、重用、顺序机制考虑，把场景拆分为场景片段（最小原子粒度），每个场景片段挂载一个执行段（实际执行的功能）。那么复杂场景的组装，就可以根据乐高模式来拼装各种各样的测试场景。场景片段与场景片段之间数据传递通过场景上下文机制。

       另外考虑到有些基础场景是复杂场景的组成部分，可以把基础场景也作为场景片段的一种，称为场景片段组。

图6 基因重组原理结构图

基于此设计原理有以下特性：

• 不同的场景，可以复用场景片段及执行段
• 不同的场景，相同的场景片段可以挂载不同的执行段
• 不同的场景，相同的场景片段执行顺序可以不同
• 同一场景中，不同的场景片段可以挂载相同的执行段

另外，此框架还有度量功能，通过与CICD相结合，每次所提PR合并到发布分支后，会自动触发测试，把测试场景的执行结果进行汇总，从而反应出此次PR合并对参数业务场景的影响。    

曾被问及这样一个问题：能否快速提供场内技术能力到场外？对我们团队来说，问题的重点不在场内技术能力输出，而在于“快速”。团队的技术资产和能力都是有的，只是缺乏快速提供的能力。快速输出就需要进行标准化，达到可复制模式。这正是基于支撑场外这个契机，把场内的研发模式、规范、实践经验、避坑指南等重新梳理了一遍，落成了规范，标准，方法论。

图7 技术输出标准化

整个场内到场外的能力输出任务的额外成果就是：一种场内能力标准化，可复制的成果创新。

三、总结

       从上面四个环节中可以看到，每个环节中都贯穿着一条背后的暗线：我的目的是什么（BE），我需要做什么（DO），我取得的成果是什么（HAVE），这就是聚焦目标。[BE-DO-HAVE]也是一种循环模式，不断的在迭代中复盘、精进。有人讲“全面的拥有等于全面的平庸”，先把BE搞清楚是重中之重。

很多通过实践总结出的方法论，不在于理念有多先进，而在于能够落地多少。这不仅仅是简单地执行，还在于能够结合实际最大化地贯彻下去。创新很多时候就是在模仿、筛选、整合已有亮点成果的基础上进行的迭代。

流水不争先，争的是滔滔不绝，也许你与创新就差个迭代，找到切入点，盘它即可。