前些年去法国自驾，发现法国道路上的红绿灯特别少，大部分的路口都被设计成环岛（见下左图）。而在国内，这样的设计非常少，大部分是十字路口（见下右图）。两种路口的目标都是为了更好的让车辆通行，那么哪种是更好的设计呢？答案是各有利弊！
环岛的优势是不需要红绿灯（环保），车辆进入路口时基本无需等待。而十字路口在大流量时通行效率更高（车辆无需在岛内绕行），而在乡村车辆很少时，可能会造成车辆空等。如果路口有大于4条路交汇（比方上海的五角场），十字路口的信号灯设计将会非常复杂，远不如环岛效率高。但环岛对于司机的要求很高，需要理解的规则比信号灯复杂。
之所以提到这个例子，是想提醒大家，我们在讨论一种模式或者工具时，很多时候我们会强调它的优势，而选择性的忽视其的局限。只有从各个角度去了解事物时，才能获得更多的洞察和更深的理解。
上一期我们从一个实际的案例展示了如何用 SoS 的方式运作一个大型的项目。这期我们将继续深入讨论 SoS 可能的不足之处。问大家两个问题：
1.上期案例中这样运作 SoS 哪些地方可能出现问题？
2.我们该如何应对？
在我们展开进一步讨论前，大家可以先思考一下，看看有没有自己的答案？
现在让我们从以下2个主要方面对 SoS 展开更多讨论，看看可能出现的问题。
1.需求管理
2.团队协作
需求管理
上一期中，我们提到张这幅需求分层的图，这是一个洋葱式逻辑包含关系的图。
如果我们从时间维度或者说生命周期来看的话，那么需求分解的图应该是怎么样的呢？（这里假设需求只需要拆分成3层）
上图展示了非常理想的状况，需求可以“快速分析和拆分，快速启动开发，迭代交付”。然后事实通常是如下图所示，可能会遇到反复调整方案，没有资源启动等等问题。
问题1：
在“真实情况”中，solution 通常从提出到开发会经历很久，有些时候是因为需求的反复变更，有些时候是 solution 的反复修改，而有些时候时要等待合适的开发资源。在 SoS 的框架中，我们会发现 APO-OPO 的沟通模式会有很多的交接，这增加了快速启动前等待的时间，最糟糕是，完整的 solution 已经在文件夹中躺了1年以上。而且，通常在开发资源准备好时，solution 很可能要重新刷新。
解决：
● 简化 solution 的制订，从最初的一个几十页的文档简化到 one page solution（PPT），只列出这个 solution 最关键的一些要点，并做一些简单的拆分。这里遵循的原则是避免提前，过度的设计。这里通常由 APO 负责，有时也会指定由某个 OPO(Operational PO)负责。
● 在预测到开发资源可能准备好时，通常1名或多名 OPO 将会对 solution 以及拆分的 feature 做进一步详细设计，并将需求细化。
这样我们就可以在需求出现时不必做过度的设计，而且也避免了过时的重新设计。
团队协作
在大团队进行协作时，一个无法避免的问题就是高昂的沟通协调成本。在 SoS 的框架下，由于引入了 APO-OPO，SoS-Team 双层结构，不可避免会加剧这样的问题。
问题2：
某些 solution，甚至 feature 是跨 area 的，需要不同 area 的 PO 与 team 进行协同。
解决：
由于 area 是相对静态设置，因此不可避免的会有一些需求穿越 area。解决方案：
● 尽量由同一 area 的 APO，OPO，team 负责主导。实际开发过程中，由一名 OPO 负责澄清需求，并且设置需求优先级。同时 team 的 scrum master 之间会建立一个团队层面的沟通机制，来协调进度和开发依赖。
● 之前提到 team 一般会有1-2个 primary domain, 2-3 secondary domain 的开发能力。因此一个 team 原则上是可以跨 area 工作的。这个在一定程度上缓解了这个问题。
● 尽量在架构与技术上解藕（这个依赖良好的软件架构），使两个团队可以独立开发和发布。
工具支持：我们在 PO 群建立一个需求看板，在各个 SoS 建立 SoS 共享看板，每个 Scrum 团队也有各自的白板。同时各个团队（包括 PO，SWAT）建立各自的 wiki，将团队信息发布出去。可以借助的工具包括 Jira，Teambition 等等。（P.S. Teambition 的知识库是很好的共享团队知识的工具。）
总结：以上列举了两个在 SoS 框架下可能发生的问题。我们可以看到，在 SoS 框架中，普遍来说信息沟通与决策链条会拉长，因此克服这些短板就成了很大的挑战。一方面在拆分需求时能消除复杂性，尽量避免需要大量的沟通；另一面，要给予团队更多的赋权和赋能，让他们能灵活处理各种问题。文章的开头我们提到了十字路口适合大流量的通行，但必须高度依赖信号灯。同样地，在团队协作时，我们需要有一些协作工具，例如 Jira, Teambition 等等。正是这些工具的出现，才使得团队有能力完成复杂协作，包括信息共享，知识共享，创新等等。
另外，敏捷开发依然是高度依赖人的开发模式，如果产品开发过程中，团队没有成长，总会遇到某种模式所无法克服的问题。相反，团队如果能持续成长，那么就能灵活运用各种模式，实现真正的敏捷！
作者：周巍，ThoughtWorks 高级咨询师，16年的工作经验，具备 CSPO，CSM，CSP 等资格认证。擅长精益（LEAN）与敏捷等辅导，关注管理方式的变革，帮助组织与团队持续提升响应力与交付价值。曾经服务过的客户包括华为，中国银行，汇丰银行，招商银行，中国电信这样的大型企业，也包括像 AHA 社会创业学院这样的创业孵化器。
