在上一篇文章里，笔者讲述了自己在产品研发团队组织结构选择上的一些思考，详情请参看上一篇文章《LeSS is More – 大规模敏捷开发框架LeSS实践（一）》。团队存在的目的和意义在于能够交付对客户有价值的产品，在这篇文章中笔者将和你一起探讨如何设定合适的产品目标以及关键结果引导产品的方向。
探索&交付
产品研发过程通常可以分为探索域和交付域。探索域关注客户的需要，定义做什么；交付域关注如何将人通过合适的方式组织在一起，以合适的工作方式，采用合适的技术，在合适的时间周期内，保质保量的交付产品，也就是怎么做。
需要注意的是探索&交付是一个持续循环反复的过程。这里需要关注几个点：
1.如何界定探索域和交付域？
2.从探索域向交付域的信息是什么？
3.信息批量大小如何？
4.从交付域到探索域的反馈是什么？
5.一个循环的周期如何？
思考一下上面这几个点，有助于我们理解传统开发模式和敏捷开发模式一些重要的不同点。敏捷宣言背后的十二条原则中有两条是这么说的：
1.我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。（Our highest priority is to satisfy the customer through early andcontinuous delivery of valuable software.）
2.经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。（Deliver working software frequently, from a couple of weeks to acouple of months, with a preference to the shorter timescale.）
简单说敏捷开发模式更倾向于小批量，短周期，频繁交付可工作软件获得客户价值反馈以及时响应变化。有了客户的反馈才有了调整，有了调整才能及时应对变化。一定程度上反馈周期的长短决定了对变化感知的频率，对产品的相应调整和交付能力决定了对变化的响应能力。在瞬息万变的时代里适应变化的能力往往决定了一个产品的生死。所谓的敏捷性就在于适应变化的能力。公司依赖产品创造价值，产品由团队合作共同交付，产品的敏捷性是我们必须追求的果，而单个团队的敏捷性是产品敏捷性一个潜在的因，更重要的是与产品相对应的整个交付组织的敏捷性。
借用《Specification by Example》里的一张图，在很长的一段时间里，人们往往更加关注交付域的Build Right，而往往忽视了探索域的Right Product。成功的执行一项毫无意义的计划是导致失败的致命原因。记得有句话说选择比努力更重要。那么如何才能知道我们正在构建一个Right Product呢？
精益创业
在所谓的VUCA时代里，谁是产品真正的客户，什么是客户的真正问题，哪些是对客户真正有价值的东西往往是不确定的。即使做过充分的客户开发，在没有将可工作的软件交与客户之前，所有的一切都是我们的假设，我们也许永远不会在一开始就知道。（当然那种只在意交付产品而不在意产品价值的产品不在这个讨论范围里）。
假设往往是不可靠的，回想一下自己的工作生活中有多少因为错误的假设导致的问题。分享一个笔者的糗事：2017年的杭州敏捷之旅笔者作为杭州敏捷社区建设者负责广告赞助这块的接洽，一个朋友介绍了一个潜在的赞助商给我。于是笔者很高兴的和对方聊了起来，从11月16号开始，各种赞助方案，各种赞助权益，聊的好不热烈，好不开心，最终确定了整体赞助方案。到了12月1号，笔者把支付宝账号给到了对方，让对方将赞助的费用打到账户上来，对方最后的问题是让笔者把大会的简介发他看一下，笔者屁颠屁颠的发了2017杭州敏捷之旅链接给他，对方竟然问了一句说：“不是XXX大会么？”对方竟然一直以为是另外一个大会的赞助（实际上该大会早已经结束了，并且还不是杭州敏捷社区主办的），而笔者一直以为对方是想对敏捷之旅的赞助！后来笔者翻了一下聊天记录，双方从11月16号到12月1号，竟然从来都没有提起过所要赞助大会的名字。不管对方真实的考虑是什么，笔者是基于赞助敏捷之旅这个假设去聊的。如果最重要的假设不成立，一切也就没有了意义。
当可工作的软件/产品真正交付给客户，客户与产品的互动可以为产品提供反馈和数据，合适的反馈和数据往往帮助我们验证我们对产品的假设。精益创业里希望可以花最少的力气、最短的开发时间，经历一次完整的开发-测量-认知反馈循环，以完成一次经过实证的认知学习。引用《原则》里面的两个原则：
1.进化是宇宙中最强大的力量，是唯一永恒的东西，是一切的驱动力。
2.不进化就死亡。
精益创业期望在一个完整循环中通过不断的验证假设，不断的消除产品中高风险的部分取得持续的进化。当然进化的结果可能是不断的增强也可能走向灭亡，但即使失败，最好也是快速失败。什么最宝贵？时间啊！
反馈循环按活动顺序是：开发-测量-认知，但我们制定计划的时候工作却是相反的：先确定验证的目标是什么，再确定需要如何评估是否达成目标，最后确定需要开发什么样的产品来进行实验，并取得评估反馈和数据。那么如何确定目标以及如何评估是否达成目标呢？
产品OKR
一个产品通常会经历三个阶段：
1.将问题和解决方案匹配起来；
2.将产品和市场匹配起来；
3.扩张。
第一阶段的核心问题是有没有值得解决的问题。这时候往往需要对目标客户以及利益相关者进行观察和访谈，去发现客户真正的想要解决的问题，他愿意花多大的代价来解决这个问题，以及他期望在什么时候可以解决这个问题。对于笔者团队来说一个有利的条件是，产品面对的客户来自于公司内部，最终用户也在公司内部。相对于外部客户/用户而言，我们可以更方便地进行更频繁和深入的观察和访谈。这有利于挖掘出真正的值得解决的问题。现实中的问题往往错综复杂，这里需要注意的一个点是要抓住客户最最痛的那个点，这也是产品的从0到1时最最重要的目标。产品失败的原因可能有很多，其中一个也许是产品目标太多，当我们什么都想做的时候往往什么也做不好。LeSS is More！如何简明扼要的描述产品目标呢？
这里简单介绍一下OKR。“OKR是一套严密的思考框架和持续的纪律要求，旨在确保员工紧密协作，把精力聚焦在能促进组织成长的、可衡量的贡献上”（注：引用于《OKR 源于英特尔和谷歌的目标管理利器》）。简单理解，OKR主要帮助我们回答两个问题：我们要做什么（Objective）？我们如何知道是否达成了目标的要求（Key Result）。这里借鉴了一下OKR的形式定义了团队产品目标。
小结
产品研发过程通常包括探索域和交付域，过去人们往往更关注交付域，即如何保质保量的交付需求&产品，而往往忽视交付产品价值的反馈。而在一个VUCA的时代里，谁是产品真正的客户，什么是客户的真正问题，哪些是对客户真正有价值的东西往往是不确定的。在没有真正的交付客户之前，一切都是假设。精益创业提出了开发-测量-认知反馈循环，期望花最少的力气、最短的开发时间，以完成一次经过实证的认知学习，验证假设，持续进化。在产品从0到1的第一阶段需要将问题和解决方案匹配起来，首要的问题是：如何确定值得解决的问题？如何确定合适的产品目标引导产品前进？我们可以采用OKR的方式定义产品的目标以及关键结果，从而驱动精益创业的认知反馈循环，不断的推动产品进化。生存或者灭亡，这是个问题。
作者：于旭东，网易敏捷教练，专注于公司内部敏捷产品研发实践与培训，擅长精益产品搜索，敏捷需求管理，敏捷测试等技术。具有超过10年的敏捷产品研发经验与组织敏捷转型经验；杭州敏捷社区建设者，2016 rgional Scrum Gathering大会组织者以及话题评审者，AgileTour,Agile China,TiD等大会话题分享者；CSM/CSPO/CSD/CSP/PMP。
