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

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

在多团队的产品组织中,存在一个选择:采用一份还是多份产品待办列表。因为试点起始于一个团队或者产品本身起始于一个团队,通常会从一份产品待办列表出发。引入多个团队后,有些组织选择采用多份产品待办列表,而另一些组织则选择保留一份产品待办列表。当采用多份产品待办列表时,通常会由不同的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越焦虑 采用越多份产品待办列表 当采用多份产品待办列表多少解决了探索效率问题时,我们会倾向于更少关注创建对齐和形成共同协作能力,从而变得更依赖于多份产品待办列表。 总结 当我们做一个产品时,最好的情况应该是采用一份产品待办列表。我们分析了是什么阻碍我们这样做,那些因素是我们需要去移除的。常见的有三个方面的原因让我们选择采用多份产品待办列表:团队专业化、需求澄清、产品探索和决策。我们寻找了对应的根本解决方案,并看到采用多份产品待办列表可能产生的“舍本逐末”陷阱。...
阅读更多
认识组织选项背后的系统动态:一个还是多个产品负责人

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

我原先以为这个选择本质上和一份还是多份产品待办列表是相同的。当我细想后,发现还是值得把它写成单独的话题。作为两个最流行的大规模敏捷框架 - 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...
阅读更多
认识组织选项背后的系统动态:狭窄还是宽泛的产品定义,第二部分

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

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

把系统思考带给更多人-2018年3月杭州聚会

历史 差不多在一年前有了“把系统思考带给更多人”的想法,到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...
阅读更多
认识组织选项背后的系统动态:需求还是任务

认识组织选项背后的系统动态:需求还是任务

  在辅导敏捷团队时一个重要的杠杆是增加对需求而非任务的聚焦。这篇文章描述其背后的动态。 传统的项目在两个层次跟踪进度。一个是里程碑,经常跟诸如需求分析完、集成准备就绪、测试完成这样的阶段相关联。另一个是任务状态,经常通过每周汇报会议来跟踪。相比之下,敏捷开发却跟踪需求的进度(注:更好的是跟踪那些需求的价值,但这不在本文范围内讨论)。我们将看到不同选择背后的动态,希望由此带来的理解能对成功的改变有所帮助。 为什么聚焦任务?  聚焦任务有它的原因。   任务焦点本质上代表了资源焦点。当面临成本压力时,我们尝试增加资源焦点,以提高资源效率,从而减轻成本压力。 我们如何增加资源焦点呢?一种方式是通过任务。事实上当跟踪任务时,次序经常是按人,问每个人在做什么任务。这样就能确保每个人都忙着。如果没有匹配他们技能的任务呢?我们创造任务来适应他们的技能。我们会在后面看到这将带来有趣的影响。 为什么聚焦需求? 聚焦需求也有它的原因。 需求焦点代表了客户焦点。当面临市场压力时,我们尝试增加客户焦点,以提高流动效率,从而减轻市场压力。 我们如何增加流动效率呢?一种方式是通过需求。我们不是跟踪任务和人,而是跟踪需求确保它们流动。我们较少关注谁闲着,更多关注如何让需求流动得顺畅。 两者之间的矛盾 如果两个平衡回路相互独立,成本和市场的目标能同时得到满足。然而,在资源效率和流动效率之间存在矛盾。 我们讨论资源效率时曾经提及,当一个需求对某些人来说没有他合适的任务时,我们就开启另一个需求以使他有合适的任务做,从而提高了资源效率。注意如果需要学习,他就不是资源有效的。并行需求的增多意味着客户焦点的降低。因此,资源焦点对客户焦点有负面的影响。 反过来也是一样。当我们聚焦客户,通过限制并行工作的需求个数以追求流动效率时,它不可避免会产生某些人没有合适的任务做的情况,这就不是资源有效的。因此,客户焦点对资源焦点也有负面的影响。 现在两个平衡回路就相互作用了。当市场压力变大时,加强客户焦点以提高流动效率。同时,这减弱了资源焦点,降低了资源效率。这时候是B2回路主导。当成本压力变大时,加强资源焦点以提高资源效率。同时,这减弱了客户焦点,降低了流动效率。这时候是B1回路主导。 理解这个矛盾帮助我们以不同的方式看待变革中的抵制力。虽然聚焦客户令人难以反驳,根本性的系统结构却产生反向的力量。 这个矛盾也提出了关于系统目标的重要问题。对特定的组织来说,你更想优化哪个目标 - 资源效率还是流动效率? 产生影响的杠杆 有可能两者兼得吗?或者至少在以某一项为主的同时能兼顾另一项? 来看一下我们是如何实现资源效率的。我们开始更多并行的工作以适应技能,但牺牲了客户焦点。我们可以让B3回路而非B1回路工作,也就是通过学习扩展技能,最终提高资源效率。B3回路对客户焦点并没有负面的影响,但学习也需要更长时间才见效。不令人意外的是,真正的杠杆在于我们如何能有效地学习和扩展技能。 上图是来自于《This is Lean》书中的效率矩阵。图中的蓝线表示通往“完美状态”的演进路径,首先实现B1回路(提高流动效率),然后再是B3回路(提高资源效率)。然而很多组织自认为它们的现状是“高效岛屿”,也就是B2回路主导,这样一来演进路径变成了图中的红线。从变革管理的角度来看,沿红线演进是困难的,因为它意味着资源效率会先降低。你可以改变认知以从更为真实的“浪费之地”出发,或者确保资源效率的降低是可以掌控的。 聚焦于需求还是任务本质上是在客户焦点和资源焦点之间的选择。 英文版:https://blog.odd-e.com/yilv/2018/02/seeing-the-system-dynamic-requirement-vs-task.html...
阅读更多