标签： 系统思考

在第一部分，我们分析了把平台定义为产品的情况。现在，我们来分析把产品领域定义为产品的情况。那些产品确实都有客户视角，但是我们有可能定义一个更宽泛的产品，然后那些产品就变成了宽泛产品定义下的产品领域。让我们进一步分成两种情况，一种是把解决方案定义为产品；另一种是把产品系列定义为产品。 把解决方案定义为产品 解决方案包括若干产品，它们之间交互产生客户价值。让我们来看两个例子。在电信网络中，无线接入网是一个解决方案，而基站和基站控制器是其中独立的产品，也就是网络解决方案中的网元。在电子商务中，电子商务平台给客户提供了端到端的解决方案，而购物、支付、物流是其中独立的产品，也就是整体解决方案中的元素。解决方案往往会演进成一个开发的生态系统。我们可以把解决方案重新定义为产品，那样在同一解决方案中的产品就变成了产品领域。 1. 产品化、同步和灵活性 虽然在解决方案中产品之间的关系与第一部分中阐述的应用产品和平台产品之间的关系有所不同，以下呈现的动态却很相似。 产品化是推动狭窄产品定义的一个关键驱动力，这由B1回路呈现。产品化的支持包括市场、销售、预算等。一旦这方面有差距，我们把原本只是属于同一产品的不同领域定义为独立的产品。这增加了产品导向，带来更好的产品化支持，最终关闭这方面的差距。 为了在解决方案层面交付价值，相关的部分必须同步起来。独立产品降低了相互之间的同步程度，从而延长了周期时间。更长的周期时间带来时间上的压力，它形成了对产品独立和狭窄产品定义的制约。这个动态由B2回路呈现。 产品独立也会在狭窄产品之间产生部门墙效应，这降低了整体的灵活性。当一个产品有更多高价值的工作时，是很难从另外产品调动团队工作到这个产品上的。当整个解决方案还是充满不确定性，并且整个组织的规模还较小时，我们会期望有更高的灵活性。因此，它也形成了对产品独立和狭窄产品定义的制约。这个动态由B3回路呈现。 与把平台产品化类似，在解决方案中形成独立的产品也最好通过涌现而非事先计划。过早的产品独立带来的问题比它解决的问题还更多些。 2. 局部创新和整体创新 局部创新和整体创新是另一对权衡。局部创新指的是在每一个狭窄产品内的创新，而整体创新指的是在解决方案层面的创新。 狭窄产品定义通过聚焦帮助推动局部创新，这由B4回路呈现。它是推动狭窄产品定义的驱动力。然而，产品独立产生部门墙效应，从而损害了同一解决方案中的产品间协作，降低了整体创新。当感知到整体创新不足时，我们可以通过定义宽泛的产品来降低部门墙效应，增进协作，从而提升整体创新。这个动态由B5回路呈现，它形成了对狭窄产品定义的制约。 也有组织选择不同的平衡回路来应对整体创新的不足。他们不是通过宽泛产品定义，而是通过创建跨产品的工作组来提升协作，以推动整体创新。这个动态由B6回路呈现。理论上来说这是个好主意，然而实践中把那些工作组的结果落实到各自独立的产品中是一个挑战。定义宽泛产品和创建工作组也是可以互补的。 把产品系列定义为产品 产品系列包括若干服务于同一市场但不同客户群的产品，比如一些是高端的，另一些是低端的。通常它们也会共享大部分的代码库。我们可以把产品系列重新定义为产品，那样在同一产品系列里的产品就变成了产品领域。 1. 关注、竞争和混乱 我们首先来分析与业务和客户相关的动态。对客户的关注能增加客户满意度，而让客户感到混乱则降低客户满意度。这里的竞争是指同个产品系列里的不同产品对业务和客户的竞争。 狭窄产品定义的一个驱动力是更好地服务客户。产品定义得越狭窄，那些对应的客户得到关注越多。这增加了客户满意度，从而客户压力得到释放。这个动态由B7回路呈现。 当同一产品系列里的每个产品都各自发展时，相互的对齐变弱。产品之间的竞争加剧，最终意识到对齐不足。这会触发重新定义一个宽泛的产品，从而增加对齐以使竞争可控。这个动态由B8回路呈现，它形成了对狭窄产品定义的制约。 有意思的是当对齐变弱时，客户感到的混乱也会加剧，因为他们可能使用同一产品系列里的多个产品，会收到不同的甚至是冲突的市场信息。这种混乱感使客户满意度降低。这个意外的后果由R1回路呈现。B7回路和R1回路一起构成了“饮鸩止渴”系统基模的动态。 2. 重复工作和通用组件 让我们再来分析与开发相关的动态。重复工作对开发成本有负面的影响，而通用组件则能降低成本。 当同一产品系列里的每个产品都各自发展时，它们之间的透明性变低，从而产生更少的通用组件，导致更多重复工作。重复工作增加了开发成本，因此成本压力变大。针对重复工作的一个解决方案是把产品系列定义为宽泛产品，而之前的产品就成了这个产品里的产品领域。这样做增加了透明性，以使更多的通用组件涌现成为可能，带来重复工作减少，进而开发成本降低，成本压力得以释放。这个动态由B9回路呈现，它形成了对狭窄产品定义的制约。 针对重复工作还有另一个常见的解决方案，就是围绕潜在的通用组件创建组织。这些组织驱动组件被使用，以使它们成为真正的通用组件，带来重复工作减少，进而开发成本降低，成本压力得以释放。这个动态由B10回路呈现。你可能已经注意到这本质上就是我们在第一部分阐述过的“平台是一个组件”的情况。 B9回路和B10回路是创建通用组件的两种不同方式，一种是通过透明性使它成为可能，另一种是定义它。在我的经验里，涌现通常比事先定义工作得更好。 总结 狭窄还是宽泛的产品定义是个很大的话题，有着非常多的上下文差异。这两篇文章（第一部分和第二部分）还远非全面。我总结一下其中涉及的主要权衡和陷阱。 产品化是狭窄产品定义的一个关键驱动力。因为正确的狭窄产品通常是涌现的，我们应当避免过早将它们分离出来。 周期时间和灵活性的考虑是对狭窄产品定义的主要制约。无论定义的是真正的产品还是只是平台组件，都是如此。 通用组件和重用平台对降低开发成本有利，但并不需要把它们定义为产品并附于开发组织。 狭窄产品定义可能在以牺牲整体创新为代价推动局部创新。 英文版：https://blog.odd-e.com/yilv/2018/03/seeing-the-system-dynamic-narrow-vs-broad-product-definition---part-2.html...

什么是产品？这是一个组织设计中的关键问题。你可以狭窄或者宽泛地定义产品，由此定义产品的范围是一个连续体。我们将分两部分来认识不同选择背后的因素和动态。在第一部分，我们会分析将平台定义为产品的情况；在第二部分，我们会分析将产品领域定义为产品的情况。 平台是个在很多产品组织里都很流行的概念。平台经常被当作产品来对待，对应到组织，围绕它有相应的产品待办列表和团队。在多数情况下，平台不面对外部客户，因此本质上还是组件。平台和应用一起形成一个产品，这种情况呈现在上图的左半部分。在有些情况下，平台有独立于应用的外部客户，因此确实是产品。平台和应用就是两个面向不同客户的产品，这种情况呈现在上图的右半部分。让我们分别来展开。 平台是一个组件 为什么组织选择把平台定义为产品，即使它本质上只是一个组件？为了重用 - 多个应用可以重用同一个平台，从而节省开发成本。B1平衡回路呈现了该动态。目标是达到成本预算；行动是定义狭窄的产品，也就是平台，来推广重用。背后的推理是平台提升了重用程度，因此降低了开发成本，从而减轻成本压力。 为什么组织不选择把平台定义为产品？这里有另一个平衡回路B2在起作用。当定义了更小的平台后，客户价值的交付会牵扯更多的平台。彼此的同步程度越来越低，因此周期时间越来越长。这带来了时间压力，形成了对把更多平台定义为产品的抑制力。归根结底这是个在某个时期哪个平衡回路占据主导的问题。 让这变得更为有趣的是，异步性带来了等待，由此产生浪费，反而增加了开发成本。这样就形成了一个增强回路R1。B1回路和R1回路一起构成了“饮鸩止渴”系统基模的动态。当B1回路主导时，R1回路处在恶性循环中，从而伤害了达到成本预算的目标。当B2回路主导时，R1回路处在良性循环中，不仅对时间目标有利，还能帮助达到成本预算。这部分的动态体现在下图中。 回到重用的初衷，有什么其它办法能增加重用程度？内部开源是一种方式。采用它最大的挑战来自于其自然发展的本质 - 只能培育它而不能控制它。 平台是一个产品 当平台除了内部应用之外也面向外部客户时，它确实是一个产品，这时就涉及不同的权衡了。 在这种情况下，把平台定义为产品主要的驱动力就不在于开发成本了，而是需要将产品带入市场所需要的聚焦和支持。B3回路呈现了这一点。产品化的支持包括市场、销售、预算等。一旦这方面有差距，我们把平台定义为与应用产品独立的产品。这增加了产品导向，带来更好的产品化支持，最终关闭这方面的差距。 但是，这同时会对应用产品带来影响。当平台自主运作后，来自应用的需求就更难同步响应了。因此周期时间变长，导致时间压力变大。这就是之前的B2回路，它对把更多平台定义为产品形成了一种抑制力。 在现实中，平台产品更多是涌现出来，而不是被正确地预先定义出来。我见过很多平台从未变成真正的产品；那些成为真正产品的平台却很少是被预先定义的。和重用组件一样，平台产品的涌现最好也是被培育而非计划。当过早把平台定义为产品时，它损害了应用产品的交付，同时也没能在做出成功的平台产品方面达到预期效果。 在第二部分，我们会来看是将其定义为一个狭窄的产品还是将其定义为一个更宽泛产品中的产品领域。 英文版：https://blog.odd-e.com/yilv/2018/03/seeing-the-system-dynamic-narrow-vs-broad-product-definition---part-1.html...

历史 差不多在一年前有了“把系统思考带给更多人”的想法，到2017年7月才付诸行动。当时倡议共创系统思考工作坊，得到了很多朋友的响应，在2017年9月的杭州钱塘江畔通过两天的共创有了系统思考工作坊的第一个版本。过去的半年里大家在不同城市不同公司将它带给了更多人，同时工作坊本身也得到了演进。在去年12月我邀请有兴趣把系统思考带给更多人的朋友今年3月在杭州聚会，也就是刚发生的事，给大家做个更新。 2017年7月，把系统思考带给更多人 2017年9月，系统思考工作坊共创 2017年12月，系统思考工作坊进展和后续 2018年3月，“把系统思考带给更多人”聚会 “把系统思考带给更多人”有一个目标是到2019年底让3000人通过我们的工作坊学习了系统思考，到目前为止我们已经带给了～750人，算是完成了四分之一。从这个角度来说，我们在扎实地进展：） 聚会 这次聚会的第一天在保俶塔边的纯真年代书吧，其实是最初就想去的地方，也算了却一桩心愿。总共有16人参加，其中11人参加了去年9月系统思考工作坊第一版的共创，另外5人则是新加入。   两天聚会每天各有一个主题，第一天围绕现有工作坊，第二天围绕未来的扩展。具体日程是大家共同创建的，我对其中的一些内容简单做个更新。 在第一天里，Tony、晓云、长虹、Philip和王磊各自分享了他们现有工作坊的内容和交付方式，这部分对新加入的朋友尤其有帮助。对工作坊之后跟进和落地的讨论让大家对以后发展演进有了更清晰的思路，我会在后续部分分享。系统思考和某个话题（比如研发管理）结合的讨论让大家对如何定位工作坊有了更深入的理解。如何引导复杂动态建模的讨论则让大家得到了互相学习的机会。最后福润还分享了他长期以来总结的轻量思考。 在第二天里，一些朋友对在今年TiD大会上的系统思考时段（有三天）共同做了设计。大家讨论了如何使我们的工作坊能面向社区持续组织，如何把它带到目前还没有涉及的城市。我们对如何分享信息形成了共识，对外的分享会通过github生成的内容网页来做，而内部的共享则使用云盘。第一版的工作坊着重于分析问题，如何找到杠杆点是自然的下一步，我们讨论了如何自己实践，如何引导帮助其他人实践。下午还对系统思考和U型理论，如何提升自身的系统思考能力等话题做了交流。 后续 这次聚会对我来说一个重要的收获是大家对如何继续有了更清晰的思路和共识。 “把系统思考带给更多人”有两个层面，一是更多人对系统思考产生兴趣；二是更多人成为系统思考实践者。很难期望一个一天的工作坊能够让人持续实践系统思考，而在自己公司内部就有更多跟进落实的可能性。事实上，现有的共创成员在各自公司内部确实产生了更为持续的影响，比如华为、东软、中兴、诺基亚等。如果能有多位成员来自同一公司，又能产生更强的合力。所以我们希望通过社区工作坊让更多来自不同公司的朋友对系统思考产生兴趣，其中一些或许会有兴趣把系统思考带回他们所在的公司。简而言之，社区唤起兴趣，公司推动实践。 我们整理了“把系统思考带给更多人”的群组，决定保留两个。 1、“把系统思考带给更多人-兴趣组”，这是一个开放的群组，只要你对系统思考感兴趣就可以加入。除了系统思考相关的讨论交流外，我们也会把各地的社区课程通知到群里，方便有兴趣的人参加。社区课程在大连、杭州、上海、北京至少会保持每季度一次的频率，如果你不在以上城市，但是希望在自己的城市安排工作坊，只要在群里提出来，相信会有人响应的：） 2、“把系统思考带给更多人-共创组”，这个群组只包含参与过共创的朋友。目前为止就是参加了去年9月和/或今年3月活动的朋友。至少在2019年底之前，我们会每半年组织一次聚会，进一步共创和推动“把系统思考带给更多人”，所以你至少还有三次机会加入其中。聚会的具体安排和报名会在“把系统思考带给更多人-兴趣组”提前发布。 吕毅，2018.3...