分类： Blog

历史 差不多在一年前有了“把系统思考带给更多人”的想法，到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...

一般软件研发团队组成方式无非几种：按职能划分的职能团队，按系统结构划分的组件团队，以客户为中心的特性团队。这些团队结构各有各的问题和挑战。 职能团队 业务分析团队，设计团队，架构师团队，开发团队，测试团队，按照职能来划分。完成价值交付的过程会出现明显的阶段和交接传递。理想状况是一个需求流畅的从一个团队流畅的流动到下一个团队，直到价值交付到客户手中。 往返传递 现实情况是通常下一个职能团队为上一个团队提供反馈，需求可能会回到上一个职能团队进行调整，需求会在职能团队间来回传递。比如，开发团队完成开发后交给测试团队，测试团队发现bug又交还给开发团队修复，这个过程会反复多次。这样的反复通常无法预期，会经常影响两个团队的原计划，这又加剧了职能团队的下一个问题。 等待队列 工作性质和团队工作能力的不同，导致一些团队会有不能及时处理的任务堆积，形成队列。这些等待中的任务是半成品，不能直接产生价值，是一种浪费，还会使事情变复杂，比如需要有人来维护这个队列。队列会降低工作的流动性，从而降低价值交付的速度。 组件团队 组件团队是按照架构模块或系统组件来划分团队。比如GUI团队，API团队等。 限制设计 按照康威定律，“任何设计系统的组织……都不可避免地产生出与其组织沟通结构一致的系统设计”，团队的组成结构会限制设计。然而大多数情况下，一开始产生的设计都不是最完美的，组织的灵活性对有效的设计有着举足轻重的作用。而组件团队恰恰限制了设计的有效性。 强化瀑布，增加协调复杂度 组件团队还会加强瀑布的开发过程。通常组件团队的存在会导致工作安排按照组件来分配给各个团队，这意味着所有组件团队完成各自的工作后还需要集成并完成最后的测试，反馈被延迟了。当然我们可以用持续集成等方法来加快反馈频率，但这中间的协调工作也确实变多了，你的Team Leader或者Scrum Master是不是经常为这样的事情疲于奔命？想想如果每个团队的工作是完成相对完整的功能，协调工作是不是会减少许多？组件团队有自己的计划安排，但往往需要和其他组件团队协调（比如联调），导致计划总在被打乱？ 系统问题 同时，组件团队和职能团队都会导致：团队往往只关注于完成手头上的工作而非价值；团队与团队间形成职责壁垒，各自只为各自工作负责，也不愿其他人碰自己的工作（典型的如开发人员不愿意其他人碰自己的代码），这也意味着各个团队会更倾向于局部优化，比如在团队工作内容不多的时候，团队会制造些活来干，或者基于专业性来挑选工作而非客户价值。 特性团队 特性团队是由长期合作、跨职能、以学习为导向、多技能的人员组成，能完成端到端客户特性的团队。通常团队的职责包括需求分析、交互设计、计划、设计、编程、测试等，这样团队就能全神贯注地完成端到端的客户特性。 大多数组件团队的缺陷也得以弥补了，比如计划、协调等工作被大大简化了，交接与等待的浪费也减少了，整体的生产周期也被缩短了。同时，团队的技能约束少了，计划和安排工作的灵活性就提升了，可以更多的专注于真正高优先级或更有价值的功能开发上。当然特性团队的好处虽多，但也有不少的挑战和问题： 团队及其成员需要扩展技能和相应的产品知识，以便尽可能的修改系统的任意部分 同时修改同一个代码的机率变高了，冲突的可能性也提高了，这就意味着需要频繁提交代码等一系列持续集成的实践来减小工作批量，缩短集成周期。 各个组件的设计责任被分散到了各个团队，除了持续集成外，还需要其他的实践来保持设计的合理性和持续改善，比如测试驱动开发，重构，演进式设计，组件守护者等。 有些特定的技能比较难以掌握，比如视觉艺术，或者稀有专家掌握的知识和能力（比如图像渲染中的光线追踪算法） 可能需要组织结构的调整，一般组织是以组件或者职能线的汇报关系，最终需要转变成多个团队向共同的上级经理汇报。 如果你正纠结于团队结构或者其它团队在研发过程中碰到的问题，可以考虑参加我的培训： Certified Scrum Developer认证Scrum开发者课程 —— 敏捷团队工程实践 时间：2018年4月8日~10日 地点：上海 ScrumMaster领导力课程 —— ScrumMaster进阶技巧课 时间：2018年4月16日~17日 地点：上海 或者也可以找我聊聊，可以通过zbcjackson@odd-e.com 或者微信 ...