你可曾想过软件研发过程中如何让工作变得更简单高效？

1.关注需求 vs 关注任务

在办公室，常见的景象是每个人都在处理多项任务，忙得不可开交，却频频延误交付。事务性工作本质上是任务驱动，专注于基本的开发任务，但这些任务片段化，缺乏整体的产品需求和目标。尽管个体完成了许多任务，但缺少与其他任务在需求层面的衔接，导致产品交付不及时。这就像仓鼠在滚轮上奔跑，始终原地踏步。

软件交付的核心是持续、快速且高质量地提供有效价值，而有效价值源于用户需求和业务目标。需求可以从业务目标、场景和功能需求等不同角度进行分解，保持其独立性与可测性。每个需求交付都是验证假设、创造业务价值的机会。

因此，在软件交付中，通过精益交付看板可视化需求流动，才能实现价值驱动；唯有从整体视角出发，才能在协作中实现不同职能的联通。关注用户问题的提出和解决，就是要强调“结果优于产出”，即在最小化产出的同时最大化结果。

老板更关注的是交付的特性需求，而非完成的任务数量，因此，协作应以需求为单位，更重视业务价值，并通过可视化手段呈现交付过程。

2. 流动效率 vs 资源效率

资源效率是指将人视为资源，关注个人效能，创造局部繁忙的状态。然而，局部资源效率的提升并不能提高整体效率，这是因为产品交付的全过程需要各职能之间的协同，包括业务、产品、开发、测试和运维等。

关注资源效率的两大原因在于：

1. 软件交付受到短板的影响。
2. 每个职能的局部效率优化容易形成“效率竖井”。局部看来效率很高，产出了许多中间制品，但这些竖井之间的交接形成批量，整体效能并未改善。

以流动效率为核心，意味着将需求作为流动单元，从用户需求出发，快速流向用户，从而加速需求的上市时间（Time to market）。流动效率的快慢直接影响用户响应和反馈的效率。

要以流动效率为核心，必须拉通交付流程中的所有职能，打破组织壁垒。同时，聚焦流动效率可以帮助组织及时发现协作中的问题，如阻塞和等待等，这些问题可能是协作问题，也可能是工程能力问题。

软件研发过程中的主要问题往往不是资源的闲置，而是需求的闲置。因此，关键在于：资源效率关注个人人效和人力利用率，而忙碌的局部资源效率并不能在整体上提升流动效率。

3. 关注问题 vs 关注活动

僵尸式站会是指那些仅仅照搬方法论框架、追求形式主义的会议。在这种情况下，人们常常陷入“是站着开还是坐着？会议分上午和下午，还是集中在下午？”等细节中，忽视了真正的问题。这种本末倒置的做法违背了方法论的初衷，即促进交流和理解，而非生搬硬套。

在软件项目协作中，关键在于解决问题和移除阻塞，关注需求如何快速流动。从项目协作的角度，应关注以下几点：当前存在哪些阻塞、哪些需求到期却无法交付、交付的价值流中是否存在中断，以及当前交付过程中的瓶颈是什么。这样的关注才能真正提升协作效率。

我们推荐的“6+1”站会模式，旨在引导团队关注协作中的问题。“6”代表六个关键要素：瓶颈和队列、关键缺陷、重点关注的需求、阻碍和问题、到期或即将到期的需求，以及中断。“1”则指未在看板上反映的问题。通过这种方式，可以更有效地识别和解决协作中的挑战。

不建议照搬哪个方法论的框架，方法论框架的目的是为了交流理解的需要，而不是生搬硬套，照本宣科。