从精益来看价值交付是什么

前一段时间在做U内的价值交付。个人也从最开始的可意会不可言传的状态，到后来可以聊些概念和措施的阶段。

老实说曾经在我司经常听到DevchallengeBA：“你这个需求的价值是什么？”现在反而听到越来越少。曾经我们坚持要去做有价值的事情，直到我们现在不得不highlight出价值交付这个标题。并且常常会被问到——价值交付，它到底指什么？

首先我不会尝试直接回答这个问题。作为一个交付型U，我们先从一些耳熟能详的理论和方法实践中，尝试找到“价值”这个词。

从前两组概念——敏捷和敏捷项目管理，来直接追溯价值交付，看起来总是有些刻意。而精益思想的第一原则“精确地定义特性产品的价值”，直接从用户受众的角度入手，就看起来直观的多，因此我这里就直接从精益来看价值交付是什么。

说到精益如果用一句话来描述它是用来干什么的话，那应该是：杜绝浪费，降本增效。当然如果提到它诞生的背景的话，它解决了工业化大生产中的提前批量性生产、生产时间周期过长、生产可预测性不准等问题，但解决问题的终极思路就是：在保证价值的同时持续不断、稳定地消除浪费，从而降低成本提升效能。

说到“浪费”：丰田模式中，将生产活动中的各环节分为3类步骤：

同样的道理在软件交付中，首先的出发点就是价值，并不是一堆一堆的功能集、features或者看起来非常fashion但不解决自身问题的前沿方案。

但是无论是制造业还是软件业，价值只能由产品的使用者——最终用户来确定。一般在交付团队中，会有两种情况：

交付价值只有在用——具有特定价格、能在特定时间内满足用户需求的特定产品（无论商品或者服务）来表达时才有意义。所以在交付之前，先确定产品的价值——开发的人力成本、时间成本、机会成本，和最重要的一点——这是否解决了用户的真实问题吗？以及是否“更好地”解决了用户的真实问题？为什么这里有“更好地”一说？就比如同样是员工打卡系统，在开发各成本投入产出比相似的情况下，上AI人脸识别——自然是比手工签到的价值要大的。

也许有人会说，“我们使用敏捷，就是因为当下无法定义出明确产生价值的需求，才使用敏捷软件交付——实现增量性发布、快速实验和反馈。”这里要分两种情况来看这个问题：

实现完价值定义之后，我们针对当前价值定义来看看“交付”这个动作。

用过Scrum或者Kanbanboard的人应该都理解，一张卡（无论EPIC卡还是story卡），其承载的就是一个价值点（这里不涉及到估算）。

而将board上的各个columns对应的步骤连接起来，其实就组成了完成此类卡的一条粗粒度的“价值流”。其中有产生价值的InDev、InQA等，也有1型浪费DevDone/ReadyforQA等等，当然个别团队可能还存在2型浪费的columns。价值流的目标就是让团队识别出流程步骤，为之后消除这些浪费做准备，最终降低开发成本、缩短leadtime。那从这种粗粒度的”价值流“中如何逐渐暴露浪费和执行改进呢？

也许有人会觉得这句话理解起来很难，其实在部分团队内非常常见。比如：见过一些客户团队，所有story的开发只要开发人员开发完毕，就推进DevDonecolumn中，等到整体功能开发的差不多了，才引入QA来开始测试，在此之前QA资源可能在忙于另一个团队的测试工作。一种类似制造业批量化生产的模式，生产步骤之间存在大量库存，批量满额之后，才会推进到下一个生产环节。也有一些敏捷团队，由于QA资源不足，出现相同的DevDone之后在ReadyforQA中形成批量等待，始终无人解决，甚至大家对此已经习以为常——QA会在下一个sprint整体测试这批卡。“使价值不间断地流动”，其实不仅是行动、更是从思想和意识上认识到——价值要流动起来。就像最后那些敏捷团队的例子，即使使用了敏捷流程和工具，思想和意识不到位，依然用出了批量的样子。

有人会说：“这种批量有什么不好？团队上所有的人都在工作，并没有空转，人力没有被浪费。“如果一定要从项目人力运营的知识域中来看价值交付，我只想说：是的，大家看起来都忙忙碌碌，行色匆匆，努力“做事”，但是人力花完就代表创造了价值么？另一方面，我也可以从”测试前置“、”一次性把事情做好“、”缺陷越晚修复，修复的成本越高“、”开发周期越长，越容易返工“等等方面来聊一聊不关注价值流会造成的种种人力成本、时间成本、机会成本上的浪费。

只有让价值尽量不间断地流动起来，从需求到生产，才会暴露问题——让团队观察和思考这种端到端的整条价值生产活动中，哪些是产生价值的，哪些是浪费？持续地逐渐优化和消除浪费后，降低开发成本、提升研发效能。

当研发效能提升、单个价值点能被快速完成端到端交付时，提前预测性质的功能设计（是否能最终产生价值靠玄学的那种）就可以完全被避免，由最下游的终端用户直接提出需求，从来拉动交付。

在前面我讲board上面的价值流的时候，始终特指其是”粗粒度“的价值流。为何？因为无法从这些columns中看到：用A框架开发会比B节省多少开发成本、使用某个自动化测试方案可以节省多少测试成本，诸如此类的“细粒度”的价值流才会发现的浪费对比。这种时候各团队面临的问题各不相同，需要团队一线人员自身的方案和技术能力去扩展优势、消除浪费，不再局限于敏捷软件开发流程、scrum/kanbanboard来宏观指导和描述开发流程。

这里就涉及到精益思想的最后一个原则：“永远追求尽善尽美”。

精益思想前四大原则都只是在讲——如何消除产品生产过程的浪费，最终形成高效有价值的生产流程。一般完成前四原则，基本可以收获突破性改善（指初次改革，调整生产活动后，一次性获取到的改善效果）。精益思想用最后一个原则“永远追求尽善尽美”，才提到了如何持续性改善。

而《丰田模式》用了一整本书，来讲如何实现“追求尽善尽美”、实现“持续性改善”——即使完成了前面四个原则，或用了大量的精益工具和实践，只要没达到一点，就不是精益。精益——打造一个真正的学习型组织。

这个“学习型组织”，不是说——只是在组织内培养学习氛围，今天去学几种对价值流毫无帮助的语言或架构，明天去做一些对当前主业务毫无扩展的社区活动。也不是说当某个团队需要一个大数据工程师时，需要从零开始培养，当第二个团队又需要一个大数据工程师时，再次另外培养。而是说——培养学习氛围、过程中不断创建“标准化”以达到“稳定”，然后让成员发挥创造性思维和创新能力以持续改进价值流的组织。

为什么说“团队能力/学习型组织”是价值交付的土壤呢？假设某团队前四原则背后的工作并不是团队自发形成完成的，是由一个外部人员引入并督促实践完成，本团队并没有掌握其能力。当用户需求拉动生产越来越快时，必然会暴露进一步需要解决的瓶颈和浪费，这时候团队离开了外部人员根本无力继续持续改进从而稳定交付价值。

为了真正实现精益的持久性改善和价值交付，这需要一个自下而上的过程。仅靠上级制定几个衡量指标，没有培养团队的学习和自组织能力，你永远也想像不到真正实践时会长成什么样子。将团队的指标呈现想像成地上的树，如下图。上级也许期望是扎根价值交付、持续性改进指标背后的问题。但团队也许只是做了一些流于表面的工作让指标变得好看。

何为价值交付？以打造学习型组织或团队为基石——精确定义产品用户价值，尽可能以追求价值卓越为目标，从需求提出开始到产品上线被终端使用，持续消除或者减少阻碍产品研发的浪费，最终实现产品价值。

看起来精益贯穿始终。再回来看看《敏捷宣言》和《相互依赖声明》，发现和精益很多方面都很相似。只不过在我看来，精益可以更好的端到端描述整个价值流思路。