翰纬 · 悦书评 2022年第2期
《Project To Product》
价值流动：数字化场景下软件研发效能与业务敏捷的关键。
米勒·科斯腾的这本书回答了一个困扰我很久的问题。
“软件研发学制造业的经验会有用吗？”
寻找瓶颈：第三次顿悟
米勒·科斯腾
“离开宝马莱比锡工厂之后的几周，我开始痴迷于如何把我的见闻应用于软件交付。流动和可见性这两个关键概念似乎可以直接照搬。
然后，在尝试建立生产风格的软件交付流程模型时，我总是卡壳。”
米勒·科斯腾看到了先进制造业的实践，万分激动。于是在没有完全理解二者之间差异的情况下，引入到软件研发领域。
在经历了一些问题之后，他得出了这个结论：制造业生产线是线性制造过程，而软件持续交付是网状协作过程。
制造业生产是线性过程，所以出了问题必须停工，必须处理完这个瓶颈才能继续走下去。而软件研发是网状协作，是分布式。当一个地方出现了问题，有的是绕开这个问题的方案。这个方案不一定是最有效，但一定是有用。所以，因瓶颈导致交付停滞在软件研发里是不存在的。
借鉴制造业里的精益理念，但不能生搬硬套。比如不能简单地将DevOps的持续交付比作制造业的生产线。这么做就会过于狭隘和过于线性。因为一旦将理念降维成工具手段，线性过程就出现了。
顿悟3：软件价值流不是线性的制造流程，而是复杂的协作网络，必须与产品对齐。
本书一共9章。核心就是要讲明白价值流动对于软件研发的意义。而要实现价值流动，最好的方式就是转向产品导向。
软件研发应该学什么？
流框架、价值流、价值网络等等，不是新名词。做IT服务的都知道，很早ITIL就在讲这个道理。IT服务就是产品导向，只有运维才是项目导向。
IT服务提供的是服务产品。有定价，生产即交付，稳定团队支持等等。从服务需求到产品研发，再到交付消费。同时伴有反馈和持续改进。一个服务产品团队及其关联干系人共同协作完成服务产品的持续交付。
产品导向不论是IT服务还是软件研发都适用。这个适用的大前提是你必须直接面向客户。所以，软件研发学什么之前，首先要看你所具备的条件是什么？
业务敏捷不可能发生在强职能组织结构下，通过项目导向来实现真正的敏捷。
基于这个认知，我们来回答软件研发应该学什么之前，可能要再问一句：软件研发是否具备学习先进经验和实践的组织基础？
德国宝马莱比锡工厂中央大楼是围绕汽车生产线而设计。由此延伸到软件研发，组织是否能够按照这个思路来确定实践路线？是否以价值引导实现路径？
如果是，我们才能继续实践流框架、价值流和价值网络。否则，也就是东施效颦了。