分析精益产品开发之看板开发方法

61/61解析精益产品开发（一）——看板开发方法看板（Kanban）开发方法是近年来最热门的敏捷和精益开发方法。越来越多的案例表明，它能够改善协作、优化治理，显著提高交付速度、质量和灵活性。看板开发方法的规则简单，但其有效实施依靠于对原理的理解、对原则的坚持和实践的应变。本文将整体介绍看板的原理、原则和差不多实践。1.看板的原始含义看板源自精益制造。尽管具体实践不同，看板开发方法和精益制造中的看板原理是一致的。从精益制造动身，能够关心我们更好地理解看板的本质。1.1看板源自精益制造精益制造是上世纪50年代起，从丰田公司实践中演化出来的，又被称为“丰田生产方式”。1990年麻省理工的JamesP.Womack等几位教授提炼总结了丰田的实践，出版《精益生产方式——改变世界的机器》一书，精益制造的概念开始为世人所认识和效仿，直至今日，它仍然是最先进的制造方式，是制造业共同追求的目标。丰田生产方式之父，大野耐一讲：“丰田生产方式的两大支柱是‘准时化’和‘自働化’，看板是运营这一系统的工具”。看板是丰田生产方式的核心工具（如图㈠）。图㈠丰田屋——丰田生产方式相关厂商内容大数据驱动的金融业务创新华为团队构建与体系变革的创新模式腾讯代码治理平台架构和开源实践批改网：基于语言大数据的英语作文自动批改服务系统建设和运营猿题库：大数据时代的在线教育相关赞助商全球架构师峰会，7月17日-18日，深圳大梅沙京基海湾大酒店。立即报名。看板（Kanban）一词来自日文，本义是可视化卡片。如图㈡，看板工具的实质是：后道工序在需要时，通过看板向前道工序发出信号——请给我需要数量的输入，前道工序只有得到看板后，才按需生产。看板信号由下游向上游传递，拉动上游的生产活动，使产品向下游流淌。拉动的源头是最下游的客户价值，也确实是客户订单或需求。图㈡看板拉动制造过程图㈢是一个典型的看板——装在塑料套里的一枚卡片，包含的信息是“什么地点，需要什么产品，多少数量”图㈢生产中的看板1.2基于看板的拉动系统实现准时化准时化又叫即时生产（Justintime-JIT）是丰田生产方式的一个支柱。看板形成拉动系统，各环节依照看板信息，仅在在需要的时刻，生产需要数量的必要产品。这将带来生产库存的降低，甚至实现生产过程零库存。库存又被称为“在制品（WIP——workinprogress）”，是差不多开始但没有完成的工作，它们堆积在工序间或临时仓库中。库存降低带来的直接收益是：1)降低成本：库存减少增加了运营现金的使用率，同时降低治理和仓储开销。2)缩短交付周期：消除或缩短产品在工序间的库存等待时刻，缩短了从开始制造到交付的周期时刻。3)提高制造过程的灵活性：在低库存水平下，调整生产的打算更加容易。降低库存更重要的作用是暴露制造系统中的问题。图㈣中的湖水岩石是一个经典隐喻，水位代表库存多少，岩石代表问题。水位高，岩石就会被隐藏。生产系统中库存多时，设备不良、停工等待、质量不佳、瓶颈过载等问题都会被掩盖。库存降低后，这些问题都会显现出来。没有了临时库存的缓冲，设备运转不良或停工等待立即会凸显出来；没有了库存等待时刻，上一环节输出的质量问题也能即时得到反馈。这确实是所谓“水落石出”，暴露问题是解决问题先决条件，不断暴露和解决问题，带来生产率、质量以及灵活性的提高。图㈣湖水岩石效应1.3自働化自働化是丰田生产方式的另一支柱，它的准确含义是自动停机（Auto-No-Mation），指出现问题时（如某个环节有次品），机器能够自动感知异常，并赶忙停机或停下整个生产线。丰田认为，这相当于把人的智慧给予了机器，称其为“人字旁的自动化”，因此用“働”而非“动”字。图（三）比较了自动化与自働化在概念和实践上的不同。图㈤自动化和自働化自働化把质量内建于每一个制造环节，出现异常时，杜绝接着产出不合格产品，同时不把不合格产品输入到下一环节。这确实是“内建质量”（buildqualityin），而不是让质量依靠于最后的检测环节。其次，自働化带来“停止并修正”（StopandFix）的文化，发生异常时，赶忙停止生产，分析全然缘故，并加以解决，防止问题的再次发生。“停止并修正”是持续改善的基础。2.精益产品开发的进展以上我们简要介绍了精益制造（丰田生产方式）的框架和其中的看板实践，它既带来直接经济结果，又带来深层次的文化和思想变革。精益是制造业的革命，是既大规模生产之后的全新范式。精益思想的阻碍早已超越制造领域，精益服务、精益医疗，甚至精益行政都被广泛实践，产品开发也不例外。然而，开发和制造特点不同，决定无法照搬精益制造的实践。产品开发需要从自身特点动身，进展完备的实践体系。

产品制造产品开发阻碍工作对象具体、可见的物理产品抽象、不可见的信息产品开发的价值、价值流淌不可见，治理价值流更加困难。有必要采取适当的措施，可视化价值和价值流淌。完成单个任务的时长固定——完成前后两个加工任务的时刻相同，且能够精确预测。不固定——每一个开发任务差不多上全新的，完成的时长不同，且不能完全预测。在生产中能够追求或逼近零库存。产品开发中，由于任务时长的不确定性，零库存可能会导致开发步骤间的等待。不同任务的延期成本相同差不专门大在生产中一般采取先入先出（FIFO）的队列治理方式；开发中用需要应用比先入先出更灵活的队列治理方式，以优化经济结果。对可变性和错误的态度制造是重复的过程，消除可变性能够提高质量。不确定性(可变性)是产品开发价值的一部分，完全消除差异是不可能的产品开发必须同意不确定性，并通过必要的试错来验证它们，以增加价值。可变性不能完全消除，需要在考虑开发过程的可变性。精益产品开发概念出现于上世纪90年代，2000年后逐步成熟。这中间起到推动作用的代表人物有MaryPoppendieck，DonReinertsen和DavidJ.Anderson等。他们促进了精益思想和产品开发特征的结合。MaryPoppendieck是精益软件开发的早期推动者，她的思想在敏捷软件开发社区被广泛引用，2003年到2010年，Mary和他的夫君TomPoppendieck先后在三本书中总结了这些思想，并提出了操作建议。DonReinertsen致力揭示产品开发流的本质，并提出相匹配的原则方法。在2010年出版的“ThePrinciplesofProductDevelopmentFlow”一书中，Don提炼了精益产品开发的175条原则，这可能是迄今为止对产品开发最本质和深入全面的阐述。但面对175条原则，从哪里开始是一个问题。2006年在DonReinertsen的启发和鼓舞下，DavidJ.Anderson最早在软件开发中应用看板实践，其后不断完善，形成了看板开发方法，这是精益产品开发走向适用和普及的重要里程碑。看板的推广速度超过任何其它敏捷开发方法，Versionone的调查报告显示看板是增长最快的敏捷实践，2011年使用了看板的敏捷团队占24%，2010年那个数据是18%。2010年David在他的著作”kanban–SuccessfulEvolutionaryChangeforYourTechnologyBusiness”一书中，详细介绍了看板的价值、原则和实践。书中总结了看板开发方法的五个核心实践，它们是：可视化工作流、过程规则显式化、限制在制品数量、度量和治理流淌、以及协同改进。接下来，我们将以这五个实践为线索，介绍看板开发方法的概貌。3.看板的五个核心实践3.1核心实践1：可视化工作（价值）流产品开发的加工对象——信息——是抽象和不可见的，这提高了价值流的治理难度。看板开发方法把可视化工作流作为基础实践，先让价值和价值流淌具体可见，然后才是治理和优化。图㈥是看板开发方法中的一个典型可视化案例，被称为看板墙（Kanbanwall）。图㈥可视化工作流图中的每个卡片代表一个价值项，如：功能需求、缺陷、技术概念验证等。它们所在的列，表示其所处的时期。这些价值项，每通过一个时期（图中的列）都会产生新信息，价值得以增加。例如，需求通过分析时期，注入了新信息，价值更高。价值流是价值项从左至右的流淌过程，是信息的产出过程，也是价值增加的过程。价值流淌可能会被阻碍。比如，编码因对第三方接口错误而无法进展；测试因没有设备而停滞。图中，红色卡片是对问题和阻碍因素的可视化。标识阻碍因素并推动其解决，促进价值流淌。最终限制系统端到端流量的是系统瓶颈处的流量，改善端到端的价值流，必须从解决瓶颈问题开始。发觉看板墙上的瓶颈并不困难，找到最长的队列就能够了，这就和交通系统的瓶颈处，总是出现长长的等待车队是一个道理。上图中的队列出现在测试处，不难看出，测试是价值流淌的瓶颈。价值、价值流，以及问题和瓶颈的可视化，是改善价值的起始，也是其它看板实践的基础。3.2核心实践2：显式化流程规则显式化流程规则，是指明确定义和沟通团队所遵循的流程规则。价值项的“流转规则”是看板开发方法中最典型流程规则，它定义了一个价值项从一个时期进入下一时期所必须达到的标准。图㈦中，给出了某团队其中一项流转规则的实例，定义了从分析时期进入开发时期所必须达到的条件。“流转规则”的显式化，让质量内建于各个时期——这与精益制造中内建质量的思想是一致的。除各个“流转规则”外，其它重要的流程规则也能够或者需要被显式化，如，团队的协作规则、优先级的定义规则等。图㈦显程化流程规则流程规则显式化更重要的意义在于，它是“持续改进”的动身点和结果的载体。没有显式化的规则作为依据，讨论改进就没有基础，而变得主观和随意。改进的结果通常也需要落实到显式的流程规则当中，让改进稳步进行，幸免低效的反复。显式化规则不是为了限定团队的工作方式，而是为了关心团队更好的改进。这就像，丰田的生产现场必须有明确操作规程，但假如那个操作过程长时刻没有变化也同样是一个问题，因为，持续改进是精益思想的核心之一。3.3核心实践3：限制在制品数量限制在制品数量是看板开发方法的核心机制。如图㈧所示，列标题右面的数字标识了该时期同意的在制品的最大数目（进行中和完成的价值项的和）。在制品数目小于那个数字时，才能够从前一时期拉入新的工作。图中，分析时期的在制品限制数目是3，而实际在制品数目是2，能够拉入新的工作。测试时期的在制品数是3，达到了上限，就不同意拉入新工作。图㈧限制在制品数目限制在制品数量形成一个与精益制造类似的拉动机制。一个环节有空余的能力（在制品数目未达上限）时，从上游拉入新的工作，拉动的源头是最下游的交付或客户需求。与产品制造类似，通过拉动系统能够：1)加速价值流淌：限制在制品数量，减少了价值项在时期间的排队等待，缩短了价值从进入系统到交付的时刻，加速了端到端的价值流淌。2)暴露问题：限制在制品数量，让湖水岩石效应产生作用。它让过去被隐藏的问题，如团队协作不良、需求定义错误、开发环境低效、资源分配不均衡等得以显现。许多号称使用“看板”的团队，并没有限制在制品数量，他们因此也可不能得到上述收益。精益制造通过看板向上游传信号，拉动生产。而看板开发方法通过限制在制品数量形成拉动系统，缺乏这一核心机制就不成其为看板，对此，CoreyLadas

如此描述“复印的美元不再具备货币的内涵，因此不再是钞票；同样，缺少在制品数量限制的看板墙，也不能叫看板”。在制品数量的限制值及其演化，将在以后的文章中讨论。3.4核心实践4：度量和治理流淌快速、顺畅的价值流淌是看板开发方法的目标。快速流淌带来快速的价值产出和快速反馈，它对业务成功至关重要；顺畅流淌，意味着稳定和可预测的价值交付能力，这与流淌的绝对速度同等重要。度量为改善价值流淌提供方向参考，同时为改善的结果提供反馈。看板开发方法没有定义特定的度量方法，累积流量图是实际应用较为普遍的一种。图㈨是一个典型的累积流量图，左面的斜线是累积差不多开始的价值项（如用户需求）数目，右面斜线是累积完成价值项的数目。两条斜线的垂直距离表示某个时刻差不多开始但还没有完成的价值项数目，也确实是在制品的总计数量。两条斜线的水平间距表示价值项从开始到完成的周期时刻，也确实是从概念到交付的响应时刻，它是价值流淌效率的一个重要衡量。斜线的斜率反应的是价值交付的速率，也确实是每周能够交付的价值项数量。图㈨流量累积图累积流量是一个综合的价值流度量方法，能够通过它得到不同维度的信息。例如，我们设想限制在制品的数目，能够缩短周期时刻、而对交付速率阻碍有限。但实际效果如何还要通过事实来检验，通过实验和度量，图中的数据差不多验证了这一假设，让改进更有方向，结果更可衡量。同样的数据有不同的呈现方式，图㈩基于相同的数据，它突出了在制品数目和周期时刻的变化趋势，以及两者的关系。从图中能够看出，周期时刻的降低略滞后于在制品数量的降低，这符合精益理论，因为只有在积存的队列被处理完后，对交付周期的改进才能够显现出来。而图11反应的是系统流量（每周交付价值的数量）的变化趋势，为改进提供了信心。图㈩在制品数目和周期时刻图11周流量图以上只是一个度量实例。度量不是目的，而是治理和优化价值流的手段。关于特定的组织，度量什么应该由目标和现状决定。3.5核心实践5：协同改进（ImproveCollaboratively）应用可视化、限制在制品数量、以及价值流度量，能够暴露产品开发中的问题和瓶颈。但发觉问题还不够，重要的是如何去解决它们，对此看板开发方法给出了两个建议——团队协作和应用科学方法和模型。限制在制品数目本身就能够激发协作，例如在前面图㈧的看板墙，可能会出现以下的顺序场景1)测试遇到问题(如输入质量太差)而被堵塞，在制品数量达到上限2)因在制品数量达到上限，依照规则，测试不能从上游（实现）拉入更多的工作3)实现时期已完成的工作无法进入下游测试环节，实现时期的在制品数量专门快也达到上限4)实现要想开始更多的工作，就必须关注下游的问题，并做出反应，如提高本环节的输出质量，或者是给予关心5)实现和测试的协作使价值流淌更加顺畅图12协同改进图12是”kanban–SuccessfulEvolutionaryChangeforYourTechnologyBusiness”一书的封面插图，它反映了发生在看板墙前面的协同改进。看板开发方法的差不多假设是：产品开发的目标不是单个环节效率的最大化，而是端到端价值流的提升。看板通过拉动机制暴露了限制价值流淌的瓶颈，并激发团队协作，改善价值流淌。解决瓶颈问题的方案可能在瓶颈处，如临时加班、分配更多资源、或相邻环节的支持等。但专门多时候解决瓶颈问题的方案在不处，例如提高瓶颈之前环节的输出质量，调整职责分配，甚至是重新设计工作流。关于偶然出现的问题，只需要临时性解决方案。如突发性高负荷，能够通过临时的相互支持解决。而关于系统性问题，如持续的负荷不均衡，则需要长期的方案和更加系统和科学的模型指导，如系统考虑、精益思想、排队理论等，这些模型本身不属于看板方法的一部分，但它们让长期的改进有章可循，以后的文章，我将中深入地探讨其中的一些模型。4.总结：看板是变革方法DavidJ.Anderson如此定义看板开发方法：“看板定义了我增量、渐进地改变技术开发和组织运营的方法。它的核心机制是限制在制品数量的拉动系统，通过它暴露系统运作（或流程）的问题，并激发协作以改进系统。”这当中的核心是，看板并不是一个开发框架或流程，而是引领变革的方法。每个组织有自己特点，所面对的市场，使用的技术不同，经历和所处的时期不同，他们值得也应该拥有适合自身特点的方法流程。看板的实施正是从组织流程现状动身，首先可视化实际工作流并显式化流程；在此基础上，限制在制品数量形成拉动系统以暴露系统问题和瓶颈，度量价值流淌以发觉改进机会；并通过团队的协作，不断改进和演化出合适的流程、方法，实现一个高效、顺畅的产品开发价值流。适应组织的具体情况，和发觉合适的变革路径，这两点是敏捷实施的最大困难，看板给出了被证明可行的方案。这可能是看板能够在国外社区迅速推广并成功运用的缘故，而在国内，看板这方面的价值还远未被认识和发掘。这篇文章之后，我们还会从不同的方面，更加深入地介绍精益产品开发。它们是：-价值篇：解析产品开发中的价值和价值发觉过程-价值流篇：解析产品开发中流淌的本质，和价值流的治理-可视化篇：探讨面向价值和价值流的整体可视化方案-看板实施篇：通过案例介绍看板的实施步骤和实践细节-变革篇：从组织变革的视角讨论精益的实施、看板应用和持续改进-……感谢张凯峰对本文的审校。给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@。也欢迎大伙儿通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。差不多翻译成中文的我推举两本

1.《精益开发实战》，这本书专门简洁有用，从头至尾围绕一个成功的案例展开,读起来专门爽，也提供了大量的实践操作方法。

2.《看板》，这本书据讲差不多翻译好了，六月份左右出版，值得期待。这本是看板最权威的书，全面讲述了看板的理论和实践。

另外：MaryPoppendieck有三本关于精益软件开发的书，第一和第三本都有中文，Mary的书是专门好、专门全面，问题是多停留在概念层面，没有实践的人理解起来有问题。解析精益产品开发（二）——产品开发中的价值本文是《解析精益产品开发》系列的第二篇。第一篇中我们介绍了看板方法，看板方法关心组织持续改进，实现顺畅和持续的价值流淌。然而，只有基于正确价值的流淌才有意义，这是精益产品开发的前提。在本篇中，我们将揭示产品开发中的价值本质，并以此为基础，分享一个适合精益产品开发的价值定义和发觉实践——阻碍地图（ImpactMapping）。1.产品开发中价值的本质传统项目治理强调预先定义、分解和可能价值，以此为基础打算项目，然后按打算执行就能够实现价值。这一理念应用在诸如生产或建筑之类的工程项目上是有效的，但应用在产品开发上时就有问题。以瀑布模式下的软件开发为例，在项目前段，通常能够按打算进行，但为了满足进度要求，往往会让风险后移；在项目后段，风险和不确定性逐渐显现，项目出现困难和延期；更有甚者，假如交付的产品不符合客户或市场的要求，再完美地符合打算也是没有价值的。什么缘故在工程项目中有用的方法用在产品开发中就会出现问题？其缘故是产品开发和工程项目中价值的本质是全然不同的。1.1信息是产品开发的价值载体，它与不确定性如影随形工程项目（如生产或建筑）的产出是物理产品，价值由物理产品承载；产品开发的产出是方案，价值由方案中的信息承载。以“制作食品”和“制作食谱”来类比，产品开发相当于制作食谱，工程项目则相当于按食谱制作食品。制作两份同样的食品，得到两份价值。而制作两遍同样的食谱，可不能产生两份价值，因为它没有产出新的信息，价值也无从谈起。不确定性与信息及其承载的价值如影随形。贝尔实验的伟大科学家香农（Shannon）最早用比特（bit）来度量信息，并奠定了信息理论的基石。按信息理论，信息的量是对事件不确定性的衡量，表达为information=

。一个bit包含了0和1两种不确定性——，而1个byte包含256（0-255）种不确定性，其信息量为8bits——。确定事件的信息量为0——。产品开发不可能排除所有的不确定性还保留任何价值。正如治理学之父彼得•德鲁克在其经典著作《治理的实践》中所述：在所有关于以后的概念中，一定会失败的确实是那些“十拿九稳”、“零风险”等“绝对可不能失败”的概念。每一次产品开发都必须与过去有所不同，这意味着不确定性和风险，也为产品注入信息，带来潜在价值。TomDemarco在《与熊共舞》一书中把风险和不确定性比作熊，成功的产品开发是“与熊共舞”的艺术。第一代iPhone采纳了全新操作界面——多点触控、全新材料——大猩猩玻璃材质，和全新商业模式——运营商（AT&T）深度绑定，这些尝试带来了技术、生产和商务上的不确定性，同时也成就了产品与众不同的体验和非凡的价值。在技术、产品和市场快速变革的今天，挑战不确定性和风险差不多成为企业交付价值获得竞争优势的不二法门。相关厂商内容自适应学习与国内在线教育猿题库：大数据时代的在线教育大数据驱动的金融业务创新华为团队构建与体系变革的创新模式腾讯代码治理平台架构和开源实践相关赞助商全球架构师峰会，7月17日-18日，深圳大梅沙京基海湾大酒店。立即报名。1.2和商业目标相关的信息才能带来价值信息承载产品开发的价值，但只是潜在价值。只有通过达成商业目标，信息才能成为真正的价值，组织也只应该在能关心达成商业目标的地点承担不确定性。设想，苹果假如在第一代iPhone中尝试4G（LTE）通信技术，会带来更大的不确定性，然而即使成功了，也不能带来价值，因为当时还没有与之配套的商用LTE网络，事实上，第一代iPhone甚至没有支持当时差不多流行的3G通信技术。与商业目标无关的不确定性不带来价值，而且可能是有害的。GoogleWave刚推出时被Google和用户寄予了厚望，产品红极一时，但一年后却因未能吸引到足够用户而宣布停止开发。Wave几乎加入了能够添加的所有功能，但用户并不买账，相反，过多的功能导致复杂的界面、模糊的定位和稳定性的缺乏，让用户远离Wave。产品开发的目的是实现商业目标，而非完成功能。产品的功能应该围绕有限和明确的商业目标展开，否则一方面会引发范围蔓延，造成项目执行和产品维护的困局；另一方面却无法实现核心目标。Wave引入过多的功能而牺牲了易用性和稳定性，但用户依旧普遍的抱怨，它不能满足自己的应用要求，它什么都能做，但作为协作工具它比不上GoogleDoc或Zoho，作为社交工具它比不上Facebook或GoogleBuzz，作为通信工具它比不上Gmail或已有的IM工具。ScottBerkun曾经成功领导微软数个重大项目，包括奠定扫瞄器大战胜局的InternetExplorer4.0，在其畅销书《项目治理之美》中他分享了一个曾经使用的需求治理实践——应用简单机制跟踪从目标到功能再到产品项的映射关系。在这一机制下，每个工作项必须对应一个功能，每个功能必须对应一个目标，同时每个版本仅聚焦于有限数量的目标。依据这一映射，团队能够明确判定一个新的工作项能否进入项目范围。这既有效抑制了范围蔓延，又确保了核心目标的达成。1.3价值要在开发过程中持续发觉产品开发是一个信息积存和知识创建的过程，团队持续猎取业务需求、市场环境、实现技术等方面的信息，深化认知、明确价值。近年来，业界在如何让这一过程更加有效方面的实践取得了专门大进展。1.3.1先期决策是传统项目治理的通用实践传统项目治理强调预先打算和按打算执行。如图㈠所示，团队拥有最丰富信息和知识的时刻是在项目的末期，这也是最可能做出正确决策的时刻。然而与之对应的是，绝大部分的决策在项目的早期做出，如设定产品需求、承诺项目打算和确定技术方案等。现在的决策只能依据有限的信息和知识做出，却成为后期项目执行的基准。过早的决策成为后来的约束，也降低了应对变化的灵活性。图㈠先期决策1.3.2“延迟决策”比“先期决策”更符合产品开发的本质敏捷和精益开发倡导“延迟决策”。如图㈡所示，在迭代模式下，随着产品开发的进展，市场和技术环境发生变化，客户需求逐步清晰，成员对业务和技术的掌握越来越全面深入。对应的，项目的决策也是分步做出的，项目启动时期团队做出一些初始的决策，更多的决策则发生在后续迭代中，现在团队拥有更多的信息和知识，更可能作出正确的决策。图㈡延迟决策在《ThePrinciplesofProductDevelopmentFlow》一书中，Donald.Reinertsen讲：“产品开发成功的关键是：总是能依据最新的信息作出经济上正确的决策，当信息变化时，决策也要相应变化。”这确实是延迟决策的意义所在。至于延迟到什么时刻，MaryPoppendieck的建议是“最后责任时刻（TheLastResponsibleMoment）”，现在再不做决策，将失去重要的决策选项，或系统将自动选择缺省方案（如不采取动作，或沿用既有方式等)，这往往也不是最优的决策。Donald.Reinertsen的建议更加实际：“进一步的等待不能提高预期的经济结果时，确实是应该做出决策的时刻了”。采纳谁的建议并不重要，重要的是理解延迟决策在经济上的意义，和制造延迟决策的可能性。1.3.3“延迟决策”还不够，“刻意发觉”提高发觉过程的有效性在图㈠和图㈡中，信息积存和知识发觉的过程被表示为一条直的斜线，这是一种简化表示。而在现实中，这一过程是非线性的。如图㈢右边的线，缺省情况下，知识发觉更多集中于项目后期，因为现在得到的反馈信息更加真实。我们称这种未经刻意打算的过程为“随意发觉（AccidentalDiscovery）”。随意发觉是相对无效的，因为越是后期的信息和知识越难转化为真正价值，怎么讲在项目后期做出调整是专门困难，且成本巨大的。图㈢刻意发觉对应随意发觉，DanNorth提出了刻意发觉（DeliberateDiscovery）。他指出项目初期，团队缺乏业务领域、构建技术、遗留代码、工具等方面的知识，处于对项目最无知的状态。无知是产品开发的最大制约因素，这其中也包含对无知的无知，也确实是不明白缺乏知识或不明白缺乏什么知识。有意思的是，关于无知的无知往往让团队更加乐观而非更加慎重，所谓“无知者无畏”。被动的、基于已有知识的延迟决策是不够的。团队应该在开发过程中通过有打算的活动，刻意地探究发觉，最快和最大化的发觉知识、消除无知，其中也包括消除对无知的无知，也确实是尽快发觉我们还缺乏哪些方面的知识。这一过程被称为“刻意发觉”，它增加并提早了软件开发的知识创建。如图㈢所示，相比随意发觉，刻意发觉把发觉的过程拉向坐标的左上方，更早和更有效地发觉知识。项目早期的快速原型、技术探究、最小产品公布等都属于刻意发觉的实践，它们通过有目的探究活动，更早的积存知识，有力的支持了项目在执行、技术以及商务上的成功。1.3.4“经证实的认知”把“刻意发觉”推向极致“经证实的认知”源自近年来兴起的“精益创业”理念，它把“刻意发觉”过程推到了极致。《精益创业》一书的作者EricRies把创业定义为：“在极端不确定的情况下开发新产品和新服务”，在移动互联的今天，这越来越成为产品开发的常态，不管是新创企业或是成熟企业的产品开发部门差不多上如此。Eric认为学习是创业的重要部分，而最有效的学习必须是以从客户那儿收集到的真实数据为基础的，并把这种学习称为“经证实的认知”。“精益创业”提倡先向市场推出极简的原型产品，然后在不断地试验和学习中，以最小的成本和有效的方式验证产品是否符合用户需求，并灵活调整方向。“经证实的认知”的核心是开发（build）->测量（measure）->认知（learn）的循环。如图㈣，循环从概念开始，它往往是基于对市场、客户和技术的假设，我们并不完全确信它是可行的，能解决客户问题，并为市场所同意。在这一循环中，第一步是开发验证概念的最小产品；第二步：基于最小产品猎取市场、用户的反馈和测量数据；第三步：用数据验证假设，深化认知和建立新的概念。再进入下一循环，不断构建、优化产品及对其的认知。图㈣经证实的认知“经证实的认知”的执行过程是一个循环（图中的外圈），打算过程是另一循环（图中的内圈），它与执行的循环方向正好相反。也确实是，第一步：确定要验证什么样的概念；第二步：规划需要猎取什么数据来验证概念；第三步：决定通过构建什么最小产品来获得这些数据。这两个相反方向的循环共同构成了“经验证的认知”的完整实践。今天，云计算和产品服务化让产品公布模式发生了深刻变化，快速猎取反馈和验证概念越来越方便，好的产品可不能依靠于初始时一两个好创意。以用户为中心，快速有效地学习，不断调整和完善产品和服务成为产品开发的核心竞争力。“精益创业”的理念和实践在产品开发中被广泛实践，大到微信、微博如此的平台，小到各类细分应用，甚至硬件产品，都会通过持续公布产品，猎取用户反馈，不断调整方向，更好的解决用户核心问题，优化产品功能。“经验证的认知”为这一过程提供了理论依据和实践指导。2.一个价值定义的实践方法——阻碍地图（ImpactMapping）以上我们探讨了产品开发中的价值本质1）信息是产品开发的价值载体，不确定性为产品开发注入信息，带来潜在价值。2）服务于商业目标的信息才能成为最终价值3）价值要在开发过程中持续发觉，延迟决策、刻意发觉和经验证的认知让这一过程变得更有效。“不确定性”、“服务于商业目标”和“持续发觉”是关于产品开发价值的三个关键词。对产品开发价值本质的认知是基础，但只有把它们应用到实践中才有意义。下面将要介绍的“阻碍地图”确实是一个从产品开发本质动身的价值定义和价值发觉的实践。2.1阻碍地图解决的问题是什么？产品开发的任务是通过交付功能（或服务）达成商业目标，通常在组织中这意味着两个职能，一部分人关注业务——客户需求和产品目标；一部分人关注开发——用什么技术，如何样实现。为此产品开发一直要面对两个挑战：1）业务职能和开发职能之间的理解、沟通和协作的隔阂2）产品功能和业务目标之间的不一致以及关联的模糊图㈤阻碍地图要解决的问题如图㈤所示，阻碍地图要解决的正是上述两个挑战。2.2阻碍地图是什么？阻碍地图是GojkoAdzic总结和提炼自己及他人的实践后提出的，旨在关心组织更好地创建和沟通产品路线图和打算，确保功能交付和业务目标的一致，并提高应对变化的灵活性。2.2.1阻碍地图可视化了从业务目标到产品功能的映射关系产品是为人服务的，必须通过阻碍人的行为才能实现目标，这也是“阻碍地图”名称的由来。为完成从目标到功能的映射，阻碍地图要回答两个问题：1）对什么人产生什么样的阻碍能够关心目标的实现2）提供什么样的产品功能（或服务）才能产生如此的阻碍图㈥是一个阻碍地图的实例，它面向的业务目标是“6个月内，不增加客服人数的前提下，支持两倍的用户数”，以业务目标为核心，阻碍地图分为4个层次。图㈥阻碍地图实例1第一层：目标（why），也确实是要实现的业务目标或要解决客户的核心问题是什么。目标应该具体、清晰和可衡量。第二层：角色（who），也确实是能够通过阻碍谁的行为来实现目标，或消除实现目标的阻碍。角色通常包含1）要紧用户，如产品的直接使用者；2）次要用户，如安装和维护人员；3）产品关系人，也确实是尽管不使用产品但会被产品阻碍或阻碍产品的人，如采购的决策者，竞争对手等。第三层：阻碍（how），也确实是如何样阻碍角色的行为，来达成目标。那个地点既包含产生促进目标实现的正面行为，也包含消除阻碍目标实现的负面行为。第四层：功能（what），也确实是要交付什么产品功能或服务产生希望的阻碍。它决定了产品的范围。2.2.2阻碍地图显式化了从目标到功能映射背后的假设如图㈥，上述的映射关系中，事实上是基于两类假设的。1）功能假设：假设通过设想的功能能对角色产生期望的阻碍2）阻碍假设：假设对角色产生如此的阻碍会促进目标的实现例如，我们假设：对常见的问题提供论坛链接，能够引导用户更多的上论坛。同时还假设：假如用户更多的上论坛就能减轻客服的工作负载，从而服务更多的用户。在功能交付之前，这些假设还只是待验证的概念。阻碍地图把这些假设显式化出来，关心组织有意识地验证和修正这些概念，这与“精益创业”的理念是一致的。让假设显式化是“阻碍地图”的重要方面，MaryPoppendieck在“ImpactMapping”一书的序中讲：“阻碍地图是由连接缘故（产品功能）和结果（产品目标）之间的假设构成的，它关心组织找到正确的问题，而这比找到好的答案要重要的多”。2.2.3阻碍地图提供了一个共享、动态和整体的图景阻碍地图不应该专属于某个职能，也不应该是某一时刻的静态规划。开发过程中，团队持续交付功能，获得反馈及其它信息输入，深化对产品的认知。随着认知的深化，阻碍地图不断地被修正、拓展。这一过程需要各个职能的共同参与，阻碍地图是治理人员、业务人员、开发和测试人员共享的完整图景。关于业务人员，他们不再是简单的把需求列表扔给开发团队，并等着最后的结果。通过阻碍地图，业务人员和开发人员一同完成从目标到产品功能的映射，明确其中的假设，并在迭代交付中验证这些假设，当假设被证明或否定后，应该对阻碍地图做出调整，如接着加强或停止在某个方向上的投入，或调整投入的方式。关于开发人员，他们的目标不再限定于交付功能，而是拓展至交付业务目标。开发者除了明白交付什么功能，也了解为谁开发，什么缘故要开发。如此就能够更加主动和创新地考虑，有依据的做出决策和调整。关于测试人员，除了参与上面的规划和验证活动外，测试的责任不再局限于检查产品是否符预定的功能，而是验证产品是否产生了预期的阻碍。假如没有对用户产生期望的阻碍，即便完美符合功能定义，也不是高质量的产品。2.3一个阻碍地图案例下面我们用一个案例来展示阻碍地图的使用。设想一个团队正在开发一个跨平台知识治理应用，它要紧面向个人用户，但也有人把它用到企业的知识治理中。该应用缺省模式下是免费的，对收费用户提供额外的功能和服务。2.3.1完成阻碍地图的初始版本该产品团队在以后三个月内有多个目标，其中比较重要的是“增加付费用户的比例”。我们就以那个目标为例来应用阻碍地图。第一步：完成阻碍地图的第一层次——目标。“增加付费用户的比例”作为目标还不够明确，通过论证调整为：“三个月内付费用户比例从1%增加到1.5%”，它更具体同时加上了明确的时刻限制。但我们依旧要问：“什么缘故要增加这0.5个百分点？”，发觉更深层的目标是增加收入，而不是收费用户比例，否则通过减少用户数量也能够实现比例增加。最后目标确定为：“三个月内付费用户人数从820增加到1500人以上”，它足够明确，同时是能够度量的。第二步，第三步：完成阻碍地图中的第2和第3层次——角色和阻碍，也确实是考虑通过阻碍谁有助于这一目标的实现，以及如何阻碍。例如：阻碍已付费用户，鼓舞和促使他们积极的宣传所获得的便利，可能会吸引更多的潜在付费用户；阻碍现有免费用户，让他们意识到收费服务的价值，也可能会争取到更多的收费用户；企业用户也是一个可挖掘的资源，只只是团队对这方面的经验还特不有限，不确信要从哪些方面着手。但这没有关系，我们能够做出一些初始的假设，并在后续过程中加以检验和完善。第四步：完成阻碍地图的第4层次——功能，也确实是交付什么样的产品功能或服务来实现期望的阻碍。需要指出的是，并不是所有的阻碍都要通过开发产品功能才能实现，比如在那个例子中，为了让企业用户更方便地支付，最容易和最急迫的是为企业用户开具财务发票，它不涉及到任何开发工作。开始去做阻碍地图时，往往会发觉这种情况所占比例比想象的高专门多。这是好事，怎么讲我们要交付的是目标而不是功能。图㈦阻碍地图实例2如图㈦，通过上面四步，我们完成了阻碍地图的初始版本。它由各职能共同完成，或者由某个职能完成，再由大伙儿共同讨论、精化，团队会挑战阻碍地图中的元素和假设，但不需要纠结于每一个细节，它怎么讲是基于对产品、市场、客户以及技术，甚至是竞争对手的假设，不可能达成100%的一致。阻碍地图让这些假设可视地呈现出来，团队将在开发和交付过程中不断验证这些假设，并做出新的假设，演化阻碍地图。2.3.2规划路线图和打算一个产品可能会存在多个相关或细分的目标，需要多个阻碍地图。即便如此，依旧应该尽可能限定同时进行的目标的数量，在上一篇文章讨论看板时，我们明白限制在制品数量是看板的最核心实践。而限制同时进行的目标的数量，比限制同时开发的功能数量更重要和有效，它保证团队的工作最快地阻碍到业务，得到真实反馈。“保持专注，持续公布”正在成为产品开发团队的追求，或许FacebookCEO扎克伯格的办公桌面上的招贴“stayfocused&keepshipping”能给我们一些启发，照片是扎克伯格在Facebook提交IPO申请当天上传至自己的Facebook页面的。图㈧扎克伯格的办公桌面照片有了一个或多个阻碍地图，就能够开始制定产品路标和开发打罢了。例如，在图㈦中我们选择了一些高优先级的功能（打钩的项），作为接下来要完成和公布的内容，希望通过它们最快地接近业务目标，并验证重要假设，扫除实现目标的不确定性。这是一个最简单的里程碑和公布规划，因此我们也能够做更长远一些的规划。开始规划前我们首先要明白：1)）我们的目标不是实现整张阻碍地图，而是要依照地图找到实现业务目标的最短路径。2）通过阻碍角色才能实现目标，因此首先考虑要交付哪些阻碍，先在阻碍层面确定优先级，然后才是具体功能。以此为基础，下面是一些可供参考的产品规划和优先级确定实践：1）先选择容易实现却能够带来明显效果的功能2）选择能够验证重要假设和不确定性的功能3）选择能消除重大负面阻碍和阻碍因素的功能4）考虑先集中力对最重要的角色产生阻碍5）关于特不不确定的分支，考虑先用最小的投入探究后，再做进一步规划6）审视选择的功能集，它们应该构成一个可公布，且能完成阻碍的最小产品在实际应用过程中，实践者们还需要去修订、完善和进展自己的操作实践。2.3.3开发->测量->认知的循环上例中，我们从业务目标动身，应用阻碍地图完成从业务目标到产品功能的动态映射，为各个职能的沟通协作提供了统一的依据。我们还以此基础上，规划产品的路线图和公布打算。这只是起点，更重要的是在整个产品开发过程中，不断检验阻碍地图中的概念和假设，调整完善阻碍地图和基于它的公布路线图。在产品开发和交付过程中，我们会确认或否定阻碍地图中的假设，决定加强或停止在某一分支上的投入；通过公布产品，我们还可能取得不包含在阻碍地图中的意外的结果，我们应该重视这些意外，特不是意外的成功，发掘新的机会和概念；通过不断的反馈，深化对产品及其周边因素的认知，完善阻碍地图，调整产品里程碑打算，完善产品和服务，动态地实现业务目标。那个过程实际上确实是“精益创业”中的开发->测量->认知的循环，也是“精益创业”最核心的部分。GojkoAdzic写了一本小书“ImpactMapping”详细介绍了阻碍地图的概念和实践。Jojko的上一本畅销书，《实例化需求》推动了“实例化需求”在软件产品开发中的推广和普及，并因此获得2012年的Jolt最佳图书大奖。关于“阻碍地图”，Gojko希望它会全然改变组织构建产品和交付项目的方法。阻碍地图体现和涵盖了近年来产品开发领域多个重要趋势，包括面向目标的需求工程、迭代和持续交付、精益方法、精益创业、设计思维（DesignThinking）等。在实践中它简单有效，是相对概念化的“精益创业”和“设计思维”的落地实践。3.总结提升有效交付价值的能力是精益产品开发的全然任务。“不确定性”、“服务于商业目标”和“持续发觉”是体现产品开发的价值本质的三个关键词。“阻碍地图”专门好地把握了这些本质，它以商业目标为起点，拥抱产品开发的不确定性，结构化地呈现假设和治理不确定性，通过“开发->测量->认知”循环持续发觉和构建产品的价值。在了解产品开发的价值本质及相关实践的基础上，下一篇中我们将讨论面向价值的端到端的可视化，我们还会讨论阻碍地图之外的其它实践，并系统整合它们，为更全面的解析精益产品开发奠定基础。作者简介：何勉，现任职上海贝尔公司，曾任软件开发工程师、项目经理、部门经理，精益和敏捷教练等职。当前要紧关注：产品开发中的价值发觉、澄清和验证过程，积极实践各类方法提高这一过程的有效性，如实例化需求（SBE）和阻碍地图（ImpactMapping）等。精益产品开发和看板方法的实施，是AgileChina2013“精益和看板”模块的制作人，兼任大会程序委员会主席。精益创业和精益用户体验设计，关心中小创新型企业落实相关实践。新浪微博：@何勉感谢张凯峰对本文的审校。解析精益产品开发（三）——面向价值的可视化用户故事图谱和任务看板、版本和迭代燃尽图，可视化差不多成为敏捷和精益产品开发必选实践。可视化确实重要吗？我们将从一个真实团队的实践开始，探讨可视化的作用，以及如何让可视化发挥效用。1.一个团队实例这是一个50人左右的团队，做企业级存储和数据治理产品，他们通过实施产品开发中的价值、技术风险和价值流淌过程的可视化，促进了团队的沟通、决策、自我治理和持续改进。1.1可视化价值图1是团队使用的用户故事图谱，它集成了产品目标、产品功能项以及产品的公布打算。图1用户故事图谱实例图中左上部的两张纸上的内容分不是要紧用户需求和产品目标，它们也是产品功能定义的动身点和依据。顶部彩色的纸条是业务类不，例如关于数据治理产品，其业务类不分不是数据创建、数据存储、数据使用、数据共享、数据销毁以及系统治理等。从左至右把这些业务类不串起来就构成了用户使用系统的主流程，也确实是业务流程。相关厂商内容大数据驱动的金融业务创新华为团队构建与体系变革的创新模式腾讯代码治理平台架构和开源实践自适应学习与国内在线教育猿题库：大数据时代的在线教育相关赞助商全球架构师峰会，7月17日-18日，深圳大梅沙京基海湾大酒店。立即报名。每个业务类不下面有数个到数十个白色的纸条，它们是以用户故事的形式描述产品功能项。功能项按重要程度自上而下排列，靠上的是重要和基础的功能项，靠下的是次要和补充的功能项。以排列好的用户故事为基础，团队制定公布打算，图中三条贯穿左右的红色曲线分不对应着三次公布，它们由对用户有意义的产品功能集构成。项目启动时团队定义用户故事图谱的第一个版本，产品开发过程中随着对产品认知的深入，再持续地调整和更新。用户故事图谱系统整合了产品的目标、功能和公布打算，它促进团队沟通和理解产品目标和价值，并积极主动地参与协作。1.2可视化风险产品开发过程中必须应对各类风险，图㈡是团队使用的技术风险矩阵，它综合呈现技术风险的内容及发生的可能性、阻碍大小、以及应对方案。图2技术风险矩阵矩阵的横坐标是风险发生可能性，从左往右分不是低、中、高；纵坐标是风险可能带来的阻碍，从下往上分不是低、中、高，风险项被按照其可能性和阻碍贴在相应的位置。团队要关注的是靠上和靠右的风险，特不是右上角高可能和高阻碍的风险，并制定应对措施，如提早进行技术评估、技术验证，或设计替代方案等，这些应对措施通常会转化成团队的技术任务。图中附在风险项之上的蓝色纸片是该风险的应对措施。风险矩阵只用于跟踪尚未解除的风险，随着项目的进展风险项被不断添加和移除。风险矩阵关心团队有效治理技术风险，它的核心能够用下面的公式表示：风险=f(可能性，阻碍)–应对方案产品开发中要紧包含三类风险，分不是：业务风险——产品能解决客户的问题，并被市场所需要吗？治理风险——治理和协作方式能保证质量、效率和响应能力吗？技术风险——所采取的技术方案、基础设施能支持我们开发出所设想的功能并满足非功能需求吗？以上的风险矩阵中只包含技术风险，而不包含其它两类风险。治理风险和业务风险在本文的后半部分介绍的其它实践中会有涉及。1.3可视化价值流淌价值项和风险的可视化只是开始。产品开发过程中，这些价值项要通过分析、开发、验证等过程才能交付给用户得以实现，我们把这一过程看成是价值流淌的过程。图3价值流的可视化（开发看板）图3中团队用开发看板可视化了价值流淌过程。看板呈现了价值项从进入开发环节开始（图中的需求接收），到分析、实现、验证、交付验收直至公布的流淌过程。图中上方的列标题是价值流淌过程所要通过的时期，其中分析和实现时期又被用虚线分割成两列，分不表示正在进行和差不多完成（图中的Done）两个状态。一个典型的用户需求在公布前会从左至右依次流经以上的各个时期。看板横向上被分成5行——称为5个泳道，最上方的泳道用以处理紧急的用户需求，相对其它需求它们的优先级更高。其它4个泳道分不对应4个按用户需求类不划分的10人左右的开发团队。当价值项的流淌被阻碍时，团队会用黄色的黏贴纸附加在该需求上并标记阻碍缘故（如图中最左上方的需求项所示）。另外假如价值项在某个时期堆积，也确实是图中的某个时期出现较长的队列，这本身就讲明了那个时期的流淌不够顺畅，存在潜在的瓶颈和问题。价值项以用户故事卡表示，图㈣是一个典型的用户故事卡，它包含的信息有，1）用户故事的描述和编号2）涉及的具体开发任务，以及这些任务完成的情况3）负责人4）最晚的交付时刻（部分用户故事包含）5）开始和结束的时刻6）在每个状态下所经历的天数。其中最后两项属于统计信息，用于团队的定期回忆和分析，它对团队的持续改进意义重大，这在以后讨论精益度量的文章中会有进一步阐述。图4看板上的用户故事的详图需求项所使用的颜色也是有意义的，如黄色表示有固定完成时刻要求的需求项，蓝色表示一般的需求项，红色表示产品缺陷。通过以上的实践，团队实现了价值和价值流的端到端的可视化，建立了关于产品开发目标、价值以及价值流淌的集成认知，促进了团队沟通，自我治理和持续改善。但这只是特定团队的实践，现实中不同的团队有不同的上下文和目标，需要依照现实情况构建适合自身的可视化实践。这就要求团队深刻理解“什么缘故要可视化？”和“如何让可视化更有效？”下面我们将讨论那个两个问题，并以为此基础构建面向价值的产品开发可视化体系，我们还将看到更多的可视化实践案例。2.什么缘故要可视化？产品开发过程中，团队需要动态处理各种信息，其中既有来自外部的信息，如用户需求、商业环境等，也有来自内部的信息如产品目标、开发进度、技术风险等。即时地猎取和有效整合、沟通这些信息，是成功的关键。反之，信息分散和信息在传递中的失真则导致沟通问题甚至是产品开发的失败。信息分散和信息传递导致沟通问题，甚至是产品开发的失败。信息分散

——

倚天屠龙的困境：在产品开发中，信息分散是指：信息散布于各地（如不同的个人或团队），不能被有效地整合。小讲《倚天屠龙记》中，一本武功秘籍被分成两份，分不藏于倚天剑和屠龙刀中，没有人能同时手握两件兵器（猎取信息），即使两件兵器在手，也不明白如何合二为一（整合信息），产生有用的知识，因此我们把信息分散称为“倚天屠龙的困境”，它在产品开发中司空见惯，如：业务人员差不多明白用户需求变更，而开发人员还在基于老的的需求工作，到交付的时候才明白白费劲了；治理子系统团队和应用子系统团队都忙于自认为重要的特性开发，在公布时才发觉，由于相互依靠的功能没有完成，不能完整交付任何对用户有意义的产品；应用层的工程师加班加点用复杂算法实现了一个紧急需求，却因阻碍产品性能被用户拒收。和底层驱动工程师讨论性能调优时，才明白只要简单地打开一个底层开关就能够实现同样的功能，而且不阻碍性能。产品开发中，信息分散于不同的人、团队和层级中，可视化直观地呈现和系统整合分散的信息，形成有用的知识，从而关心整个团队方便地猎取知识并做出有利于整体目标的决策。信息传递

——

拷贝走样的悲剧：前些年，电视综艺节目中流行一个叫“拷贝不走样”的栏目，一组人排成纵队，依次用动作表达是一个词语，由最后一个人复原。多数情况下，“拷贝不走样”成了“拷贝走样”，信息失真了，观众欢乐了。“拷贝走样”在产品开发中时常发生，但它带来的并不是欢乐，有时甚至是悲剧。1999年12月19日，价值1.25亿美元的美国火星气象探测器在进入轨道时坠毁，因为一个团队提供了英制的信息，而另一个团队把它当成了公制，导致飞行器进入了过低的轨道。在产品开发中，当我们听到下面的讲法时，讲明拷贝走样的悲剧正在发生：“我不是告诉过你…….”“项目打算里不是写的清清晰楚的吗？”“我以为你的意思是……”“听好了，我讲的是……，而不是……”。治理学之父德鲁克讲：“每一次传递都会使信息减少一半，噪音增加一倍”。可视化实践让产品开发的整体目标、当前状态和问题一目了然，如此能够及时发觉沟通的需要，并减少中间环节。有效的可视化让团队成员及时、方便和直接的猎取信息，促使成员间更加自主和直接的沟通，做出面向整体目标的决策，幸免“倚天屠龙的窘境”和“拷贝走样的悲剧”。可视化关心团队直观呈现和系统整合信息，促进团队直接和自主地沟通。可视化是信息整合和沟通的工具，它不应该是简单地堆砌信息，有效的可视化应该是目标明确和结构清晰的，它应该抓住产品开发过程的核心，促进信息的整合和沟通，这也是接下来我们设计可视化方案的差不多指导。3.产品开发过程可视化的核心——价值定义和价值流淌如图5所示，产品开发是从用户问题开始，通过一系列步骤，到交付解决方案解决客户问题的价值流淌过程，它这分不对应着价值定义、价值流淌和价值交付。图5产品开发模型假如把价值交付看着价值流淌的一个环节，那么“发觉和定义价值”和“让价值有效流淌”，就成为产品开发过程的两个核心。相应的，可视化也应该围绕这两个核心展开。产品开发过程可视化的核心是：价值定义和价值流淌。4.价值可视化产品目标决定产品的功能项，并通过产品公布打算得以实现。如图㈥所示产品目标、功能项和公布打算三者相互作用，是价值定义的重要部分。然而，现实中用户的需求与我们设想可不能总是一致，市场环境也会发生变化，我们不可能从一开始就把握所有需求。用户价值定义背后一定蕴含着不确定性，带来业务上的风险，TomDemarco在《与熊共舞》一书中把风险和不确定性比作熊，一个成功的产品开发确实是“与熊共舞”的艺术。挑战不确定性和风险是企业获得竞争优势的不二法门。能够讲不确定性本身就蕴含着巨大的价值，是产品价值定义的一部分。图6产品开发的目标、功能项及规划综上所述，