本来不打算写这个话题，因为其本质早已经被吕毅老师的系列文章讲透了。但是最近一些讨论中发现还是有必要用更浅显的方式讲一下。具体的触发点是发现很多人都持一个观点：“SAFe的多个backlog导致SILO化”。其实此观点不太成立。
首先做一个小练习。
如下图所示。迭代计划中，前10个特性已被领走，图中已选的颜色是各组最擅长的需求领域。团队1剩余的Capacity还可以做2个擅长领域的特性；但如果选非擅长领域，最多能够完成1个。
问题：Team 1 应该选什么任务？
第一种做法是跳过Team 1不熟悉的11/12， 去选符合他们技能的13、14。如果产品经理总是让团队这么选，那么这意味着产品Backlog并非首先按照客户价值排序，而是首先按照团队领域排序 ——那么事实上产品Backlog就内置了三个独立的优先级系统，成为三份不同的backlog。这就是所谓的仓筒化；最大化资源利用率的思维方式容易导致此现象。
第二种做法是Team 1按照优先级去选11（练习中这是大部分人的选择）。这样他们牺牲一点速率，但所有团队按照同一个客户价值工作，并且团队能力有更大成长空间。延续这种做法，将来的需求会有越来越灵活的团队选项，从而避免瓶颈。
实际上，在物理上具备同一份产品级Backlog的情况下，不会真的有产品经理会始终采用第一种做法，因为工作量不平衡的状态很容易暴露出来。这是采用同一份产品Backlog/同一个产品经理的意义。
第二种做法有一种极端情况是完全放弃团队领域专业化，这种实践也是需要谨慎采用的，考虑要素除了产品规模之外，还有团队稳定性（团队越稳定，越有利于向更宽领域发展）。虽然我们需要避免过度专业化导致的仓筒化，但同时适度专业化可以在两个维度上找到更好的平衡：1 - 效率考量； 2 - 有利于团队早期参与需求，从而避免规模化场景下的“需求分层交接”范式。
那么，为什么说SAFe的“多个Backlog”并不会导致仓筒化？因为，正如前面图中所示，多个团队Backlog之上是同一份产品Backlog。产品经理是不关心团队Backlog的内容的，他只关心产品Backlog。只要产品经理正常履行他的职责 - 基于客户价值定义优先级，而非基于团队能力定义优先级 - 那么“多份Backlog导致的仓筒化”就不会发生。
BTW, 回到前面的问题，我个人最推荐的选择是让Team 1跟其他团队协商，在3~11之间选一个最合适的任务（合适的意思包括其他团队的必要支持）。假如你认可我这个推荐，我送你一道相关思考题：你认为多团队的迭代计划应如何设计？
