网易 SaaS 产品精益之路 | 从越来越多的内容安全事件说起
作者：互联网
作者简介
曹靓 网易易盾项目管理总监，CSM/PMP，9年Scrum各角色经验，多年Nokia通信研发经验，熟悉LeSS，熟悉CI，曾任网易新闻个性化推荐项目经理，此时正在网易易盾致力于加速用户需求转化为价值。
前言
非常高兴有机会跟大家分享整个产品在产品化过程中遇到的问题和解决的思路。今天分享的话题主要是这五个关键词：
第一个是背景，我们为什么做产品化 第二个是内外，产品化过程中遇到内部和外部矛盾的问题 第三个是建立，如何建立机制适应这样的问题和解决这样的问题 第四个是加速，建立机制之后我们如何加速解决上面的问题，适应快速的变化 第五个是下一步，我们竞争对手也在变，整个市场也在变，我们需要跟着一起变，我们需要明确下一步的计划。
一、背景
1.1 网络内容安全与痛点
这是整个网络的情况，现在内容安全事件越来越多，大家投诉也比较多。最近很多互联网公司都被处理，隔一段时间就会爆一个直播网站被关掉，大部分是这些问题造成的，61.9%的问题来自于色情图片或者文字。
这些是常见的APP软件，但是被放了大量的广告、大量的垃圾邮件、开发票，还有很多男生喜欢但是会影响很多女性用户体验的东西，这些是常见的垃圾类型。比如在做互联网运营这些很常见的，淘宝这两天被警告了，也是像这样的问题。
发垃圾内容的不仅仅是一些散兵，还有更专业的团队，他们可能通过机器，甚至人工智能的方式去发垃圾内容。这类人知道变种背后的规则，甚至知道机器深度学习的漏洞。
如果用人来做检查，一方面跟不上增长的速度，另外一方面跟不上24小时的速度。如果仅仅是影响一些用户体验的问题那就算了，但是会影响到整个企业的生存情况，有大量的直播企业会因为这个原因被关门，主播被处理等等。
1.2 易盾的解决方案
面对上面的问题网易提出这样的解决方案。
网易在反垃圾方面做了好多年，我们可以做产品化给大家提供服务，帮助大家解决这样的问题。
二、内外
在产品化过程中会遇到一些问题，有来自外部的恶意竞争，也有公司内部各阶层对项目吐槽的问题。
2.1 外部竞争
刚开始切入这个市场的列表和产品组合只有我们有，过了一段时间发现竞争对手跟我们是一样的，做一些跟我们相近的产品，产品列表跟我们很接近。
可以看到在同样的渠道上面，一些竞争对手甚至以很低的价格卖，参照我们的价格打对折甚至免费。刚开始我们测试竞争对手的东西，发现他们有些东西做不到但我们可以做到，但是逐渐发现他们也可以做到了。同时黑灰产更专业了，这些是我们遇到的外部问题。
2.2 内部吐槽
我们内部也有很多的问题：
做不完，产品经理需求池里面很多东西做不完，开发团队也做不完； 优先级，产品经理花很多时间讨论优先级的东西； 一般，销售总监被吐槽，为什么产品刚开始不好卖，很久没有客户，销售总监说产品很烂不是卖的不好； 996，CEO说要996，所有团队要加班； 憋屈，研发经理最憋屈，都已经这样还怪我们做不好
2.3 归根结底的问题
这些问题的背后有非常多我们想做的东西，所以我们需要思考清楚这些问题。
什么对客户最有价值？我们做反垃圾的接口，提供一个API大家调用返回就知道这是不是一条垃圾信息，但是仅仅做这个就够了吗？不同的行业，不同的客户他们有什么样的需求，他们仅仅是要调API就可以吗？甚至运营的需求他们有没有？
怎么快速交付价值？怎么保证高优先级的功能先做，并快速地交付？算法团队和工程团队怎么配合？各个角色之间怎么配合？怎么从上到下保证大家的目标一致？
产品的核心价值是什么？易盾是什么？我们要解决什么样的问题？我们最擅长做什么？我们的长期目标是什么？
怎么知道做的对不对？通过什么来判断我们的策略对不对？怎么来判断我们内部哪个环节需要提升？
最核心的是前两个问题，如果能够解决前两个问题，那么后两个问题也能够迎刃而解。因此我们需要能够快速的发现和交付价值，想象一下如果做的每一个产品在决策一周之后可以上线，两周之后能够得到整体的数据反馈，那做决策可以任性一点，可以根据数据决策很快判断当时这个决定是不是对的。
三、建立
我们需要建立一套机制实现这样的结果，我们努力朝着这个方向前进。
3.1 组织问题及变化
一开始的时候我们研发团队，要做产品化于是出现了市场，出现了销售，开始有产品经理，有运营，然后技术总监这样的角色。
刚开始的时候开发团队自己决定做什么，到后来每一个角色不停的提各种各样的需求。开发团队跟大家常见的问题是这样的，谁大声听谁的，因此我们第一个要解决的问题是组织的问题。
我们需要分三层，战略、管理和执行。
战略层要处理的问题是定战略，实际上是解决方向的问题。现在每一个销售总监、市场总监、产品总监这些人会聚在一起，隔一段时间就要看一下我们的方向是不是正确的，根据反馈下来的数据看我们做的是不是对的。
管理层需要解决的问题是资源的分配，根据战略层定好方向和目标，做什么不做什么合理分配资源。
执行层需要解决的是如何能够把需求转化为价值，上面定好的需求尽快转化为价值交付给客户。
打通用户的反馈渠道，我们从三个阶段去进行。
首先我们需要打通售前和销售阶段的反馈渠道。一开始的时候需要建立一个统一的需求列表，让各方面需求统一在这个需求列表上面，在统一的需求列表上面排定所有优先级。其次打通产品阶段的用户反馈。产品经理依然需要跟销售一起拜访客户，拜访潜在客户，拜访老客户，知道老客户怎么用产品，知道新用户可能有一些新的潜在需求。最后打通运营阶段的用户反馈。离客户最近的是运营，运营也会提大量需求，甚至有些运营可以透过产品经理要开发团队帮他们解决这个问题，但是我们依然需要把运营需求统一在整体的统一需求列表里面，统一排优先级。
3. 2 核心数据反馈
经历了组织的变化，进行组织调整和打通一些反馈之后，我们需要有更明确的一些数据的反馈。
先看一下 SaaS 影响的三个因素:
收入
成本
- 增长，订单增长量
第一个因素是收入。收入是由两部分组成，第一是用户的终身价值，用户跟我们签合同之后每个月付钱，付了多久，这些钱累加在一起是多少，是由客户周期内付费额和单个客户平均付费周期决定的，单个客户付费额和产品定价相关的，产品生命周期跟客户的行业和我们提供的服务好坏相关。第二是客户数量，引入潜在客户数，这部分由市场负责的，因此是一个市场很重要的指标。销售转化率这部分是由销售负责的的，但是销售转化率仅仅是一个参考并不是硬性指标，因为销售有他的销售周期，比如Q1 、Q2、Q3，每一个季度可能不太一样。
第二个因素是成本，成本由获客成本、售后支出、研发成本、一般性成本和客户服务成本组成。售后支出是故障赔偿以及故障维护成本；获客成本是营销成本和销售成本加定制成本。
第三个因素是增长，订单增长量，有多少客户付费。新增产品销售额很重要，当发现老产品增长有问题，可能需要思考一下，我们的产品做得怎么样，这个市场有没有这么多客户，需不需要寻找新的市场。
重新审视一下这些因素，我们需要降低的是服务客户成本、销售成本、营销总成本、定制成本、研发成本和一般性成本，需要提高的是客户的总消费额，客户平均生命周期、销售转化率、产品质量、订单增长和新增产品。
我们根据这些因素建立我们自己的核心数据，第一个是客户的平均消费额，客户在 SaaS 产品里面，通常情况下，就好象联通或者移动的流量包一样，用的越多你的包越大，你付费额越大，而且由于客户付费习惯是用完才充钱，所以付费额和销售额是成正比的。因此客户消费额很重要，如果让客户尽可能多消费，就可以把整体的销售额提上去。
销售额和营销的总成本、新增客户数、销售转化率和引入潜在客户数，这是依据我们的产品现在所处的段，因为属于比较初创的阶段，最关注这些指标的核心是增长，有可能到下一阶段我们更关注是其他的一些内容。
上图是我们去年某一段的消费额，消费额是我们最核心的指标，这个指标可能由于时间的变化有调整。但是这个指标是我们最关心的，大家可以看到上面基本没有变化偶尔有些波澜，往往是因为周末，所以我们考虑为什么客户消费没有上去，客户把数据传过来了吗？我们仔细看一下是不是每个客户把符合客户体量的用户数据传过来，还有我们产品价格有没有问题，是不是有长尾客户充了钱但是用的少，是不是我们服务做的少，要不要调整客户价格的体系，提供更多的服务满足客户的需求。
下面是我们客户来源的统计，我们把客户从第一次接触我们产品到最后转化为正式用户分这么多阶段。每一个阶段有来自于不同渠道的客户，根据渠道、阶段可以知道哪一个渠道来的客户他的质量最好，投入产出比最高，可以在哪个渠道投入更多的钱。甚至发现在某个渠道上投更多钱但客户并没有增长，是不是少一点投也不会掉下去。
有了核心的数据分析之后我们需要看一下整个官网的页面数据：
注册转化率是官网最重要的东西跳出率，我们做落地页需要知道用户来了之后是不是立刻走了，需要知道每一个渠道客户跳出率怎么样，我们可以知道这个渠道是不是有问题
页面停留时长也很重要，不能太长也不能太短。太长可能是因为我们网页有问题，比如用户上传图片卡在那里等很久；也不能太短，正常人为操作不会太短
热点图，我们做网站改版的时候，需要知道用户对你哪些元素感兴趣，改版之后，新增东西或者减少的东西是不是起了作用需要知道热点图。比如之前知道热点图最下面的点和其他用户的案例，潜在客户对这些比较感兴趣，所以把整个页面缩短，让客户比较快拖动到下面
浏览器分布，这一部分可以节省我们很多资源，有些浏览器我们就不支持了。
页面的下游页面，我们可以知道用户整个操作路径是不是符合我们的预期
上图是某一天某一个页面的停留时长，只有11秒，这是不可能的。我们打开页面，等一下操作一下都不可能只有11秒，而且跟其他相关页面和之前例子相比不是11秒，有可能是竞品来过或者特殊人员来过，而且那一天访问量特别大。左下方是我们的一个路径，基本符合我们的需求，也可以看到在某一个产品体验页面使用过的用户，如果停留时长符合需求，成为我们注册用户的可能性非常大，这个情况下我们需要把那个页面做更好的引导，优化那个页面。
我们刚才讲的那一系列是为了从组织建立这样的循环，战略层、管理层、执行层、收集体验数据、核心数据和用户反馈，通过组织上的调整形成这样的循环。但是从战略层定出它的创意、想法到管理层能够把这些想法分配出去，到执行层能够把这些想法完成，最后再能够把所有的体验和反馈收上来，这样的一个过程需要多久？我们怎样加速这样的过程的实现？
四、加速
上面讲的那些住要做的是调整组织、统一需求和建立数据反馈，接下来我们要做的是加速和减少一些其中的浪费。
4.1 产品研发的困境
正常情况下一个产品开发流程是这样的：需求过程、交互过程，中间为了保证进入下一个环节有相应的评审，包括中间测试也有评审。
但实际上是这样的，每一个环节都可能发现前面某一个环节的错误，于是你要返工，返到最前面。
因此之前的流程可能有很多问题，正常时候是变成这样，我们增加更多的检测环节。需求处理完成之后，让产品经理和其他的各个角色过一遍需求，过完之后交互、视觉要仔细评审。实际上会发现并没有解决问题，依然还存在这些问题，还是可能会造成更多的返工。
那问题出在哪里？
问题是前一个环节占用的时间过多，导致了没有时间来打磨这个环节的工作，所以会产生问题。增加了更多检测环节，其实前一个环节占用的时间会更多，于是每一个环节占用更多的时间，导致每一个环节都没有时间真正打磨你的东西，这是一个恶性循环，增加的环节越多，可能整个流程越来越恶化。
4.2 如何解决研发困境
针对上面发现的问题，我们需要做的是缩短迭代周期和缩短迭代的规模，尽可能拆的更小。如果确认和调整的东西更少，那返工的时间就更少。
在这个思路下我们建立了各个层的反馈周期。
战略层两周一个单位，战略层所有高层管理在一起开会，看一下我们之前制定的这些策略是不是对的，有没有新的反馈上来，有没有数据的变化等等。销售卖的好不好，市场这些指标是不是对的。管理层以周为单位，每一周在一起同步这周最重要的东西是什么，执行情况怎么样。执行层以周为单位，后面还有页面介绍我们整体的是以周为单位同步的。
然后就是建立分析根源问题的文化，这是我们真实的案例，上线之后出现问题，然后找到一些自己的问题，就可以做一些解决。
上面的图是提升执行层，一个人工智能团队会分两块：一个是工程团队，一个是算法团队。你问算法团队这个东西什么时候指标上升，他告诉你不知道；你问他什么时候可以做完，他说这个可以告诉你，下周做完，但是什么时候有效果不保证。工程团队则会告诉你下周可以做完，开发时间有明确的期限，这是两个团队最重要的区别。
这样两个团队在一起怎么样能够更好的协作呢？
第一个独立演进，尽可能少接口调用对他们做一些分离。然后持续同步，算法是专业比较高的同事，但是他们也需要知道市场反馈怎么样，比如出现某一天突然爆量了、有一张图漏了、发现黑产，我们需要第一时间告诉算法团队立刻需要做出响应，不管用规则还是模型，算法团队也需要被这些东西同步到。算法团队结果我们没有办法控制，但是AB测试频率我们可以知道，我们需要知道算法团队多久更新模型多久做灰度测试。
在执行层我们有很多的角色一起协作，有产品、交互、视觉、开发，我们经过五个版本工作模式迭代变成现在的模式。五天做产品需求处理，五天做交互设计，三天视觉，五天开发，最后三天测试上线，这个是我们经过磨合之后的一个过程。
我们每周会做计划会议，这个计划会议前提是需求要准备好，就是要求产品交互视觉已经完成了。但是这个方式有一个BUG，当我有一个正常的需求放进来的时候，要经过很长的一段时间才能够上线。实际上这个是解决了资源利用率的问题，最大化利用各个环节的资源，并且让他们之间是无缝结合的。只解决了这个问题，但是并没有解决如何让某一个需求能够更快的流动起来。
前段时间我们负责人找到我说有一个需求，客户要一个报表的功能，就两个页面什么时候能够上线。我问重不重要，他说还好。我说还好什么意思，他说介于重要和不重要之间，我说重要的话我现在立刻组个虚拟团队，这周可以上线他说没必要这样会影响其他功能。我说不重要就正常开发，他说20多天怎么办，我说那把20天缩短一半，这个就是我现在在做的一件事情。我争取把这个版本时间变得更短，但是中间会涉及到很多改动，包括其他组织调整、新增人员、一些工具引入，这是现在在做的还没有做完。
整体的执行层都要以周为单位进行迭代，我们对外跨部门合作和自己内部小组协作是以周为代表迭代。比如沟通哪一周上线，就整体同步以周为单位横向同步。新产品一开始什么都没有，大家开始写代码，测试团队都没有，为了能够提升整体的交付速度，解决执行层的速度，减少整个循环的时间浪费，我们需要建立新的工具和工程帮助到这个环节的加速。如果有一天我们做到 DevOps ，这里东西就应该从零开始是这样做的，第一个UT和静态检查要逐渐建立起来，然后CI也逐渐建立起来。
不知道大家有没有这样的经历，花了很多精力开发的功能终于搞定了，四年之后开发的很牛的功能才开始卖。如果从GE角度考虑，开发过程中的浪费根本不算什么。如果把整个价值链拉长到销售、市场，拉到整个公司的级别，其实我们更应该关注如何消除在最前面的浪费，关注哪些事情我们不应该做，怎么样帮助团队判断哪些事情不应该做的？怎么能够给管理层或者是决策层有更多这样的机会做这样的判断。像刚才的迭代周期，其实一年时间我们一个管理团队两个月做一次判断，我们能够做这样的调整，缩短迭代周期不只是我们要缩短研发迭代周期，还要缩短整个反馈循环的迭代周期。
五、下一步
我们需要做的下一步，如何按照刚才提出的需求把整体迭代周期做的更短。我之前在诺基亚也是 LeSS 的发源地，我基于 LeSS 的理解，也是为了解决之前的问题，能够把整体产品迭代周期变得更短一些。从需求阶段进行更小的拆解，但是保证整体团队按照比较高的愿景执行。
于是产生上面这样的图，每个开发团队从整个需求池按照高到低领取需求。开发团队可以理解成一个小产品自主的公司，这个公司可以提出自己的需求，获取最上面的战略评估委员会的认可、投资和评估等等。如果提出的需求被满足了，可以把东西放在需求池里面。每一个开发团队要对自己的产品负责，这里面是没有测试人员的，测试人员在后面。测试人员负责线上整个产品的稳定、安全等等，最后如果QA同学认为可以通过了，可以上线，最后由战略评估委员会决定是不是上线这个产品，这个是我们下一步想做的一件事情。
对于持续改进方面，我们今天做的所有东西只是针对当下的问题和情况，市场在变竞争对手也在变，甚至自己内部组织构架、人员流失都在变化，因此我们要不断调整和学习新的东西，比如 DevOps 调整我们自己的策略，这样至少可以在市场上存活下去。
标签：需求,安全事件,SaaS,问题,精益,客户,产品,团队,我们 来源： https://blog.51cto.com/15127503/2660744