从 Marty Cagan 那获得启示

发表于 更新于 分类于

3ySjTf.png

周末的时候看了一篇好文 做产品真的难于上天！ 从文后的链接听了一遍 Marty Cagan 的演讲，受益良多因此记录一下。

frustration with Lean And Agile

对于「精益」 (Lean) 和「敏捷」 (Agile) 方法的挫败感。从我的角度上也是对敏捷最终留下了一个站会的形式，从剥离的外在的敏捷看来只有2个核心点。

  • 「要频繁的发布」，频繁的意思是「至少每两周发布一次」。如果你每月或每季才发布一次，就算你自称敏捷，你其实没有获得任何敏捷的好处。好的产品团队甚至每天发布好几次，就是所谓的「持续交付」 (Continuous Delivery)。也不是说大家都要做持续交付，但若你不是每两周发布一次，这会是很大的问题。

  • 「团队要被赋权且被问责」，被赋权的意思是「交由团队来找解决问题的最佳方法」。举例来说，不是由管理层告知团队「请串接日本当地LN 公司的行动支付」，而是告诉团队「我们眼前看到的问题，是太少日本当地人购买我们的产品，海外转换率实在太低了，请你们解决这个问题」。如果串接了日本当地LN 公司的行动支付，没有解决这个问题，团队就要继续探索其他方案。

第一点毋庸置疑，从 Wiki-敏捷开发 也可以轻易的发现，但是对于第二点是一个极为隐藏的问题，敏捷区别于其他方法的最为本质的区别是从面向项目的方式变化为面向人的方式。

从敏捷宣言中

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

我们也发现了，敏捷对于人的价值更为重视。而人的价值就伴随着权利与责任，很多团队被告知要更加敏捷，但其实管理层一直给团队「待完成的功能清单」（传统意义上的产品路线图Product Roadmap），每月或每季都跟团队说「请做这些功能」，这在任何意义上来说都不是敏捷。

说完了敏捷，再看看《精益》

Lean 有五大原则

  1. Identify Value识别价值：从顾客的角度定义什么是价值（顾客愿意花钱的）
  2. Identify ValueStream识别价值流：找到那些增值的步骤（往往一个公司只有5%）
  3. Create Flow流动起来：让价值流动起来（通过消除浪费）
  4. Respond toCustomer Pull根据顾客的需求时间、量来生产（拉动式生产）
  5. Pursue Perfection不断完善以上过程（PDCA）

而 Marty 的总结为

  • 「我们要快速学习才能创新」，创新源自于我们能够尝试多少点子，因为我们知道大部分的点子都行不通。（这里对应着是识别价值）

  • 「我们得要消除浪费」，所谓的浪费就是花了4 个月才发现「这不是解决问题的好方法」，这就是浪费。在创业阶段我常看见的浪费就是「我们正在做一个MVP 」(Minimum Viable Product 最小可行性产品)。然后我就会问「太好了，那可以让我看看MVP 吗？」结果他们就说「正在做了，还要4 个月」。坦白说，这根本不是MVP，只是个半成品、是不成熟的产品。真正的MVP 只需要4 小时或4 天，不是4 个月。

不同周期的产品研发

探索阶段

此阶段我们要搞清楚「探索该打造的产品」，我称之为「产品探索」(Product Discovery)。这个意思是要找到一个产品方案，符合以下四个条件：

  • 对用户有价值(valuable)：就是顾客会买单
  • 易于使用(usable)：意思就是顾客能自己搞懂如何使用
  • 可被打造(feasible)：是我们知道如何打造
  • 商业上可行(viable)：有市场可行性，包括这个产品，包含宣传、销售、客服，也有收益

在这个阶段，我们交付 「原型」 (prototypes)，而不是「产品」 (products)。

产品交付阶段

交付工程师有自信的产品，让我们可以真正开始运营这个产品。这个最终产品要符合的条件是：

  • 稳定(reliable)
  • 可扩展(scalable)
  • 高效能(performant)
  • 可维护(maintainable)
  • 支援多国语言且本地化(internationalized and localized)

作者注： 就我的经验看来，国内的研发经常会混合着这两种模式，同时需要满足以上两点的产品对于传统命令式的软件开发为主（其实也不存在探索阶段），对于创业公司，第一种情况是团队小心谨慎的闭门工作了4个月，发布产品后发现这是错误的产品。第二种情况是团队超级迅速的发布了好几次产品，其中有些成功了，但也创造了极大的技术成本，打造了难以维护、难以扩张、很低效能的产品，得再花4个月重构，令团队无法继续迅速发布。

探索阶段就是build the right thing，然后交付阶段是build the thing right。失败的软件总是有类似的状况,Marty Cagan在INSPIRED书中，介绍了产品失败的4大风险，分别是:

  1. 实行性风险(Feasibility Risk)：团队明确需求，但手边并没有解决问题的技术，或技术尚未成熟，就是「我们知道要做什么产品，但是做不出来」的状况
  2. 易用性风险(Usability Risk)：顾客想用这个产品，但不知如何使用，或太少人克服使用门槛，就是「产品做出来了，但是好多顾客看不懂、不会用」的状况
  3. 价值风险(Value Risk)：这个产品并没有解决顾客需求，为顾客带来价值，就是「产品做出来了，某些顾客也会用了，但后来都不继续用，因为没有满足需求」的状况
  4. 商业可行性风险(Business Viability Risk)：这个产品对公司没有商业价值，或无法在市场竞争中存活，就是「产品做出来了，顾客也爱用，但是无法赚钱，或拿不到更多预算与资金，或无法赢过竞争者」的状况。

一些问题

怎样让老板们信任Product Team

我试着跟产品团队说，你们的工作不只是告诉大家「为何这些不可行」，你们的工作还必须告诉大家「这些构想更能解决问题、更有机会成功」。如果今天的课题是「国际交易支付量过低」，产品团队除了告诉大家「串接PayPal 不是个好方法」，还必须告诉大家「PayPal 以外还有哪些方法」可以解决问题，这才是优良产品团队和新手产品团队的差别。优良的产品团队知道，自己还必须提出可行的方案，而且这些方案要更有机会成功。

产品不仅仅要告诉老板们，为何我们觉得这些不行，重要的是为了解决问题，我们还要一些其他办法。

我们可以在很多公司，见证这种做法的影响力。因为，只要产品团队开始展现这些能力，高管们开始认定这些团队是「问题排除者」 (Problem Solver)，而不是「阻碍者」 (Blocker)。只会验证点子(validating ideas) 的团队是阻碍者，你可以在很多公司看到这样的症状。

满脑子只有单一方案？

很多团队接着采取的行动，就是继续制作原型(prototyping)、继续20、30、50 次迭代，直到他们用完所有的时间，或直到放弃。其实，你真正想要理解的是「总是有很多种解决问题的方法」，所以当你在做少量规划的时候，你要确保自己记得「这里有5种解决问题的方法」，至少要把这件事记在心上。我们认为其中一个方法最好，所以从这里开始，但如果我们没获得成果，我们就要尝试下一个。

对于产品的解决之道可以有多种渠道，而对于软件的解决之道？倒是存疑。

只有无尽的产品优化？

他们只在做这件事情。我可以告诉你，如果这是你唯一做的事情(指不断的优化产品)，你正在一个缓慢死亡的道路上，因为这只是「捕捉价值」 (value capture) 的行为，就像提高价格一样。这是件好事，没什么不对，但如果你只做这件事，你只是逐渐消耗价值而已。我们身为产品人的工作，是要创造更多价值，大余我们捕捉到的价值。产品探索(Product Discovery) 就为了「创造价值」 (value creation)，产品优化(Product Optimization) 只为了放大价值。

产品管理的核心能力

  • 对用户和顾客的深入研究
  • 对用户操作的深入研究
  • 对生意/商业模式的深入研究
  • 对产业的深入研究

终章

这一篇讲产品为主，然后在我的观点中，我认为复合型的人才是未来的发展的主要方向，当程序员准备去生产产品的时候，我们也应该从产品的角度去了解这个产品为何是现在这番模样。