书本推荐指数：四星
书本推荐说明：作者是一位软件开发和企业敏捷转型专家。作为Tasktop公司的创始人，他开发了一系列软件，帮助团队更好地协作和追踪工作进展。在书中，他从软件研发过程中经历的三个顿悟出发，推导出关于产品价值流框架的体悟。作者对于产品导向、产品价值流的思考和理念非常细致，发人深思，可以帮助加深产品导向管理理念的认知。而且每一章节前会说明关于本章的主要问题和内容主旨，章末则进行总结并引出下一章节，让人读起来很落地。不过有的理念如何在实操中落地，还值得进一步探索。
想讨论的话题：
1）所在组织是否会衡量产品价值？什么时候会衡量？从哪些维度衡量产品价值？
2）如何识别价值流上的瓶颈？
3）从项目导向转到产品导向的管理关键是什么？如何转换？
产品导向
1、如何在下个10年中生存
要搞清楚我们处于软件时代中的哪个位置，就有必要提到佩雷斯的理论中最重要的一点，那就是新科技体系的导入期和展开期这两个概念。在导入期，风险资本等大量进入资本被用来撬动新的科技体系，瓦解前一个时代的同时，新的体系形成足够多的技术、企业和资本。这边是我们看到的初创企业“寒武纪大爆发”。
佩雷斯在书中提供的证据表明，我们正处在第五次迭代的中期。如果遵从佩雷斯的五十年周期模型，就可以认为我们正逐年靠近展开期。接下来十年，会有大量企业在市场中失去立足点。
本章提到了技术革命的周期以及每轮新的技术体系给时代带来巨大的市场影响。面对经济浪潮，如何在未来10年，找到正确的投资目标和投资方式进而在转折点幸存？
作者在书里每章节都以在宝马集团莱比锡工厂的见闻和感悟作为引子。为什么这次参观能给作者留下这么深刻的印象，我想是因为作者多年身处软件行业，却没发现这个复杂过程的不可见性带来的问题。所以制造业的生产过程和管理方式给他带来了巨大的冲击。
在工厂中装配线的流程清晰可见，这些流动的部件最终就是需要交付的产品价值。走在工厂里就能随时查看和检查价值流的交付速率、单元质量。而软件产品的研发过程显然是复杂和不易展现的，这就容易导致业务与IT的脱节。这种脱节也许是从需求导入到过程实现，从验收输出到现场应用都有可能会发生。这种脱节往往也不易被察觉。
2、聚焦于端到端的产品价值
第一条经验：要避免局部优化陷阱，就要关注端到端的价值流。
第二条经验：如果只按成本来管理转型，势必会降低生产力；
第三条经验：工程/IT和业务必须挂钩
在书中这部分，作者提到了他的3条经验。3条经验虽然是从三个问题场景得出的经验，总结的是同一个理念：无论是改进优化、转型变革还是过程管理，最重要的是聚焦于端到端的产品价值。
1）聚焦：组织在运营和管理过程中，始终要抓住和识别，当前最重要、最需要关注的是什么？活动的开展是否有利于目标的达成。这种聚焦，应该是整体性的。不管是哪个部门、哪个岗位、哪个活动，还是评判标准，都需要朝一个共识的方向去聚焦。不然就有可能会出现各部门有各部门的小目标，组合后却失去了统一的方向，这其实也是一种资源浪费。只有每一次的聚焦，才能有最终的合力。
2）端到端：端到端的这个词在互联网行业常常听到。但是在这本书中，又有一点新的领悟：端到端其实也是一种系统思维，需要从业务层面用全局的视角看待问题。
常常说端到端的拉通，那么到底是要拉通什么？如何进行端到端的拉通？端到端不应该仅仅是局部信息的传达，或仅仅只是技术实践。更应该是业务与IT部门在业务层面达成合力。共同探索明确的业务方向，并进一步将这种业务战略理解内化承接到软件研发过程活动中，包括从需求输入到需求实现，从需求实现到整体验收。驱动产品线整体的价值流动不断层、不衰减。
另一方面，这和约束理论的概念相像：在瓶颈以外的任何地方投资都是徒劳。而每次的瓶颈/断层/衰减环节是有可能会变化的，需要持续去识别和反馈。改善瓶颈的目标不应该只是解决这一次的问题，不是为了局部改善而改善。而是从整体业务层面达到改善的目标，所以这是一个动态持续的、系统思考的过程。
3）产品价值：聚焦的目标不是功能验收、项目交付，也不是流程和活动，而应该是产品交付后所能实现的业务价值。业务价值的实现，是整个产品交付的动力，也是反馈闭环的照妖镜。
3、项目导向VS产品导向
产品导向的管理聚焦于对每个投资单元所产生的业务价值结果进行度量。重点在于产品才是投资单元，而项目不是。
产品导向的管理中，关注点在生命周期成本和盈利能力上。按照“项目结束谬论”，组织看不到软件交付的关键经济因素，比如技术债务。
项目导向和产品导向为什么会有上面列的区别？还是因为给了不同的“框”，一旦被框住，管理者就只能看到框内的情况和问题。
项目导向和产品导向引导的是不一样的目标层级和决策思维。在实际组织管理过程中，是否有可能通过项目管理的方式，达成产品导向的管理目标。我想可以有进一步思考。
价值流的度量
软件流动：沿着软件价值流产生业务价值这一过程中涉及的活动。
流动项：由于干系人所拉取的、通过产品价值流来传递的价值单元。
流动分布：价值流中每个流动项的比例，根据每个流的需要进行调整，使业务价值最大化。
与原先认为的每次交付都是功能价值不同，缺陷修复、风险规避和债务消除，也可以是交付的价值。而每次交付应该如何分配各类流动项的分布？流动分布图又可以有什么样的作用？我想这两者是相互反馈验证的关系。
1）在产品生命周期的不同阶段，可以为每次交付设置不同的流动项分布计划，以使所有交付与高阶的业务目标保持一致。
2）最终历次迭代交付的流动项分布趋势，也可以呈现出产品随着每次交付所带来的市场变化，以及产品缺陷/技术债所积累的影响。
这里也是在强调，不同的产品阶段需要关注不同产品业务目标。在新产品导入阶段，更侧重于新特性的交付。这是一场与时间的赛跑，整个业务都依赖于发布的成功。而当特性交付积累到一定程度，由于软件开发本身就有的复杂性，缺陷和技术债也会不断增加。所以如果每次都以特性交付为高优先级，忽略了技术债务和风险，就可能会出现最坏的情况：随着客户使用量骤增，每次能交付的特性功能越来越少，而不得不花时间处理计划外的新增缺陷和技术债。这对需要不断创新的产品来说，是不可持续的。
通过流动项分布趋势，可以帮助识别产品状态和预判风险，对功能价值和业务交付可持续性进行权衡，从而引导下一次交付的流动项分布计划。
