解析精益产品开发(二)——产品开发中的
价值7
information = 。

一个——，而
8bits——。

确定事件的信息量0 ——。

产品开发不可能排除所有的不确定性还保留任何价值。

正如管理学之父彼得
共舞”的艺术。

第一代iPhone采用了全新操作界面——多点触控、全新材料——大猩猩玻璃材质，和全新商业模式——运营商（AT&T）深度绑定，这些尝试带来了技术、生产和商务上的不确定性，同时也成就了产品与众不同的体验和非凡的价值。

在技术、产品和市场快速变革的今天，挑战不确定性和风险已经成为企业交付价值获得竞争优势的不二法门。

1.2 和商业目标相关的信息才能带来价值
信息承载产品开发的价值，但只是潜在价值。

只有通过达成商业目标，信息才能成为真正的价值，组织也只应该在能帮助达成商业目标的地方承担不确定性。

设想，苹果如果在第一代iPhone中尝试4G（LT E）通信技术，会带来更大的不确定性，然而即使成功了，也不能带来价值，因为当时还没有与之配套的商用LT E网络，事实上，第一代iPhone甚至没有支持当时已经流行的3G通信技术。

与商业目标无关的不确定性不带来价值，而且可能是有害的。

Google Wave刚推出时被Google和用户寄予了厚望，产品红极一时，但一年后却因未能吸引到足够用户而宣布停止开发。

Wave几乎加入了能够添加的所有功能，但用户并不买账，相反，过多的功能导致复杂的界面、模糊的定位和稳定性的缺乏，让用户远离Wave。

产品开发的目的是实现商业目标，而非完成功能。

产品的功能应该围绕有限和明确的商业目标展开，否则一方面会引发范围蔓延，造成项目执行和产品维护的困局；另一方面却无法实现核心目标。

Wave引入过多的功能而牺牲了易用性和稳定性，但用户还是普遍的抱怨，它不能满足自己的应用要求，它什么都能做，但作为协作工具它比不上Google Doc或Z oho，作为社交工具它比不
上Facebook或Google Buzz，作为通信工具它比不上Gmail 或已有的IM工具。

Scott Berkun曾经成功领导微软数个重大项目，包括奠定浏览器大战胜局的Internet Explorer 4.0，在其畅销书《项目管理之美》中他分享了一个曾经使用的需求管理实践——应用简单机制跟踪从目标到功能再到产品项的映射关系。

在这一机制下，每个工作项必须对应一个功能，每个功能必须对应一个目标，并且每个版本仅聚焦于有限数量的目标。

依据这一映射，团队可以明确判定一个新的工作项能否进入项目范围。

这既有效抑制了范围蔓延，又确保了核心目标的达成。

1.3 价值要在开发过程中持续发现
产品开发是一个信息积累和知识创建的过程，团队持续获取业务需求、市场环境、实现技术等方面的信息，深化认知、明确价值。

近年来，业界在如何让这一过程更加有效方面的实践取得
了很大
进展。

1.3.1 先期决策是传统项目管理的通用实践
传统项目管理强调预先计划和按计划执行。

如图㈠所示，团队拥有最丰富信息和知识的时刻是在项
目的末期，这也是最可能做出正确决策的时刻。

然而与之对应的是，绝大部分的决策在项目的早期做出，如设定产品需求、承诺项目计划和确定技术方案等。

此时的决策只能依据有限的信息和知识做出，却成为后期项目执行的基准。

过早的决策成为后来的约束，也降低了应对变化的灵活性。

图㈠先期决策
1.3.2 “延迟决策”比“先期决策”更符合产品开发的本质
敏捷和精益开发倡导“延迟决策”。

如图㈡所示，在迭代模式下，随着产品开发的进展，市场和技术环境发生变化，客户需求逐步清晰，成员对业务和技术的掌握越来越全面深入。

对应的，项目的决策也是分步做出的，项目启动阶段团队做出一些初始的决策，更多的决策则发生在后续迭代中，此时团队拥有更多的信息和知识，更可能作出正确的决策。

图㈡延迟决策
在《T he Principles of Product Development Flow》一书中，Donald. Reinertsen说：“产品开发成功的关键是：总是能依据最
新的信息作出经济上正确的决策，当信息变化时，决策也要相应变化。

”这就是延迟决策的意义所在。

至于延迟到什么时间，Mary Poppendieck的建议是“最后责任时
刻（T he Last Responsible Moment）”，此时再不做决策，将失去重要的决策选项，或系统将自动选择缺省方案（如不采取动作，或沿用既有方式等)，这往往也不是最优的决策。

Donald. Reinertsen的建议更加实际：“进一步的等待不能提高预期的经济结果时，就是应该做出决策的时刻了”。

采用谁的建议并不重要，重要的是理解延迟决策在经济上的意义，和创造延迟决策的可能性。

1.3.3 “延迟决策”还不够，“刻意发现”提高发现过程的有效性
在图㈠和图㈡中，信息积累和知识发现的过程被表示为一条直的斜线，这是一种简化表示。

而在现实中，这一过程是非线性的。

如图㈢右边的线，缺省情况下，知识发现更多集中于项目后期，因为此时得到的反馈信息更加真实。

我们称这种未经刻意计划的过程为“随意发现（Accidental Discovery）”。

随意发现是相对无效的，因为越是后期的信息和知识越难转化为真正价值，毕竟在
项目后期做出调整是很困难，且成本巨大的。

对应随意发现，Dan North提出了刻意发现（Deliberate Discovery）。

他指出项目初期，团队缺乏
业务领域、构建技术、遗留代码、工具等方面的知识，处于
对项目最无知的状态。

无知是产品开发的最大制约因素，这其中也包含对无知的无知，也就是不知道缺乏知识或不知道缺乏什么知识。

有意思的是，对于无知的无知往往让团队更加乐观而非更加谨慎，所谓“无知者无畏”。

被动的、基于已有知识的延迟决策是不够的。

团队应该在开发过程中通过有计划的活动，刻意地探索发现，最快和最大化的发现知识、消除无知，其中也包括消除对无知的无知，也就是尽快发现我们还缺乏哪些方面的知识。

这一过程被称为“刻意发现”，它增加并提早了软件开发的知识创建。

如图㈢所示，相比随意发现，刻意发现把发现的过程拉向坐标的左上方，更早和更有效地发现知识。

项目早期的快速原型、技术探索、最小产品发布等都属于刻意发现的实践，它们通过有目的探索活动，更早的积累知识，有力的支持了项目在执行、技术以及商务上的成功。

1.3.4 “经证实的认知”把“刻意发现”推向极致
“经证实的认知”源自近年来兴起的“精益创业”理念，它把“刻意发现”过程推到了极致。

《精益创业》一书的作者Eric Ries 把创业定义为：“在极端不确定的情况下开发新产品和新服务”，在移动互联的今天，这越来越成为产品开发的常态，不管是新创企业或是成熟企业的产品开发部门都是如此。

Eric认为学习是创业的重要部分，而最有效的学习必须是以从客户那里收集到的真实数据为基础的，并把这种学习称为“经证实的认知”。

“精益创业”提倡先向市场推出极简的原型产品，然后在不断地试验和学习中，以最小的成本和有效的方式验证产品是否符合用户需求，
并灵活调整方向。

“经证实的认知”的核心是开发（build）->测量（measure）->认知（learn）的循环。

如图㈣，循环从概念开始，它往往是基于对市场、客户和技术的假设，我们并不完全确信它是可行的，能解决客户问题，并为市场所接受。

在这一循环中，第一步是开发验证概念的最小产品；第二步：基于最小产品获取市场、用户的反馈和测量数据；第三步：用数据验证假设，深化认知和建立新的概念。

再进入下一循环，不断构建、优化产品及对其的认知。