产品 - Odd-e中国

项目管理不适合软件开发

2018-05-082018-05-08 由张博超没有评论

首先我想澄清的是：项目管理本身没什么问题，但是把项目管理用在产品管理上这就是问题了，可惜90%的软件开发都是软件产品开发。在我接触到的公司或案例中，项目管理在软件产品开发中带来的伤害要远多于好处。项目管理维基百科上项目管理以及项目的定义： Project management is the practice of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and meet specific success criteria at the specified time. A project is a temporary endeavor designed to produce a unique product, service or result with a defined beginning and end (usually time-constrained, and often constrained by funding or staffing) undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value. https://en.wikipedia.org/wiki/Project_management 这里面有几个关键：明确的开始，明确的结束，明确的目标，临时的。据我所知，这些在大多数的软件产品开发中都很少见。多大概率你在工作中碰到的需求、产品、功能说在一个时间点结束就真的在这个时间点结束了？总会有各种形式的修改，修Bug，增加，删减等。软件开发中也几乎没有什么临时的，很多时候我们碰到一些“临时”的功能或任务实际存在的时间可都不短，有的甚至比我在公司待的时间都长。项目管理的思维包含着可预测性。大家可能都知道项目管理的铁三角：范围、时间、成本。需求的范围，各种时间节点，需要的成本（主要是人力成本），这些是评估一个项目管理是否成功的重要因素。一个项目在预期的时间内按照一定的成本完成了全部的功能，从项目管理的角度来看确实很棒。但是这个项目就真的成功了吗？某大型企业有过一次回顾讨论，他们有个项目按时按量交付了，还没有bug！但是大家都不觉得这个项目成功了，为什么？没有人买也没有人用，当然没bug了。项目管理的思维方式可能会带来的问题：长时间的计划项目管理需要控制成本，因此需要一开始分析或“翻译”需求，明确范围，估算工作，制定预算，我见过不少项目在计划上的时间都多于开发交付的时间。大量并行项目计划的时间长，往往意味着同时进行的项目多。我还见过有的公司里一个需求就是一个项目，同时有几十个项目并行很常见。大量并行的项目会使这些项目的计划，追踪等更加的复杂。你可以想想许多公司根据项目抽调人员，还有很多角色是共享的，比如UI/UX，测试，运维等等，再加上项目和项目之间还会有些依赖，要做所谓的“排期”就已经十分的头大了，再稍微有些延期或其它变化就一团乱了。争夺人员与资源前面也说道按项目抽调人员是比较常见的现象，因为每个项目为了每个项目的成功都会尽可能的争夺对该项目最有帮助的人员或资源。因此产生的斗争和内耗也会很多，这是典型的局部优化。往往公司里能力越强的人同时做的项目越多，这个人会自己决定手头上事情的优先级。而且也会导致这类人的工作效率的下降，因为需要频繁的切换工作上下文。关注在需求范围而非目的项目结束时，大家更关注需求是否做完，也就导致项目过程中关注于计划的执行情况，这些需求本身有没有完成。大家会更少关注于这些需求背后的目的是否达成，是否有在产生价值。我们需要更多的关注产生的影响（Outcome），而不是我们的工作产出本身（Output）。这就要我们不断的验证假设，收集反馈，调整方向。实现不必要的功能项目就像一个容器，我们会对里面的“所有东西”进行计划，分析，设计，实现，测试，发布。但是从产品或业务的角度来看，这些都是成本，但是不是都产生价值呢？而且这些不必要功能的存在也会带来维护成本。我们是不是应该对项目的需求范围进行质疑，而不是一味的遵循呢？降低质量项目管理更加看重时间和成本，所以当截止日期逼近的时候，大多数开发人员会迫于可种压力在时间和质量之间作出选择，这是质量往往是被妥协的。有时他们选择不重构，不做单元测试，甚至不自测，甚至使用各种秘密武器：复制黏贴，从网上抄一段代码等等。技术负债就这样积累起来了，代码库变的难以维护，后续功能调整越来越难，成本越来越高。对于测试也是一样，测试的压力更大，测试强度也会减弱许多，比如不做回归测试或更小范围的回归测试，测试路径覆盖更少等。很多时候这种质量问题的结果并不会立刻显现。产品负责人与项目负责人这里产品负责人并不仅仅指Scrum中的Product Owner，项目负责人有可能是Project Manager或Program Manager。通常这两种角色有着天然的冲突，产品负责人关注价值，项目负责人关注计划的执行。项目负责人占上峰时，产品负责人失去对产品的控制力，只是负责管理需求列表；产品负责人占优势时，项目负责人只有职责却缺少实际控制力。我见过有的公司产品负责人还同时管项目，通常产品负责人大多数时间变成各种事情的协调员，甚至前后端的技术协调。所以，你得弄清楚你真的是做临时项目吗？如果不是，那么你应该用产品思维来管理。产品通常是长期存在，关注于为客户带来价值，你会持续的对其进行修改、改进、扩展。当然你需要持续的迭代，尽快的从客户或最终用户那里收集反馈来调整后续的工作。即使你是做软件外包项目，如果你和客户是长期合作关系，依然你可以用产品的方式来做，因为你的开发过程会更加的顺畅，而客户可以获得更多的价值。 PS，有些公司搞所谓的“敏捷转型”也立个项，用项目管理的方式来做。我也是不赞同的，因为这样很容易变成只是在有限的时间内把一些实践给搬到组织内，未必产生实质性的效果，也不利于持续学习与持续改善。我们应该像开发产品一样，不断的试验调整来进行持续的改善我们的研发过程。...

认识组织选项背后的系统动态：一份还是多份产品待办列表

2018-04-21 由吕毅一条评论

在多团队的产品组织中，存在一个选择：采用一份还是多份产品待办列表。因为试点起始于一个团队或者产品本身起始于一个团队，通常会从一份产品待办列表出发。引入多个团队后，有些组织选择采用多份产品待办列表，而另一些组织则选择保留一份产品待办列表。当采用多份产品待办列表时，通常会由不同的PO对每份待办列表负责。以下CLD（Causal-Loop Diagram：因果回路图）显示了这个话题背后的系统动态。一份产品待办列表的驱动力因为只有一个产品，所以很自然会想采用一份产品待办列表。R1回路可以这样读：采用越少份产品待办列表透明性越好产品整体性越好采用越少份产品待办列表这是个潜在的良性循环，最终导致采用一份产品待办列表。为什么采用多份产品待办列表？那么，为什么还有组织选择采用多份产品待办列表呢？有三个主要的平衡回路在起作用，分别是B1回路、B3回路和B5回路。与R1回路一起，它们构成了“成长上限”的系统基模。 B1回路可以这样读：采用越少份产品待办列表技能差距越大开发效率越低团队越焦虑采用越多份产品待办列表 B1回路显示了来自于团队专业化的限制。为了充分利用团队的专业化以获得效率，产品待办列表本质上变成了团队待办列表以匹配他们的技能。这个动态与采用通用团队还是专业团队背后的动态是类似的。其实另有根本解决方案，我们会随后展开。 B3回路可以这样读：采用越少份产品待办列表每份待办列表中的故事越多 PO澄清需求的工作量越大（假设PO来澄清需求） PO越焦虑采用越多份产品待办列表 B3回路显示了来自于需求澄清的限制。一个常见的误解是PO要为团队澄清好需求。如果需求澄清都由PO来做，这就成了采用一份产品待办列表的限制因素。其实也另有根本解决方案，我们会随后展开。 B5回路可以这样读：采用越少份产品待办列表团队间耦合度越高产品探索和决策的效率越低 PO越焦虑采用越多份产品待办列表 B5回路显示了来自于探索和决策的限制。这里的假设是每个团队有自己的PO，所以当每个PO可以独立决策时效率就更高。其实也另有根本解决方案，我们会随后展开。这些是限制我们采用一份产品待办列表的主要力量。它们限制了R1回路从而伤害到产品整体性。其杠杆点在于找到根本解决方案以弱化这些限制力。寻找根本解决方案针对B1回路、B3回路和B5回路，B2回路、B4回路和B6回路分别提供了相应的根本解决方案。然而这些方案因为有延迟所以是长期的。短期解决方案（也就是采用多份产品待办列表）转移了我们对长期解决方案的焦点。这本质上就是“舍本逐末”系统基模所描述的现象。 1. 团队专业化 B2回路显示了围绕团队专业化问题的根本解决方案，可以这样读：开发效率越低团队越焦虑学习越多团队技能越广（一段时间后）技能差距越小开发效率越高我们可以不通过采用多份产品待办列表来减少技能差距以获得开发效率，而是聚焦于学习和扩展团队技能广度，最终获得更高的开发效率。 R2回路是“舍本逐末”中的上瘾回路，可以这样读：采用越多份产品待办列表团队感知到越少学习的需要学习越少团队技能越窄（一段时间后）技能差距越大开发效率越低团队越焦虑采用越多份产品待办列表当采用多份产品待办列表多少解决了开发效率问题时，我们会倾向于更少关注学习和扩展团队技能广度，从而变得更依赖于多份产品待办列表。 2. 需求澄清 B4回路显示了围绕需求澄清问题的根本解决方案，可以这样读： PO澄清需求的工作量越大 PO越焦虑团队参与需求澄清越多 PO澄清需求的工作量越少（一段时间后）我们可以不通过采用多份产品待办列表来减少PO工作量，而是聚焦于让团队参与到需求澄清，最终带来PO工作量的减少。延迟是因为团队需要学习如何与用户有效交互以及相关领域才能把需求澄清工作做好，这需要时间。 R3回路是“舍本逐末”中的上瘾回路，可以这样读：采用越多份产品待办列表每份待办列表中的故事越少 PO感知到越少需要帮助团队参与需求澄清越少 PO澄清需求的工作量越多（一段时间后） PO越焦虑采用越多份产品待办列表当采用多份产品待办列表多少解决了PO工作量问题时，我们会倾向于更少关注如何让团队参与需求澄清，从而变得更依赖于多份产品待办列表。 3. 探索和决策 B6回路显示了围绕探索和决策问题的根本解决方案，可以这样读：产品探索和决策效率越低 PO越焦虑团队间对齐越多产品探索和决策效率越高（一段时间后）我们可以不通过采用多份产品待办列表来减少团队耦合以获得探索效率，而是聚焦于让团队间对齐并增加共同决策的能力，最终获得由一组团队和PO共同协作产生的更高探索效率。延迟是因为创建团队间对齐和形成共同协作能力需要时间。 R4回路是“舍本逐末”中的上瘾回路，可以这样读：采用越多份产品待办列表团队间耦合度越低感知到越少需要跨团队对齐团队间对齐越少产品探索和决策效率越低（一段时间后） PO越焦虑采用越多份产品待办列表当采用多份产品待办列表多少解决了探索效率问题时，我们会倾向于更少关注创建对齐和形成共同协作能力，从而变得更依赖于多份产品待办列表。总结当我们做一个产品时，最好的情况应该是采用一份产品待办列表。我们分析了是什么阻碍我们这样做，那些因素是我们需要去移除的。常见的有三个方面的原因让我们选择采用多份产品待办列表：团队专业化、需求澄清、产品探索和决策。我们寻找了对应的根本解决方案，并看到采用多份产品待办列表可能产生的“舍本逐末”陷阱。...

认识组织选项背后的系统动态：一个还是多个产品负责人

2018-04-212018-04-21 由吕毅没有评论

我原先以为这个选择本质上和一份还是多份产品待办列表是相同的。当我细想后，发现还是值得把它写成单独的话题。作为两个最流行的大规模敏捷框架 - SAFe和LeSS - 在这上面就做了不同的选择。SAFe中的ART（敏捷发布火车）和LeSS中的LeSS（到8个团队）规模上是近似的。在ART中，定义了产品经理和若干团队PO（产品负责人）；而在LeSS中，却只定义了一个PO跟所有团队工作。在本文中，我们会探索围绕一个还是多个PO这个选择的系统动态。在SAFe里对ART的描述中，它提到了定义团队PO的原因。 “规模大了，一个人就没法既处理产品和市场策略又专注于敏捷团队。因此，产品经理和团队PO们会一起驾驶火车。” 让我们来探索为什么这么选择以及它产生的后果。优先级排序胜于需求澄清以下因果回路图呈现了引入多个PO来分担需求澄清工作量所产生的相关动态。引入多个PO作为减轻一个PO所需承担需求澄清工作量的解决方案反映为B1回路，它可以这样读：一个PO澄清需求的工作量变高引入更多PO 一个PO澄清需求的工作量变低在这个解决方案背后有一个常见的误解，以为PO唯一负责澄清需求。在单团队Scrum里，这更像是一种选择，Scrum指南里这样描述： “PO可以做以上工作，也可以让开发团队做。” 以上工作包括需求澄清。而在多团队Scrum里，如果我们希望让一个PO能够和多个团队工作，团队分担需求澄清工作就变得很必要了。LeSS里这样阐述： “一个LeSS里的PO专注于努力思考优先级，但和团队协作澄清需求。并且他会鼓励和帮助团队直接和真正的用户／客户对话。他作为一个连接者，而非中间人。” 这个替代的解决方案反映为B2回路，它可以这样读：一个PO澄清需求的工作量变高团队参与需求澄清越多团队和客户工作的能力越强／团队具有更丰富的业务领域知识一个PO澄清需求的工作量变低 R回路解释了为什么多个PO的做法如此常见，它可以这样读：一个PO澄清需求的工作量变高引入更多PO 对PO澄清需求的依赖越大团队参与需求澄清越少团队和客户工作的能力越弱／团队具有更贫乏的业务领域知识一个PO澄清需求的工作量变高引入更多PO 如果读了这个系列之前的文章，你一定已经认出了这里的“舍本逐末”系统基模。合同游戏的现状以下因果回路图呈现了从研发引入多个PO来应对业务方的改变阻力所产生的相关动态。业务和研发之间传统的工作方式是基于合同游戏的。业务和研发协商一个发布的合同，然后业务就交由研发交付合同。在导入敏捷之前双方是没有基于迭代的协作的。当你想有更多PO时，对业务方就意味着更多的改变。阻力应运而生，最终导致在研发这边创建了更多PO。这样做消除了阻力同时又满足了对PO角色的需要。现状得以保留。 B1回路是个速效方案，它可以这样读：业务方需要的改变越大（需要更多PO）产生的改变阻力越大在研发这边引入更多PO 业务方需要的改变越小 B2回路是个根本方案，它可以这样读：业务方需要的改变越大（需要更多PO）产生的改变阻力越大对业务方的辅导越多团队和业务之间的协作越多（或者作为PO，或者作为干系人，关键是基于迭代来协作）带来越多价值和越大灵活性业务方需要的改变越小 R回路解释了为什么这么容易就回复到现状，它可以这样读：业务方需要的改变越大（需要更多PO）产生的改变阻力越大在研发这边引入更多PO 团队和业务之间的协作越少（因为团队和PO之间的协作变成了研发内部的协作）带来越少价值和越小灵活性业务方需要的改变越大是的，你又一次看到了“舍本逐末”系统基模。结论我看到过两种常见的一个产品多个PO的情况。在许多互联网公司，这些团队PO就是低级别的产品经理。他们更多工作在战术层面，而非战略层面。当他们喂给团队详细的规范和用户界面草图时，团队在产品探索上的参与度就会很低。这不仅丧失了让团队贡献于产品探索的机会，也为达成产品交付所需的共同理解制造了障碍。在更传统的行业，从研发这边引入团队PO的做法很常见。当他们关注于需求澄清时，他们本质上退化为传统的业务分析师。有很多理由反对业务分析师的角色，我最喜欢的是Martin Fowler和Dan North在2007伦敦QCon上做的主题演讲中阐述的，简而言之就是，“桥比渡轮更好”。当你选择有多个PO时注意后果！英文版：https://blog.odd-e.com/yilv/2017/03/seeing-the-system-dynamic-1-vs-n-product-owners.html...

认识组织选项背后的系统动态：狭窄还是宽泛的产品定义，第二部分

2018-04-032018-04-03 由吕毅没有评论

在第一部分，我们分析了把平台定义为产品的情况。现在，我们来分析把产品领域定义为产品的情况。那些产品确实都有客户视角，但是我们有可能定义一个更宽泛的产品，然后那些产品就变成了宽泛产品定义下的产品领域。让我们进一步分成两种情况，一种是把解决方案定义为产品；另一种是把产品系列定义为产品。把解决方案定义为产品解决方案包括若干产品，它们之间交互产生客户价值。让我们来看两个例子。在电信网络中，无线接入网是一个解决方案，而基站和基站控制器是其中独立的产品，也就是网络解决方案中的网元。在电子商务中，电子商务平台给客户提供了端到端的解决方案，而购物、支付、物流是其中独立的产品，也就是整体解决方案中的元素。解决方案往往会演进成一个开发的生态系统。我们可以把解决方案重新定义为产品，那样在同一解决方案中的产品就变成了产品领域。 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...

认识组织选项背后的系统动态：狭窄还是宽泛的产品定义，第一部分

2018-04-032018-04-03 由吕毅没有评论

什么是产品？这是一个组织设计中的关键问题。你可以狭窄或者宽泛地定义产品，由此定义产品的范围是一个连续体。我们将分两部分来认识不同选择背后的因素和动态。在第一部分，我们会分析将平台定义为产品的情况；在第二部分，我们会分析将产品领域定义为产品的情况。平台是个在很多产品组织里都很流行的概念。平台经常被当作产品来对待，对应到组织，围绕它有相应的产品待办列表和团队。在多数情况下，平台不面对外部客户，因此本质上还是组件。平台和应用一起形成一个产品，这种情况呈现在上图的左半部分。在有些情况下，平台有独立于应用的外部客户，因此确实是产品。平台和应用就是两个面向不同客户的产品，这种情况呈现在上图的右半部分。让我们分别来展开。平台是一个组件为什么组织选择把平台定义为产品，即使它本质上只是一个组件？为了重用 - 多个应用可以重用同一个平台，从而节省开发成本。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...