让传统行业研发团队插上用户思维的翅膀

 

 共计 5469 字｜建议阅读时间 15 分钟

 

本文是top100 summit 2016主题演讲的整理文稿，演讲主体分三部分内容：

1. 2015年罗辑思维跨年演讲说的“互联网恐慌”，其根本原因是什么？

2. 什么是传统行业的最大痛点？

3. 通过三个实际案例来讲述传统的研发团队如何理解并获得用户思维。

 

 

01“互联网恐慌”的根本原因

 

互联网企业如今吸引了大量的资源和目光，让传统行业的企业显得无所适从，感觉现在已经完全是互联网企业的天下，传统行业已经日薄西山，正在“混吃等死”了。

 

但其实我们来看一组2015年的数据：

 

• 华为营收3950亿，超过BAT总和

• 腾讯利润288 亿

• 中国烟草总公司利润1700 多个亿

• 中国工商银行利润2700 多个亿

• 中国移动利润1000 多个亿

 

无论营收和利润，BAT都不是最好的，甚至相差甚远，但为什么还会到处弥漫着浓浓的“互联网恐慌”呢，罗胖在他的跨年演讲上给了一个特别形象的比喻叫“你等着”，就是中学上课的时候，突然有个人告诉你说“你给我等着，下课后我要揍你！”，你会是个什么心情，肯定这节课都会充满焦虑，无法专心听讲了。而互联网企业就是那个叫嚣“你等着”的人，其根本的原因在于：互联网企业更懂用户，而且是越来越懂用户，这几乎是一种不可逆转的趋势。

 

马云曾经说过阿里巴巴最值钱的是数据，想想看我们的吃喝拉撒他们都清清楚楚，早上出门坐的哪辆车去的机场，坐的哪个航班去到哪个城市，下榻的是哪个酒店，在酒店旁的小餐馆吃了什么，买了什么，这些数据都老老实实躺在支付宝的数据库中。现金消费的场景将会越来越少，他们的数据也就会越来越完整，这是互联网企业真正可怕之处。

 

这就引出了传统行业企业的最大痛点：离用户太远了。

 

 

02 传统行业最大的痛点

 

因为传统行业企业离用户太远，导致难以了解用户的真正诉求，相较互联网企业就是越来越不懂用户了。对于仍旧财大气粗的传统企业来说，似乎直接从BAT挖人，然后照搬互联网的模式是解决这个痛点的最快捷之道。

 

但有太多的案例证明完全照搬是行不通的，因为传统行业企业和互联网企业存在着基因的不同。

 

首先，互联网企业用户和客户相同，或者说互联网企业是先通过获得足够的用户，然后才能吸引来或者直接将用户转化成客户，也就是说对互联网企业而言用户是入口。而对于传统行业的企业来说用户和客户并不相同，要先找到客户之后，才能清楚使用产品的用户究竟是谁，也就是说对传统行业企业而言客户是入口。

 

其次，互联网企业需求是内生的，自己主导需求，而传统行业企业的需求少量内生，比如优化类需求，而绝大部分需求来自于客户。第三，互联网企业的产品自主运营，比如微信一定是腾讯自己在运营，因为直面用户，运营数据属于自己，而传统行业企业的产品一般是客户来运营，想要获得用户数据非常困难，这就造成了离用户比较远。最后，互联网企业质量容忍度相对较高，试错成本小，而传统行业企业质量容忍度相对低，特别是对于电信级软件，比如核心网，一旦出现问题，影响的可能就是一个城市的通话质量，犯错成本非常大。

 

这些不同，本质上决定了虽然明知道这个痛点很痛，也不能照搬互联网的开发模式。

 

 

03 案例一 动用一切手段拉近和用户的距离

 

不是离得远么，那就想办法拉近。

 

项目背景：从传统嵌入式开发项目，跨入到行业应用软件开发项目。

 

产品迭代现状

这个是公司当时正在执行的产品迭代模型示意图，产品经理会先搜集一个超级大的需求包，大概十几甚至几十万行代码量级的需求，直接按照“交接棒”的方式扔给研发团队。研发团队吭哧吭哧做完之后，发现一年已经过去了。

 

从X2里程碑点一直到X5里程碑点，时间跨度非常长，半年到1年的时间，整个过程严格控制产品质量，不得外发，也造成了这一相当长的时间内没有任何用户参与。研发工程师更是长期见不到用户一次。

 

这种质量至上的模式，主要形成于公网电信业务，面向的客户是电信运行商，一旦业务出现问题，成本非常大。另外，需求比较固定，客户也不可能给我们快速试错的机会。但是对于面向企业的专网项目，甚至是行业应用类项目，用户的反馈及现场真实环境测试的重要性越来越重要。

 

我们意识到必须做出改变。

 

典型互联网产品迭代模式：

互联网模式相较而言，除了时间维度，多了一个用户的维度。所有的活动开展均是围绕用户展开。

 

发产品时先做出一个简单的原型——MVP（最小化可行产品）然后通过测试并收集用户的反馈，快速迭代，不断修正产品，最终适应市场的需求。这也是精益创业的核心理念。

 

调整，拉近与客户的距离

通过借鉴互联网迭代模式的思想，在X2到X5阶段，增加了“给明白人演示”、“建立展厅给客户演示”、“迭代演示”、“建立友好客户”、“补丁发布流程”、“灰度发布”等环节。这些环节使得产品的亮点功能不断产生，推出后在行业里获得了极大的口碑，成为了竞相效仿的对象。

 

另外在建立了友好客户之后，通过灰度发布除了能尽早获得用户需求反馈之外，对于实验室环境覆盖不到的特性，还能提前进行真实场景下的测试，提早发现实验室环境发现不了的问题。

 

除了增加上面的环节之外，在执行过程了，还发现了如下问题：

• 需求提出方PLM似乎不太关心我们的产品究竟做成了什么样；

• 我们一直在服务客户，真正在使用我们产品的那群人，似乎没有得到我们的重视；

• 做了一堆功能，我们并不清楚，哪些功能用户真正使用。

   

针对以上问题，我们采取了如下行动：

• 重新梳理外发流程，灰度发布涵盖版本早期阶段；

• 流程中增加用户访谈环节；

• PLM/SE/开发代表/版本经理都要把自己当用户真实使用产品，人人都是产品经理；

• 版本自带用户行为分析功能。

 

敏捷边界

我们一个项目完整的流程是先从客户那收集需求，然后启动项目论证，论证通过后立项，需求分析，方案设计，开发实现、测试验收，达到GA（General Availability）点意味着产品可以批量交付给客户，然后产品上线，客户运营。

 

很多企业都推行了敏捷模式，但是我们可以对照一下自己团队执行的敏捷的边界究竟在哪。

 

项目级敏捷，基本上只有开发人员在敏捷，执行着迭代和自动化系统集成的工作，一般自动化也不太彻底。往外扩展就是版本级敏捷，把设计人员以及测试人员纳入进来一起进行敏捷，但是这两种敏捷都有一个问题是敏捷的边界没有达到GA态，也就是说迭代出口或者说是敏捷的出口产品是没办法直接交付的。再往外扩展就是产品级别敏捷，把需求分析人员涵盖到敏捷团队中，其对应着持续交付，也就是产品经过了产品级敏捷之后会到达GA态，是可以批量交付的。但是以上三种敏捷形态的边界都没有把客户涵盖进来，而商业级敏捷就是要联合客户一起敏捷，其对应的边界就是只要客户一个idea，经过了商业级敏捷之后这个idea就能直接变成功能上线了，这个和目前互联网的模式就非常接近了。

 

通过敏捷边界的划分很明显的看到，工程师文化为什么容易诞生在互联网公司，而传统型的公司几乎没有，就是传统行业企业的敏捷边界大多数还停留在项目级敏捷的阶段，研发人员离客户和用户非常遥远，少有话语权，自然难以形成工程师文化。

 

但这至少给我们研发团队指明了一条通往离用户越来越近的路，就是敏捷边界外扩。

 

精细化用户思维

随着大数据处理技术的发展，用户思维已经不仅仅是简单的跟用户聊聊天就可以了，逐渐产生了精细化的用户思维，比用户更了解用户，直达用户内心。以下几个案例可以帮忙理解什么是精细化的用户思维：

 

• 今日头条通过分析用户点击及阅读时长，不断推荐用户感兴趣的内容给用户；

• 沃尔玛在顾客结账的时候，如果发现顾客的商品里含有纸尿裤，那么就会随机自动打印出一张奶粉的优惠券给顾客；

• 大型超市里边的水，其实都不贵，甚至亏本，因为水是价格敏感的商品，顾客如果发现水的价格偏高，就会认为整个超市的商品价格偏高；

• 电商平台顾客买了商品，下面会有“猜你喜欢”的商品推荐，高达30%的商品是通过这个推荐功能卖出去的。

   

技术手段在未来的管理中将会扮演越来越重要的作用，利用技术手段更好的服务用户将是趋势。

 

用户思维的边界

以上种种似乎在说明只要用户提的需求就必须满足，做产品之前只要做一下市场调研就可以了，其实不然。

 

首先市场调研存在样本范围是否足够大是否能代表多数人的问题，即使调研样本足够大，但是用户反馈的和自己内心真正想的是否一致也是个问题，这次的美国大选就是一个典型的例子。

 

福特曾经说过，如果要去马路上问大家需要个什么东西，大家一定会说需要一个更快的马，而不是汽车。所以用户思维本身也存在着边界，特别是对于跨越式的创新产品，往往更依赖技术洞见，而非市场调研。

 

案例小结

案例一讲的内容比较多，核心内容就是拉近研发和用户的距离，首先就是开发模式中需要增加用户维度，虽然传统行业客户是入口，但是用户才是留存及获得下一个入口的手段，对于打磨产品至关重要。其次敏捷边界外扩，联合客户一起敏捷。第三，用户思维已经发展到非常精细化的程度，不再仅仅局限于做用户访谈，通过各种技术手段帮助我们比用户自己更了解他们。最后，用户思维本身也存在着边界，市场调查并不总是可靠的，我们要识别出边界和坑在哪里。

 

 

04 案例二 把自己当做第一个用户，取悦自己

 

你最快能找到的第一个用户是你自己。我们常犯一个错误，就是一边在抱怨离用户太远，一边却连自己这个用户都没有利用好，做出来的东西连自己都不满意。

 

关于取悦自己，我们应该都有过这样的经历体验，曾因为自己写过的一篇文章、画过的一张画、设计过的一个方案、写过的一段代码而觉得身心愉悦。取悦自己首先关乎思维方式的转换，从告知思维转变为打动思维。告知思维就是做完了一个功能，只是告诉自己或者告诉其他人我做完了，我有了这个功能，而打动思维则是做的这个功能是否能够的打动自己，只有打动了自己才有可能打动大家。

 

古斯塔夫·勒庞在其著名的心理学著作《乌合之众：大众心理研究》一书中阐述：“群体的理解能力差，但行动能力强”。所以针对这一理论，对于团队或者群体的行动可以使用适合的流程引导、约束，使得产出最大化，但对于理解、创造、灵感类工作，需要鼓励个人行为。比如：流程能保障版本质量符合迭代出口要求，但是无法预测有人能在转测时就做到了“零缺陷”。这是一种远超团队标准，无法用普遍质量曲线描绘的结果。

          

取悦自己的行为属于个体行为，甚至往往是灵光突显。创意和想法是宝贵的财富，我们对于取悦自己的行为一定要给予及时鼓励，创意一旦被发现，加以必要规范化后引导到团队，发挥群体的行动力，回报最大化。

 

在我们项目过程中，就有一个典型的发现个体的取悦自己行为，鼓励并推广到团队的案例：

 

• 取悦自己行为：在项目开发过程中，有一个系统需要大量的采用报表系统，团队成员比较新，大家各自写各自模块的报表前端展示，开发人员小张，开始在任务之余提取出了一套非常实用的前端公共组件，自己使用过后个人感觉特别好，上报给主管。

        

• 及时奖励：主管意识到这个是一个非常好的创意，立即给小张申请了公司的”及时奖励“，并取消了他下个迭代的story任务，专心完善这项工作。

          

• 回报最大化：团队进行全体重构，提取出8大前端公共组件，节省代码量700 * 38 LOC。

          

通过这套方法，我们还在项目实践过程中针对具体问题，不同场景，尝试了多种优秀敏捷实践活动“L型团队的打造”、“看板迭代”、“日报引入今日心情”、“交叉迭代”、“技术回顾会”，取得了非常好的效果。

          

我们很容易发现，一个伟大的产品，好像都有一个不断取悦自己的产品经理。比如乔布斯之于苹果，张小龙之于微信。他们都在做自己产品的第一个用户，他们的产品首先要取悦自己。他们坚持着自己产品的理念，苹果的突破、极致体验，微信的克制、不打扰。所以一个高度取悦自己的行为，如果跟公司的当前流程不符，建议首先需要质疑的是公司的流程制度，而不是一开始就一味迎合。

 

案例小结

最快能找到的第一个用户是你自己，所以首先要打动自己，并且要善于发现团队中取悦自己的行为，引导到团队实现创意价值最大化，另外任何伟大的产品一定是取悦自己的。      

 

 

05 案例三 平台靠创造用户价值演化而来

 

在引出第三个案例之前，我们先来看下周鸿祎在他的《我的互联网方法论》一书中提到的一段话：“互联网里的平台都不是做出来的，都是积累起来的，是在为用户服务的过程中形成的，最开始都是从一个点做起”。

 

我理解成平台不可能是一开始就设计好的，甚至都不能说是优化来的，因为优化往往仍然是从自己的角度出发，平台必须具备演化的能力，顺着创造用户价值的枝干不断进化得来。

 

项目背景：光伏行业第一个业务版本尾声，开始投入专注平台打造，以图复制20个行业。

 

这是一次对商业级敏捷的探索，首先完成从无到有的孵化，在一个行业找到一个客户，我们跟客户一起做业务，从客户的角度一起想问题，从需求，设计，开发，测试，交付各个环节甚至团队招聘都是一起完成的，和客户形成紧密的利益共同体。第二步完成从1到N的复制，复制到不同的行业，进一步完成API,SDK。最后形成生态，组成合作伙伴联盟，建立和合作伙伴的营销，分成机制。

 

案例小结

即使是做平台同样需要用户思维，帮助客户创造用户价值才是平台真正的价值。另外平台源于演化，而非一开始的设计，熟悉技术的都知道平台本身就分为两种形态，一种是用户量巨大需要考虑并发量的，另一种用户量很小但是业务吞吐量巨大的。最后就是联合客户一起敏捷和客户组成利益共同体。

 

文章最后，引用一句乔布斯的话“我对做过的事情感到自豪，但我对决定不做的事情同样感到自豪。”

 

互联网行业现在通过MVP、精益等手段对这句话已经践行的挺好了，但是传统行业属于重灾区，合同是按照功能清单签订的，往往在签订合同时功能越多越好，根本不会关心功能越多，质量会存在风险，可能无法聚焦真正的价值功能等等问题。有一个技巧就是研发团队在接产品经理的需求的时候，需要产品经理把哪些功能是客户愿意花钱买的，哪些功能是自己吹牛吹出来的附赠品划分出来，研发聚焦那些客户愿意花钱买的功能，做出一个模型之后，给客户看一下，再来看接下来是否还需要做那些看起来其实不太重要的功能。