知识工作的有效性问题
《纽约客》（The New Yorker）杂志曾刊载一幅漫画： 办公室门上写着“总经理史密斯”，墙上只有一幅标语：“思考”。画中的经理大人，双脚高搁在办公桌上，面朝天，吐烟圈。门外刚好有两位较年长的人走过，一人问另一人：“天知道史密斯是不是在思考我们的销售问题！” 的确，谁也不知道一位知识工作者在想些什么。 然而，思考却正是他的本分，他既然是在思考，他就是在工作。
知识工作者并不生产本身具有效用的产品。他不生产有形的产品。 例如挖一条水沟、制造一双鞋或一个机械零件。他生产的是知识、创意和信息。——《卓有成效的管理者》
软件工作的有效性问题
软件工作(普遍被认为)属于知识工作，软件工作的有效性问题也普遍存在，比如：
程序员把键盘“噼里啪啦”敲了一天，谁也不知道是不是写了一堆Bug或是偏离业务价值的逻辑； BA对着JIRA，挥挥洒洒写了一天的Story, 谁也不知道这些Story的好坏，是否符合项目上下文的INVEST原则； QA对桌上摆着一堆测试设备，各种单击，双击，暴击，我们也不能知道产品是否满足了项目的质量要求；
软件工作的有效性验证
对于知识工作而言，知识工作者生产出来的知识、创意和信息： 只有通过另一位知识工作者，把他的产品当作投入，并转化为另一种产出，它们才具有实际的意义。——《卓有成效的管理者》 那么，对于软件工作来说： 一位软件工作者工作产出的有效性验证，也只有通过另外一个软件工作者，把其产生的知识、创意或信息作为投入，转为为另一种产出——即知识的消费和传递。 （可能只有）通过知识的消费和传递来验证软件工作的有效性。 一位软件工作者的产出(output)想要变成成果(outcome), 也只有通过传递和消费。
软件工作的有效性验证和一些软件开发方法
从这个PoV (Point of View)来看一些软件开发方法或实践： 敏捷方法：
Pair Programming
这是code reivew的极限形式，产出即被消费。 一名程序员的产出的一段代码或思路，同时就被另外一名程序员消费（这段代码的逻辑、模式、是否符合业务价值以及可读性的方式），这名程序员的这部分工作的有效性得到了验证；
TDD - 测试驱动开发
某方面来说，这个思想甚至更进一步。 一项工作是否正确，只有通过测试才知道。在开始某项工作之前，先设计好其有效性的验证，通过这样的“颠覆式”地验证前置的模式，更好地保证了有效性。
一项工作是否正确，只有通过测试才知道； 软件工作是否有效，只有通过消费才知道；
精益方法：
Pull模型
精益的Pull(拉动)模式，类似“价值驱动”，但更彻底。从最终成果出发，后一作业需要加工多少产品，来要求前一作业制造正好需要的零件。 软件工作的有效性只有被消费的时候才知道，为了最大限度地减少浪费（无效的工作就是浪费）即最大限度减少无效的工作），生产出来 && 得不到消费的工作（有效性未知）就是浪费。
单件流
单件流是指产品以一个单件或一个批次来流动。 为什么要流动？—— 流动更利于工作产出的消费 为什么要单件？—— 加速流动； 在软件交付中亦是如此。知识工作者的产出，也就是知识，创意或者信息从 用户/市场 —> PO —> BA/UX —> Dev/QA 再流回用户/市场，这就是软件交付的知识流。流动起来的知识更容易被消费，以最小单元流动的知识，避免浪费。
启发 - 更有效的的软件交付
从知识消费的角度来看，整个软件交付的流程，从前一工作的知识(产出)，被后一工作消费，进而生产出新的知识(产出)，依次往前，如下图：
“如何做到更有效的的软件交付？”的问题可以转化为： “如何保证软件交付的各个阶段的工作是有效的？”这个问题又可以转化为： “如何尽快消费？”即：更快的消费流。
更快的软件交付消费流，我们可以从两方面考虑：
- 流速更快
- 减少中间节点
流速更快
- 聚焦高优先级
- 单件流（或者是控制WIP）
- 被Block的问题是最高优先级
- 减少等待时间
- 减少排队时间
- 减少返工
- 可视化的目标和进度
- 团队透明度 对于每一项，各个交付团队都有很多实践和经验了。
减少中间节点
在整个消费流程中，可以看到的消费（反馈）节点：
- User/Market
- PO
- BA/UX
- DEV/QA
- PO
- User/Market
完整的反馈流节点：User/Market -> PO -> BA/UX -> Dev -> QA -> PO -> User/Market 乍一看，好像都不可缺少，但是有两个点可以讨论：
不一定所有产出都需要这样的消费流 有些工作产出，可以直接跳过某些节点； 比如PO提出的一些想法，BA不用通过“可工作软件的”来反馈给PO；在自动化测试充分的情况下，Dev的某些卡不需要再通过QA测试； 对于一些任务，团队有一定的灵活性来让消费流（快速反馈）更快。
生产者和消费者，是否可以是同一个人？当然可以！ 我们喊的是两个口号：“A. 业务价值，人人有责！ B. 产品质量，人人有责！” 团队的每个成员都需要对业务价值，产品质量负责，也就是每个成员在某些时刻，肯定在做保证业务价值，或产品质量的事；同理，他(她)也可以戴上用户、UX、PO的帽子； 最极端情况就是：自己做一个给自己用的软件！集万千角色于一身。
知识工作者的“消费主义”精神
软件（知识）工作者的“消费主义”，是本着“工作是否有效，只有通过消费才知道”，时刻去思考和推进自己的工作能最快地被消费，最快地将“产出”转化为“成果”。 软件交付有着精益求精的追求，需要 “工匠”精神； 而软件交付本身作为知识工作，需要“消费主义”精神