> For the complete documentation index, see [llms.txt](https://www.oulan.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.oulan.com/1ux/agile/simplyagile/3-asset-for-pm.md). # 项目经理保持迭代行军的三种资产 经常有项目经理被问到： * 现在什么都理好了，为什么你们的交付老是出问题？！ * 现在不就是在搬砖吗？ * 不能及时上线，是不是你们不够努力啊？ * …… 然后项目经理只有望一眼还在增加的需求，和其他团队因为配合搁置的功能，唉声叹气。这个时候，当我们去跟他们讲敏捷的时候，通常都会说，我们搞的就是敏捷啊，你看我们有迭代，有计划会、有评审会，每迭代我们还开回顾会呢！可是业务在压、别的团队不配合，我们虽然天天都加班到很晚，就是真的干不完啊。而且……我们同时还干着别的项目呢！是不是很常见？是不是经历了一样的委屈？很难。不过尽管很难，我们仍然会说，项目经理在迭代行军的时候保持好这三种资产，就会舒服得多。即： * 进展感：已经实现目标的个数 * 目标感：预期要实现的目标个数 * 协作感：关于团队的效能，每个迭代能交付的能力的个数 是的，我们做了简化，参见[端到端、即时、极简：极简质效三原则](https://mp.weixin.qq.com/s?__biz=MzU5MjA5MDgwMw==\&mid=2247484083\&idx=1\&sn=8de798a25caddc37ba7b17cc36f15cd1\&scene=21#wechat_redirect)。
## 第一种资产 进展感：已经实现的目标个数 在迭代里的第一种资产就是已经实现的目标个数。很多时候是项目经理根本就不知道有多少目标达成了。甚至很多时候，项目经理只知道任务，不知道目标。因为有些组织天然是任务叙事的（[故事叙事和任务叙事](https://mp.weixin.qq.com/s?__biz=MzU5MjA5MDgwMw==\&mid=2247484452\&idx=1\&sn=056d88b691e311bdccdae9f8a0360284\&scene=21#wechat_redirect)）。他们相信有一张图，制造零件，拼装就能达成目的。通常是先集体造零件，然后才去拼装。而一些团队还天然承担着不同项目的事情。这就导致项目经理很难知道项目的真实进展，我“真的”干完了多少事情了，我“真的”离目标有多远。实际上，很多项目经理连如何对这个资产进行计数都不知道。比如数任务个数的，数功能点的，更有数人天的。就算有几个数故事的，也很有意思，比如通常数的故事并不是真的用户故事，而是一个任务，比如： * XXX功能前端页面 * XXX报表数据加工 * XXX存储过程 * …… 或者是数的故事还没有完全干完，就被列进去了。这个时候可能有些角色会在会议上讲“我干完了啊”，以示迭代里有苦劳，甚至还想要算成功劳。我当然推荐这种进展感用用户故事的个数来表达。不过，要对应到业务目标。一个迭代内如果对应的业务目标是支离破碎的，那项目交付也会如此。每一个项目都干了一点点，但是又什么都没干。而数个数这个事一定要统一迭代里的“完成”定义（DoD）。你也可以理解为故事要有DoD，但是在迭代中这是计数的基准。比如一个故事的完成，它必然被业务/PO认可接受，它应该可以随时发布（比如在UAT环境已经被业务验证），并且在主干分支已经被合并。这样，如果你的DevOps能力足够优秀，想发布是点一下的问题。即使是生产需要隔离的场景，这也不是很难的事情。这样的故事，我们还是有个工具可以帮你保障它的计数过程的，即[七种武器之一枚绣花针：聊聊项目管理里的假干完和真放火](https://mp.weixin.qq.com/s?__biz=MzU5MjA5MDgwMw==\&mid=2247483966\&idx=1\&sn=9a23b9937f3d9f87f46f33058a20a530\&scene=21#wechat_redirect)。既然说到了业务/PO要认可，那半喇咔叽的不是故事的任务就不应该作数。因为这个只是做了，不是真的做完。
这个数很重要。因为很多团队上来不是初创阶段，已经运行了有一段时间。用这个方式，你就能发现一些问题： * 目标设定不清晰 * 任务拆分不合理 * 跨团队配合有问题 * …… 虚假的繁荣假在哪里。 ## 第二种资产 目标感：预期要实现的目标个数 在迭代里的第二种资产是预期下实现的目标个数。这个简单来说就是下一迭代拟交付的业务目标个数（目标），也可以用户故事个数来表述。这是一个协同的活。要参与的角色都知道并且明确才行。有很多时候，就是因为拆分不是故事而是任务，就导致具体做事情的人迷失方向，很容易宣布自己已经干完了，但是实际上又没有干完。关于用户故事有很多工具，比如DEEP，比如INVEST，比如ACT的标准：沙子、板砖、钻石。如何判断拆的是不是故事呢？好像方法比较模糊。这里给出一种比较简单的策略： * 是用户故事则一定能演示 * 是用户故事则一定能完成一个业务功能 哎？一定能演示，我们可是要其他团队配合的，比如要调用某个团队的输出，再输出给另一个团队。那么，搞定它，如果不能，那你就是加工了个零件，你组装的时候重新做基本上是必然了，浪费这个人力不值当啊。为了让用户故事更容易被理解，我建议名字去聊……的优化，……改进之类的字样。借用引导圈的写便签的方法，采用7-15个字的句子比较好一些。对于一个迭代而言项目经理在迭代结束的时候，手里应该握着下个迭代用的所有用户故事，是大家都对齐，并且负责交付的角色可以用来发誓的那种。可以参考[七种武器之一座床子弩：谈谈项目管理里的需求管理](https://mp.weixin.qq.com/s?__biz=MzU5MjA5MDgwMw==\&mid=2247483982\&idx=1\&sn=4d756fdb47545bb8df2b7ee47e02bf3d\&scene=21#wechat_redirect)。可以用来发誓就有一个非常好的判断方法，就是如果没有兑现，就可以用雷劈了。 ## 第三种资产 协作感：团队的效能 在迭代里的第三种资产是团队稳定的效能，即每迭代以当前团队的能力稳定输出的用户故事个数。很多团队是不知道自己这个能力的，所以也不知道自己究竟能背多大的锅，这在之前的文章[七种武器之一口大铁锅：聊聊在项目管理里你有多大的胆，你能甩多大的锅](https://mp.weixin.qq.com/s?__biz=MzU5MjA5MDgwMw==\&mid=2247483975\&idx=1\&sn=88f1e8c9c04e1d8a62a5674428090927\&scene=21#wechat_redirect)里有讲。 知道自己的能力，才能评估目标能不能达成，这条路能不能按期走到终点。从目标达成的角度，这就是个简单的算法，剩多少，每个迭代能做多少。这个时候就需要多考虑，什么不需要做，什么可以做得简单一些，要在什么时间加人才行，因为加人，也是需要时间和适应周期的。
## 迭代行军 一个项目的过程有点像走一条徒步路线或者是参加越野跑比赛。能在短时间内跑完的屈指可数。比如168组的赵家驹和向付召。即便如此强横的世界级跑者，蜀道山的168，赵家驹用了不到24小时，可是到后面也是筋疲力尽了。
所以通常我们还是会分段来完成。比如深圳的鲲鹏径，全长200km，一共分了20段。按我现在的体能，一天最多3段，可是要连续这么做战，恐怕也很难达成。这就是第三个资产的重要性。对于我来说，这第三个资产我就是介于一天2-3段之间。太满就后继乏力了。如果真从头走一遍，一天2段是个比较合理的范围。
而走一段就是一段的资产。这就是[告别“虚假完成”：让迭代回归真实交付的策略](https://mp.weixin.qq.com/s?__biz=MzU5MjA5MDgwMw==\&mid=2247484373\&idx=1\&sn=5c5568a0295f071bbd4c5e8757f91ad9\&scene=21#wechat_redirect)的意义。而预计一段，清晰的一段也是让我们能从容面对一个大项目，而不是全力输出，到某一刻崩溃。
## 所以 当你手中握有这三种资产，至少在你的项目过程中已经做好了迭代的“财务管理”。如果参照计划已经完成超出预期，就稳稳的是个富家翁，所谓家有余粮，心中不慌。如果这三样入不敷出，那你就知道风险了。不过至少你比一样没有的人好一些，你们已经不是一个级别了。因为你还有补救之法，而什么都没有的，只能靠天意了。