图说敏捷项目管理中的价值

与传统的项目管理不同，敏捷项目管理关注价值。

（关注价值）

要理解价值，我们先要理解项目的目标是什么，无外乎包括以下几个方面：

（项目目标）

明确了目标，再来谈价值。价值从本质来说，代表的是所提供的产品或服务对最终用户的价值，即用户愿意支付的、最终对于企业本身产生的增值，而不是仅仅被企业所认可。

（衡量价值的维度）

举个例子，银行在线上提供个人自助贷款服务，其目标是在3个月内线上个人贷款业务数达1000笔，贷款总额达5000万元，新增线上用户数达3000个。对应到价值，可以理解为更高的销售额、更多的利润以及更多的用户。

相比传统瀑布开发，敏捷是对软件交付价值链的系统性颠覆。价值链上游的产品需求从庞大完整的功能版本以一定的优先级次序被拆分成了源源不断的故事卡。上游需求单元的颗粒度和频率变化让交付环节的管理复杂度指数级增加，项目经理应改变“项目是为了交付更多功能”的传统观念，而把关注点放在“这个功能有什么用”——即项目交付的价值上。

如何交付价值呢？

不同于传统的瀑布开发模式，敏捷软件开发以迭代的方式进行，旨在不断收集真实用户反馈、听到市场的声音，践行价值交付。

（敏捷交付模型）

通过敏捷项目，让我们“想象”中的“价值”更快地交付到市场，以验证其是否真有价值。一般而言，敏捷软件开发会将每次的发布（Release）分成多个迭代（Iteration），在每次迭代结束都会做showcase，演示本迭代开发功能。项目经理需要从价值交付的角度管理每个迭代的需求，让每次showcase都能展示有“价值”的功能。

为了达成目标，在项目交付中，我们需要对价值流作出行之有效的管理。

项目经理如何改善价值流呢？

知易行难啊...现实是：

在制品（Working In Progress，WIP）数量增加

系统前置时间（System Lead Time）变长

(如果可以再来一次？)

本着信息透明的原则，先用“看板”来限制在制品。如下图所示，通常我们都是采用基于“列”的在制品限制。

(限制在制品)

通过对看板流转情况的动态观察，识别影响看板的瓶颈，从而通过限制在制品避免和解决瓶颈。比如，我们发现在测试阶段（Testing）出现任务的挤压，这时候测试就成了整个看板的瓶颈。那么我们有可能采取的方式是：增加测试人员；或限制测试任务的输入，即在开发阶段（Development）限制在制品。

在项目的前期，在制品数值应该是经常变动的。分享一个快速设定在制品数值的方法：

如果某列经常同时有5-6个工作在进行，我们最初可以将在制品数量限定在10-12个，然后规律性的以20%左右的幅度将其递减，继而达到一个相对稳定的值。在制品数值的调整，本身也是一个持续改进的过程。基本原则是避免浪费，提高效率。

项目经理还要时刻关注System Lead Time。

(Lead Time)

Lead Time升高的原因有很多，不同问题采取不同的对策。

(Lead Time升高的根因分析)

如果是组织和环境（流程与协作、质量与基础设施以及组织方式与技能）的原因，可以考虑通过改变“游戏”规则的方式来得到期望的结果。举个例子，有些团队在项目初期从需求分析到制定各种计划，通常一周时间已经过去了。然后再作需求评审，又需要两到三天时间。为了缩短Lead Time，我们需要改变“游戏”规则：简化流程，优化系统。如果是风险管理（技术、业务和依赖关系）出了问题，则需要通过加强风险管理的手段来预防和管控。