告别“虚假完成”：让迭代回归真实交付的策略
最后更新于
这有帮助吗？
最后更新于
这有帮助吗？
“登高必自卑，行远必自迩。”
在很久以前我们就写了。这个武器还真可以算一个不错的诊断工具。这个绣花针扎的是小事，但在组织改进的过程中却会有非常好的效果。
我一个朋友说，他到新团队里这一招特别管用。他是个公司级的敏捷教练。我另一个朋友也这么说，他是PMO。以前光看一堆团队的周报、迭代报告就头大得不行。现在好了，几针下去，哪个数是真的，哪个数是假的自然就知道了。他还很开心的把夕会里进行Showcase做成实践，时间方便就可以去团队里例席，发现问题，给团队真正的支持。
细心的你可能已经看出来了，与直接的生产力提升不同，这些招式都是基于管理方式的，或者可以称为是生产关系方面的调整。因为很多时候组织比较容易关注在效能的某些方面，所以这个方面往往不大容易被注意到。
“庞葱与太子质于邯郸，谓魏王曰：‘今一人言市有虎，王信之乎？’王曰：‘否。’‘二人言市有虎，王信之乎？’王曰：‘寡人疑之矣。’‘三人言市有虎，王信之乎？’王曰：‘寡人信之矣。’庞葱曰：‘夫市之无虎明矣，然而三人言而成虎。今邯郸去大梁也远于市，而议臣者过于三人，愿王察之。’王曰：‘寡人自为知。’于是辞行，而谗言先至。后太子罢质，果不得见。”
为什么我会重新提这个事情呢？大概是最近又有几个朋友问我相同的问题。这些问题其实或多或少在以前讲过很多次。比如前一段有个朋友问我，他们的研发要和外部供应商协同，但是每个开发的迭代和外部供应商联调的时候，每个迭代的需求都测不完，数量还不少。很多是一联调就掉坑，一步一个坑。接口明明沟通清楚了，但是一联调就发现需要重新对逻辑，成本高，交付延期。
这是以前经常分享的案例。为什么很多团队还是会遇到呢？大概率是很多时候所谓的“相信科学”、相信“最佳实践”，忽视了发生这种事情的背景。马云曾经说过“作为创业者，不要去学别人如何成功，去学他们如何失败的。”
研发的成果通常都不可视。关于团队现在的进展现有的管理模式通常都是听每个团队自己的汇报。这是解耦之功。解耦让大规模应用成为可能，这当然是好事。但是这也加剧了另外一件事。就是每个团队看到的“进展”都是片面的。
这样他们在描述的“进展”的时候也会容易报喜不报忧：“反正我干完了，问题都是XX团队不给力，没有配合好。”就从这点来说，项目的进展就比较容易罗生门。
虽然每个团队，每个迭代的数据都挺好看，但是一到要上线，就出现大问题：配合部分被忽视了。
“大多数人所共有的东西得到的关注最少。人们最关注自己的东西：他们不太关心共有的东西。”
对于组织而言，项目/产品的成功是依赖于团队之间的协作的。倘若我们真的去查看团队/成员间的协作就会发现：
需求都拆分到了个人任务的，但是协作部分有的就没有
即使有协作部分的，很可能安排了所有协作方的人，但是没有人真的为此负责
有些协作部分的配合对一些团队来说收益甚微，不愿意干，优先级很低，但是这个部分对另一个团队来说优先级却是决生死
有些协作部分需要内部结算，于是有些团队就狮子大开口，不同意，干不出来是你的事……
很多时候对于此类协作，缺乏管理措施，最后有的就演变成PUA，比如你为什么不去求他们？为什么XX就有人配合？为什么不去陪着开发团队加班？更有甚者暴露了管理者的自行车棚上限：是不是你的穿衣风格和我们团队的调性不符，看着不像个干活的……
大部分团队关于协作部分的解释都是别人的问题
大部分团队关于协作部分的解决方案都是反正我是干完了
……
因为太重视解耦了，所以耦合部分就成为了公地。成了谈判的砝码。零件我们大可以使劲生产，至于装配不上，非标准才能拿捏别人。
“一个人走得快，一群人走得远。”
如果希望让迭代回归到真实的交付而非表演“进展”，其实无非是在解耦的时候关注一下耦合的部分。这个部分不能只是让团队自发去处理，而是管理者，特别是组织级的管理需要注意的。很多团队对于什么算是“干完”是没有共同认知的。这也是造成团队喜欢制造零件的重要原因。更有甚者，很多团队对于什么“可以干”都没有标准。这也导致他们对业务方的承诺酷似AI：
但是大物始于小，改进知于微。
如果组织中关于什么“可以干”，什么才能算“完成”都没有明确的共识的话，特别是虽然有共识但是共识部分不包含协同部分的话，解耦将引发灾难，加工零件，而不是交付装配完的产品就成为团队不约而同的下限。如果考虑到协同部分，关于“可以干”和“完成”的共识，至少应该包括：
不论何种原因演示要包括上、下游-即可能有外部供应商的接口部分
什么可以算“完成”，迭代内的故事要可以演示，演示通过才“完成”
什么“可以干”，那在迭代排期的时候，可以承诺演示的才可以排入
或者有人会说，大哥，你这么玩不行啊，我们的需求就没有这么小的。根本拆不开。那你就撞我枪口上了。如果一个需求不能拆，你还能把它加工出来，你不觉得这逻辑有多大的问题吗？
“八成熟、十成收，十成熟、二成丢。”
如果希望迭代回归真实交付，还有一件事情是要注意的，那就是要注意颗粒归仓，不能贪大而全。需求能做完吗？那当然能：如果不增加。为什么现实中我见过所有的团队需求都做不完呢？因为它一直在增加啊。
有个研发团队的朋友就告诉过我，他们团队的需求一直在膨胀：
本来业务够用的，可是产品一介绍说，这个地方还可以如此这般，就又加了一个需求
有些功能明明现在用不上，或者用的频率很低，有更重要的事要做，但是一句你们加加班，然后就进入了待办清单
某领导的KPI
某领导的OKR
竞品有这个特性，为什么我们没有？
……
做得完才怪。
虽然我们经常说MVP，可是一规划那就不只是MVP了，是这个也要，那个也要。
明明是搁浅的小鱼扔到海里就可以，非要搞生态，必须送到最适合它生存的水域，反倒导致越救，能救的数量越少。
颗粒归仓，农谚最是贴切：八成熟，十成收；十成熟，二成丢。
“凡事豫则立，不豫则废。言前定，则不跲；事前定，则不困；行前定，则不疚；道前定，则不穷。”
这对组织来说真不是个好事情。虽然我常常分享、常常提醒、常常写案例、写原理，但是很多团队还真的陷入这个怪圈，越学习成功案例就越出问题。真正有用的工具，比如一提到这样的就怕疼。这对我来说还真是个好事情。
我们其实从失败的案例中很快就能发现教训。比如借助，我们是可以发现团队成员之间、团队之间是否有目标感的。但是管理上的有些指标的牵引作用（参见：），却让大家乐此不疲。
忙着秀“进展”，忙着产出零件，就成了经常能见到的现象，至于等到出现了问题，就开始甩锅。由于太关注做了多少，而忽视了自己的锅可以有多大，虽然可以借助一下：。反正大家都在甩，最后锅落谁家就不重要了。对后面的改进了不大。最后积累了甩锅经验者胜。然后该发生的仍然发生。
如果你还不知道你的团队是真干完，还是虚拟繁荣，建议你重温一下本文提了多遍的。在项目的前期，也许扎一针可以让你之后少受困扰。在项目的后期，断然杜绝纸包火来一次大爆炸的可能。
