我们经常去谈互联网思维，传统企业转型问题，到底什么是互联网思维，说到底，不过是围绕互联网新市场环境下，我们企业内部各个部门围绕它而做出的改变。这看似一句话的解读却需要公司上下根据变化做出全面调整，其中产品研发就是一重要环节。
企业互联网转型的研发引擎重要性
先从一个故事讲起，这是一个具有代表性的真实案例：某家具有20年历史的传统制造企业，产品品类很多。今年年初了进入智能手表领域，上市后由于前期强大的广告投入、成熟的销售渠道，以至于上市后销量非常可观，达到月销量几十万台的好成绩。
因为这是一款定位非常精准的，面向儿童的智能手表，同时解决了家长的一大痛点，防走失功能，可以定位找到孩子，所以被大家广泛接受喜欢，但是没过多久其他企业也推出同类型产品，而且其他公司快速超过了他。
为什么一个成功的领先者很快被后来者超越，在当前的时间点，若复制一个商品，有各种各样的供应商可以提供解决方案，所以很快就会有公司复制或超越你。如果想不被超越，你要比后来者做的更快更好，让追随者无法超越。
分析他们问题的成因你会发现，前期成功只是因为敏锐的产品嗅觉，但是嗅觉只能维持一时，当刚性的痛点性的需求被挖掘到时很容易被大家蚕食掉这片市场。
案例中的厂商只做到了前面，当面对无数纷至沓来的竞争者时，他们败在了缓慢的研发速度上。
其实当第一批消费者使用产品时就碰到了很多问题，由于渠道商会将产品铺到多级网络中，从一线城市甚至到3-4线县镇，用户的复杂性是难以想象的，他们每天会收集大量的客户反馈，硬软件各种问题扑面来，当企业面临着更加复杂的网络情况和用户使用情况，他也很难去定位问题。
这就是传统企业面对互联网时，无法应对网上复杂的用户场景，以及用户带来的各种各样异常的是操作带来的更难的问题，缺乏处理大量用户反馈问题经验的一个典型案例。
于是，他们疲于应付这一切，产品因为上线之后想去做新的功能，受到线上问题的冲击，以至于他们不断的延期产品的可调时间。导致延期两个月至三个月才能上线。
如果有一万个用户来给你提问题，但是你要等到三个月以后才能发布一个新版本给到他，再让使用者去提意见，任何一个用户都难忍受如此长的等待，这就是一个致命的问题。
再经过了解，发现员工工作状态也很不利于研发。七天每天十一个小时的工作制，这会导致员工疲惫不堪，从而严重影响产品品质，最终导致了他们在这个第一个产品发布后三个月内，产品销量不断下降。即便付出大量的广告推销还是不能挽回颓势。
研发背后的四大问题
第一个问题，管控性研发
这种方法本身无问题，但任何好的方法都有他适用的范围，相比较他更适合硬件制造业，确定性目标明确，中途目标不改变这就适用此方式。而互联网产品研发，由于以用户需求为准，而他们的需求是变量，所以计划性强的研发就可能屏蔽掉用户需求，对他们视而不见。
第二大问题，职能化分工
这是阻碍传统企业转型的最大障碍。将人专业化分工这是非常好的做法，但是在互联网时代这样的组织结构时间是不利于产品研发的。因为专业化分工非常的清晰，那、以至于员工只负责自己眼前这点事。而对最终的产品交付结果都不承担后果。
没有人对最终的结果进行负责，而实际上在这些企业里面最终负责结果的人是这个业务的负责人。但是由于负责人每天被行政事务缠身，对业务可能关注不可能很细致，但恰恰相反的互联网企业里边，各个层级的老大都会非常非常的专注在产品细节上。
第三大问题，串行流程
这导致在某一段时间某一岗位很忙其他的岗位很闲的这样的状态出现。我们在这个互联网产品里面可能更多的期望的是说我们能够多角色多任务平行工作，并行起来工作证能够效率最大化，并且能够加速对结果的，产出的反馈。
第四个问题，闭门造车
我发现企业都特别缺乏的是创业精神，什么是创业精神，你想到了个点子然后投入去做，做完快速放在市场上检验它。证明它是对的还是不对的?如果是对的你去可以去进行下一轮融资然后等等。
但是在企业里面因为你有很多资源，而且再加上有很多权利。那这个时候你可能更多考虑的是，一件事情通过部门规划去统筹安排做了。那就做的过程中你是否与用户需求越来越远了?很大程度上就造成了很多企业在做新产品的研发的时候采取的是闭门造车的方式。
我猜用户需要什么东西然后再去做个什么东西，做出来以后花个半年一年的时间花费了大量研发成本以后，竟发现产品有偏差。
以上四点造成了产品研发滞后。
接下来呢我们来看一下我们当时给他的一些解决方案。
最终通过不断试调，结果如下：
研发各层级解读：
作坊式研发-管控性研发-敏捷阶段-极速研发，这是一个逐层效率提升的研发方式模型图，可以看到我们在互联网环境下，最佳的方式是极速研发，在腾讯等互联网企业中都在做极速研发方式，追求快和变，追求客户的需求和体验感。
课程问答：
1、在产品研发改进层面，如何通过互联网收集到用户真实感受，如何分辨哪些意见是我们需要重视的?
转型的过程之中大家遇到产品上线之后常常遇到的第一个问题。而这个问题是非常棘手的身份难以找到一个判别标准的这样一个问题。对用户的反馈实际上我们是都应该重视的，但是了如何去分辨，这其实是一件很需要经验的一件事情，去读足够多的意见反馈你才可以做得到啊!腾讯那边那有一个最共这个约定的一种。工作习惯就是叫做一千一百十法则。
2、请问串行工作方式之外，还有什么更科学的协作方式?
串行其实是在很多时候是不可避免的。特别是岗位之间相互关联的情况下特别容易出现这种问题。
但这并不是说串行不好，大家有没有感觉在我的分享过程中，不会去否认一件事情，而是跟随场景而定。如果把它放大化或者基于工作分工去串行，这样效率是非常低的。如果把它变成以需求和任务去串行，那么就很有必要性了，因为相互之间必须有依赖。
所以这就给了我们一个机会，如何能够让多种任务、需求能够在并行的方式下去开展?
我们举一个很简单的例子。比如说我们在当前迭代工作准备需求的时候，开发的同学或者编码工作的同学就可以去启动开发之前已经准备好的事情了，那在开发之后的测试的同学就能够提前进行测试了。
这就实现了在同一时间大家在不同的层面上工作或是不同的任务领域去工作，形成了一个给大家并行工作的机会。
同时在并行工作的过程中，如果有交叉和重叠我们可以在相对固定的或者确定的时间来进行协作。这就给了我们更多的协作时间点。所以我们推崇大家使用迭代日历等方式去约定大家的共同协作时间，去改善大规模团队如何在一起的工作方式。
3、银行是怎么样结果导向化的?怎么避免出现管控型研发和职能化组织?
银行是一个非常典型的行业!最近刚刚结束了一个深圳证券交易所的项目。他们和很多银行系统的研发运作方式都非常类似。在这个过程中我们其实是有一些针对于银行行业的解决措施的。
首先不是去考虑让结果导向化，而是考虑如何让研发效率提升。
我们发现银行体系下的研发是偏低效化的。虽然加班很多，但是却没有那么高的效率。他们实际上是一种典型的内包方式，内部外包：这是在向业务部门提供具体的信息化系统，这个过程中离用户和最终业务使用者是非常远的。带给他们的结果导向化的最大问题就是无法知道这个事情做的对不对，以至于结果导向化变成了几乎不可能实现的状态。
所以怎么能够从后端往前端挪?或者是从前端和后端去牵引，这是首先要解决的问题。这个问题如果能够被解决，其实效率本身就会提高。提高之后再来考虑结果的导向化怎么处置。
在深圳证券交易所的项目中，我们把业务部门和研发部门重新组成团队。在组织架构上做了一个虚拟化的团队重新打造团队。让业务方面的经验传递进来，带到研发的过程之中，并且在这个过程中去接触消费者、储户和业务的使用者，能够直接去收集反馈意见。在反馈意见的过程之中再去看看如何评定我们的工作成效。我们的银行系统可能需要考虑和采用更多这样的方式和思路。
选购指南：
本公司主要为山东地区的商业、企业及个人提供各类定制开发服务，如：软件定制开发、APP定制开发、微信定制开发以及P5业务支撑平台等整体的信息化解决方案，能够满足各类大中小型商业、企业及个人的需要。
