登录注册
最新博客
最新资源下载
企业级SaaS产品的精益之路2017版
把生命浪费在美好事物上2018-08-01 09:17
什么是价值？精益的思维方式把价值定义为“向顾客提供利益”，除此之外的任何东西都是浪费。
如果能发现和定义什么是有价值的，并能快速交付价值，产品也许就能在竞争中有更多选择。
如何发现和定义价值？
一般情况下，我们尝试通过各种方式建立一套可持续地商业模式，通过这种商业模式提供产品和服务，然后推向市场。如果市场反馈不好，我们就尝试花更多时间认真地评估我们的商业模式，然后重新推向市场。问题是：要是还不行呢？继续增加研究需求的时间？总觉得哪里不对。
我们花了很多时间争论应该做什么，我们也花了很多时间裁剪需求，把需求变小，分步推向市场，可是这样够了吗？需求池里面依然有大量的需求堆积着，我们花大量的时间调整优先级，研发资源总是不够用，市场依然反馈平平，负责人觉得团队不够努力应该996，研发团队努力提升质量憋屈地开发了一堆卖得一般的功能。可是客户到底要什么呢？
我们如何找到客户到底要什么？关于做什么的争论是有益的，但是无论花多长时间争论，都不及用户的反馈来得有效，如果我们能更多更快地通过用户反馈来验证结果，也许就能更快地找到价值所在。
《精益创业》中提出了“开发——测量——认知”的循环，首先做出假设，然后为验证假设开发一个MVP，定义好这个MVP的验证方式，然后投入市场进行测量，获取测量的数据，接着依据数据来分析假设是否正确和是否有其他发现，根据分析结果调整策略，然后进行下一个假设，接着重新开始循环。
如果我们能减少这个循环的成本，加速循环的过程，我们就能以更小的代价，尽快地找的对于用户有价值的假设，从而找到对的方向，做对的事情，更快地做。
影响SaaS产品的三个因素：成本，收入，增长
收入大于成本，可能就盈利了，如果还能快速增长，那就完美了。那什么影响了成本，什么影响了收入，增长指的是什么？
收入
收入 = LTV * 客户数量
如果我们可以增加LTV（客户的终身价值）和客户数量，就可以扩大收入。
LTV=ARPU x单个客户的平均生命周期 – 服务客户的成本
影响LTV的因素有ARPU，单个客户的平均生命周期和服务客户的成本，如果我们能够增加ARPU和客户的生命周期，同时降低服务客户的成本，我们就可以提高LTV。
ARPU是每月每个客户带来的平均收入。SaaS产品，客户带来的平均收入跟客户的消耗额正相关，客户数量越多，消耗额可能就越接近销售额，消耗额跟用户的数据量和产品的价格正相关，客户消耗的资源越多，产品的价格越高，客户带来的消耗额越高，客户带来的ARPU也就越高。同时，如果消耗额和客户的业务总量是正相关的，SaaS产品对客户的粘性也会加强，对于降低流失率也有帮助。
客户数量 = 引入的潜在客户数 * 销售转化率
我们如果能够提高引入的潜在客户数量和销售转化率，就可以提升客户数量。
成本
成本 = CAC + 研发成本 + 一般性成本 + 售后支出
如果能降低这四个因素，就可以降低成本。
CAC=（销售与营销的总成本 + 定制成本）/客户数量
影响CAC的因素有销售成本，市场成本，或者现在我们可能会遇到的大客户的定制成本（这里特意列出定制成本，是因为为了满足每个大客户的各种需求而维护多个版本，或者让客户的这些需求互相融合，需要付出的成本很值得重视，成本会随着客户的数量几何级数的增长），但是这么算实在太麻烦也很难区分哪些能算CAC，哪些不能算，因此就简单用这个方式来计算就好了。如果能降低总的销售与营销成本和定制成本，同时提高客户数，CAC就可以降低。
售后支出 = （故障赔偿金额 + 故障维护成本）* 故障数量
研发成本和一般性成本的增长都还是线性或者可控的，在这里就跳过，直接来看售后支出吧。
故障赔偿金额跟我们承诺给客户的赔偿金额和故障的严重程度有关，故障维护成本和我们的服务效率有关，服务效率又和产品和团队的成熟度有关，故障数量和故障严重程度跟我们产品的质量有关，而质量也跟产品和团队的成熟有关。这个成熟度包括团队的产品的生命周期，服务流程，开发流程，各种规范，团队成员的经验，团队的配合程度，等等。
因此我们要减小售后支出，可能需要在团队的整体能力上有所提升，从而提高产品质量和服务效率，而不只是团队成员的数量上的增长。成员数量上的提升可以降低业务快速推进带来的质量和效率上的妥协，但是同时也会带来整体协作和平均个人能力的下降，因此也是一把双刃剑。
除了CAC，其他成本的占比会随着客户数量的增加而减少，当LTV > CAC，就可以把LTV - CAC的盈余继续投入市场和销售，不断增加客户数量，形成一个正向循环。LTV-CAC的盈余越多，有可能带来的增长也就越多（当然也会遇到增加投入，但是客户增长并没有变多的情况，这时候可能就需要考虑换方向了）。反之，如果LTV < CAC，那么就需要尽快摆脱这种局面，否则即使有外部投资，也无法让亏损收敛，我们期待的LTV和CAC的关系应该如下图：
增长
增长 = 订单增长量 * 订单单价 + 新增产品销售额
新产品有助于销售的拉动，但是在新产品上的投入可能会降低在原有优势产品上的投入，原有产品又需要持续强化和升级来扩大优势提升订单单价，增加销售和营销投入来增加订单量，但是也不可能持续提高销售和营销成本和研发成本，这样总成本就没法降低，因此资源的优先投放始终会是一个核心问题。
我们重新审视一下影响收入，成本和增长的这些因素：
我们要提高：
- 客户平均消耗额
- 单个客户的平均生命周期
- 引入的潜在客户数量
- 销售转化率
- 团队成熟度
- 订单增长量
- 新增产品
我们要降低
- 服务客户的成本
- 销售和营销的总成本
- 定制成本
- 研发成本
- 一般性成本
增加引入的客户数量和销售转化率，就会增加客户数量，持续提高就会提高订单增长量，而增长是判断我们的战略是否正确的重要指标，因此这两点极为重要。
我们需要不停地尝试，通过观测上面的这些因素，来找到对的战略。
作为网易这样体量的公司，我们的产品化之路常常是由于我们有某个领域的技术积累，积累到了一定时候，尝试着推向市场，在技术上我们比一般的创业公司有优势，但是劣势也是在于我们不能像一般的创业公司那样随意地调整产品。一方面，我们的产品需要对内支撑内部产品，另外一方面又需要对外满足外部市场多变的需求。因此，这些指标的观测也应该融入对内支撑的部分。
建立“开发——测量——认知”的循环
为了更快地寻找到价值，需要在原有团队运行模式的基础上进行改变，逐渐形成“开发——测量——认知”的循环，首先需要建立数据反馈机制，然后需要建立形成认知循环的组织能力，然后分析结果调整假设，让循环运行起来。
建立数据反馈
建立同期群数据反馈
定价体系也决定了同期群的统计方式，客户付费方式可能包含：
- 包月
- 包年
- 包量
- 按使用量扣费
根据前面对SaaS产品影响因素的分析，我们需要非常关注的几个指标，我们每个月依据这些指标来判断我们的健康程度：
- 客户平均消耗额：
- 如果客户平均消耗额的增长达不到预期，我们就需要思考如何提升，是要改变定价策略，还是提供更多的产品服务来提升用户的消耗，客户是否把他的数据都放入我们的服务，客户是否还有什么顾虑的方面，我们提供的服务是否有让客户不满意的地方。
- 客户平均生命周期
- 如果客户平均生命周期低于预期，我们应该关注每个月转化的客户数是否大于每个月流失的客户数，我们的产品和服务是否有什么问题，产品的质量是不是有什么比较大的问题，是否有某个行业发生了重大的变化导致某一类的客户流失得比较厉害，我们是不是需要开拓新的行业。
- 引入的潜在客户数
- 引入的潜在客户数是否有增长，如果没有增长我们就需要考虑是否增加市场的投入，如果增加了市场的投入依然看不到增长，我们就需要考虑是否采用了合适的市场策略，是否找了符合我们产品的用户，还是我们选择的目标客户其实并不多，还是我们的产品需要转型。
- 销售转化率
- 销售转化率是否有提升，如果没有提升甚至下降，我们就应该关注销售团队和产品团队是否有比较好的配合，是否得到了足够的支持来提升销售转化率，销售团队的人手是否充足，是否是由于引入的客户数量变多导致销售团队来不及处理导致的。
- 客户数增长
- 如果客户数的增长少于预期，我们就需要关注前面的4个指标，是否有哪个指标不符合我们的预期。客户的增长从一定程度上反应了我们是否真的找到符合市场需求的产品方向，我们的假设是否成立。笔者在一个活动中问《精益数据分析》的作者，一般应该有多少的增长，得到的回答是：每周5%的增长。也许ToB产品的影响因素更多，但是每周5%的增长也许是一个不错的参考。
- 销售和营销的总成本
- 在定制成本还没有的时候需要关注总收益是否大于销售和营销的总成本，从而关注LTV是否大于CAC，如果CAC过大，就要仔细检查市场和销售的投入产出比是否合理，研究当前的模式是否有问题，当初的假设是不是验证失败，需要尽快调整策略让LTV大于CAC，这样才有可能持续下去，否则获客越多亏损越多。有一个参考是David Skok（在一家名为Matrix Partner的投资公司从事风险投资工作，观点源自几位来自不同SaaS公司的CEO和管理层）提到的客户全生命周期价值（LTV）要大于3倍以上的CAC。
每一项指标增长或者减少，我们都需要尽可能找到背后的原因，找到因果关系，这样才有助于我们做下一个决策或者假设。
建立用户体验数据反馈
我们常常会对网站的页面进行改版和优化，因此需要建立每次修改之后的实际效果反馈。以下几个指标也是我们需要经常关注，尤其是在改版之后需要重点关注的：
- 注册转化率
- 毋庸置疑，最重要的就是为了这个
- 落地页的跳出率
- 跳出率升高，改版可能就存在问题
- 页面停留时长
- 停留时长并不是越长越好，toB产品主要目的是为了节省使用者的时间。但是太短肯定是有问题的，比如页面上存在Bug，比如页面被某些人刷了，笔者就遇到过几个IP近1000的页面访问，页面平均停留时长不足2秒。
- 热点图
- 新增加的功能和按钮是否真的有人使用，用户关注和常用的功能有哪些，是否可以考虑换一下位置。
- 浏览器分布
- 不同浏览器的兼容和覆盖会占据不小的资源，因此依据这个数据进行取舍也许是不错的选择。
- 页面的下游页面
- 看用户的操作路径是否符合我们的设想
设计组织能力
把问题分层，依据不同角色的职责，拥有的信息量，专长的方面，把“开发——测量——认知”循环的过程分解到不同层级的组织角色上，同时保证在横向上的同步
- 战略层：由各部门总监组成，需要解决方向的问题，做出假设，定出优先级，分析反馈结果，最后调整策略。
- 管理层：由各部门主管组成，需要解决资源分配的问题，依据战略层定下的假设和优先级分配资源，执行验证并收集反馈结果。
- 执行层：由各个虚拟团队组成，需要解决快速交付的问题，依据管理层分配好的资源和任务，快速地完成任务得到结果，每个虚拟团队可能由产品，测试，开发等多个角色组成，甚至有时候为了满足一个关键性的客户需求还需要加入销售人员。
加速“开发——测量——认知”的循环
建立合适的迭代周期
迭代周期能够控制反馈的频率，一个迭代就是一次反馈的机会，找到合适的迭代周期很重要。
大的迭代意味着更多的工作内容，更多的返工，更多的问题，更多的干扰，这些更多会随着迭代周期的变长而快速上升，而且会因为一个小的问题而延迟所有的部分：团队做了ABC三个功能一起上线，却因为C功能的一个问题，导致已完成的AB得一起等着。
小的迭代带来的好处就是能够尽早地发现问题，减少已经完成但是没有交付的价值，但是太小的迭代有可能还不足以让问题暴露出来。
以下的这些周期是根据笔者团队的情况逐渐调整出来的：
- 战略层的迭代周期：双周为单位，即使这样，1年也只有27次的反馈和调整的机会。
- 管理层的迭代周期：以周为单位，每周反馈，调整和同步。
- 执行层的迭代周期：以周为单位，让工作内容尽可能在一周之内可以交付，一方面笔者做过统计，团队1周完成的任务比2周甚至以上的任务效率更高，Bug也更少，另外一方面，也强迫团队把任务尽可能地拆小成1周能独立上线。现在由于有持续部署的存在，理论上来说，每一个小的改动都可以持续地发布和部署，这方面笔者还在学习和思考如何让持续部署能够落地，现在DevOps的热门程度已经足以吸引世界各大互联网公司，如果能够解决持续部署的问题，执行层的效率会有极大的提升。
建立分析根源问题的文化
依据数据分析，发现了问题，就需要对问题进行分析，常见的就是5Why方法，通过问为什么，来找到问题的最根源，定位到是什么导致了数据的变化。通过处理根源问题来真的影响到数据的变化。还有其他的工具，比如鱼骨图，可以和5why的工具一同用起来。
比如线上Bug就是典型的需要进行5Why分析的案例，通过5Why分析，我们找到线上Bug产生的根源问题，分析的目的不只是为了找到技术上的问题，也是为了找到流程的问题：
- 是什么导致了这个Bug？我们的账号过期了
- 为什么我们的账号过期了而我们没有准备？因为我们之前和其他团队提过，以为其他团队就接手了。
- 为什么其他团队接手了最后还会导致这个问题？因为他们忘记了
- 为什么他们忘记了我们没有发现？因为我们上线前没有检查，我们的软件系统也没有自动检测的功能
- 为什么我们上线前没有检查，我们的软件系统也没有自动检测的功能？因为我们没有上线检查这个流程，也不清楚哪些需要检查，我们的系统也没有这个账号的检查机制。
OK，到这里，我们就可以做一点事情了。
每发现和解决一个根源问题，团队就会获得成长，团队成熟度就会提升，效率就会提高，一旦组织形成了这种寻找根源问题的文化，组织就能够从错误不断地学习和完善，团队就能够自我适应各种情况。
提升研发团队的工程能力
团队的工程能力的提升会极大地加速循环的提升。软件的Bug发现的越早，为解决Bug花费的时间和成本就越低。笔者和odd-e的专家交流的时候也讨论到产品间最后的竞争可能会落到团队的工程能力的提升上。
下面的这些工程工具可以很好地帮助团队提升工程能力：
- UT和软件静态检查工具：可以让软件的Bug在编译阶段就可以被发现
- CI的使用：可以让团队更多的提交代码，更快地获得反馈，更早地发现问题而不是等到最后全都完成了才做集成和发现Bug。
- 结对编程：看起来是两个人做了同一件事情，产出少了一半。但以笔者实践的经验和现在经常举办的coding dojo的情况来看，两个人同时写一份代码，可以让写出代码更美，Bug更少，写出的代码量也更多。在结对写6小时代码后，笔者快要累瘫了。
- Review：最方便的在团队内部互相学习提升的方式，同时可以尽可能地让问题早点被发现。
- TDD: 看起来是个测试工具，其实是个软件设计工具，TDD的方式让笔者写过一些设计不错的代码，逻辑清晰耦合低。但是TDD在软件从零开始就可以使用，否则等到后期在用起来就比较难了。
- ATDD：很好的需求驱动的开发工具，可惜的是笔者没有见到过用得很好地团队，因为软件的逻辑如果复杂，测试用例可能也会比较复杂，测试用例本身可能就需要自证，这时候就很考验团队如何把测试用例写得简单。
高效创新组织的设想
通过减小团队规模和增加团队数量来增加试错的机会和提升组织效率，通过测试团队来保证质量，另外一方面通过一个测试委员会来做一些宏观调控。通过让创新团队对自己的产品和功能负责，提升团队的效能和创造性。
- 为了保证原有产品的持续演进和对内支撑，继续保持一支团队或者一组团队维护
- 建立小型的创新团队，每个团队由4名开发和一名产品经理组成，团队负责开发新的产品和功能，并且自己负责完备的功能测试。
- 新产品的创意需要向战略评估委员会提出并包含验证策略，由委员会进行可行性评估，但委员的主要任务是作为第一批MVP的用户提供反馈，让小团队能够自主高效地运行，尽可能少地干预这些创意。
- 战略评估委员会还负责需求池里的优先级排列。
- 测试团队主要负责测试工具的提升，持续交付系统的维护和探索性测试。
- 上线评估由测试团队和产品团队出具测试数据，战略评估委员会确认上线，这步在完善了持续部署之后可以考虑取消。
- 创新团队不一定都要全都自己想创意，有很大一部分工作是完成需求池里面优先级最高的需求。
总结
精益的核心是要消除浪费，所有对用户没有价值的工作都是浪费。
史玉柱曾说：“一个企业付出最大的成本、最大的浪费并不在于他的实际操作，实际上决策失误所付出的代价是最高的。”柳传志也说：“做正确的事，比把事做正确更重要”。虽然我们不能做到完全没有浪费，但是我们应该用更少的代价更快地找到用户的价值，用更快的速度交付价值来减少浪费。探究如何获得产品的成功也是一门科学，我们要做的不只是建立精益的思想，而是建立精益的组织，从而帮助产品的成功。精益没有完美状态，现在的模式也只是适合于当下，我们需要通过持续改进来不断地解决新的问题。
本文来自网易实践者社区，经作者曹靓授权发布。
分享至：
