# 项目经理保持迭代行军的三种资产 经常有项目经理被问到： * 现在什么都理好了，为什么你们的交付老是出问题？！ * 现在不就是在搬砖吗？ * 不能及时上线，是不是你们不够努力啊？ * …… 然后项目经理只有望一眼还在增加的需求，和其他团队因为配合搁置的功能，唉声叹气。这个时候，当我们去跟他们讲敏捷的时候，通常都会说，我们搞的就是敏捷啊，你看我们有迭代，有计划会、有评审会，每迭代我们还开回顾会呢！可是业务在压、别的团队不配合，我们虽然天天都加班到很晚，就是真的干不完啊。而且……我们同时还干着别的项目呢！是不是很常见？是不是经历了一样的委屈？很难。不过尽管很难，我们仍然会说，项目经理在迭代行军的时候保持好这三种资产，就会舒服得多。即： * 进展感：已经实现目标的个数 * 目标感：预期要实现的目标个数 * 协作感：关于团队的效能，每个迭代能交付的能力的个数 是的，我们做了简化，参见[端到端、即时、极简：极简质效三原则](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)的意义。而预计一段，清晰的一段也是让我们能从容面对一个大项目，而不是全力输出，到某一刻崩溃。
## 所以 当你手中握有这三种资产，至少在你的项目过程中已经做好了迭代的“财务管理”。如果参照计划已经完成超出预期，就稳稳的是个富家翁，所谓家有余粮，心中不慌。如果这三样入不敷出，那你就知道风险了。不过至少你比一样没有的人好一些，你们已经不是一个级别了。因为你还有补救之法，而什么都没有的，只能靠天意了。
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://www.oulan.com/1ux/agile/simplyagile/3-asset-for-pm.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.