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