这就是为什么你的公司没有取得真正的进步，尽管每个人都很努力工作。
不管你多么勤奋，危险的瓶颈会使你所有的努力付诸东流。
那么，你有没有想过“瓶颈”这个词是从哪里来的?让我们试着更好地理解它。
想象一下，你有一瓶水，你的目标是尽快把它喝完。
场景1:你把它翻过来，水就自己流出来了，就完成了。
然而，你意识到瓶颈(字面上是瓶子较窄的部分)限制了水的流动速度。
这让你怀疑……
场景2:所以你决定再买一瓶水。相同的。你把它翻转过来，但这次你让瓶子转了几圈，产生了一个漩涡。水流出的速度几乎是上一瓶的两倍。
为什么?因为，在第二种情况下，你制造了一个漩涡，允许空气进入，这样水就可以通过盘旋运动流出来。你让水和空气有各自的路径，以实现不间断和连续的流动。更好的流动。
这是怎么回事?你基本上改进约束(瓶颈)的流程。通过优化整体，你可以用更好的准备时间来清空瓶子。
导读:如果你想要改善整个系统，首先，你需要找出并改善阻碍你实现目标的系统约束(任何限制因素)。否则，任何改进举措都将导致局部优化，而不能提供显著的好处。
在软件开发上下文中，它没有不同的工作方式。
尽管可以认为找出系统约束并不是那么简单，但在软件开发环境中，它实际上以类似的方式工作。
假设你有一个团队在开发一个特定的功能。他们的技术是一流的，他们使用最先进的工具，他们有一个伟大的团队。他们能够在短周期内构建DONE增量。然而，组织有一个政策，允许团队在经过一个痛苦的过程(由外部审批者管理)之后，在特定的日期发布他们的增量，并且只能作为与其他团队同步的整体代码库的一部分。
他们能从一个高绩效的团队中得到什么好处吗?只要在这个过程中有一个限制，阻止他们从用户/利益相关者那里得到早期的反馈?
组织是否利用了这个团队的潜力?
延迟发布对团队士气有什么影响?
这个过程对任何人都有帮助吗，还是只是对整体进行了次优化?
让我们明确一点，这并不一定意味着团队在将代码部署到目标环境时不会咨询团队之外的任何人。可能会有故意的“组织惯例”来遵守一些法律要求，或者由于业务的性质。
基本上，这种情况背后可能有一个背景。这更多的是关于能够问:“这个过程会导致系统性约束吗?”我们能改进它吗?”
有两个维度。
- 你认为这家公司的文化允许人们问这些问题而不会感到不舒服吗?
- 员工是否有足够的专业和勇气向当权者讲真话?
我的观点，从来不是其中之一，两者都很重要。自上而下和自下而上。
5 .经常遇到系统性约束。
在过去的10年里，我在不同的行业工作过，包括电子商务、金融科技、广告和房地产。无论在哪个领域，我都观察到了经常遇到的系统约束的模式。
尽管这些限制大多是流动的和相互关联的，但我可以提到5类每个问题下面都有一些有力的问题，可以发起有用的对话。
约束1:英雄式管理和领导方法
- 那些有政治影响力的人(领导者、经理，或者随便你怎么称呼他们)是公认的英雄专家，还是鼓励生存实验的仆人式领导者?
- 经理的角色是由向他们汇报的人数来定义的，还是由他们为员工和团队的成长创造空间的能力来定义的?
- 什么样的政策可以激励仆人式领导?
- 经理们做什么玄叶光一郎走？或者他们是在大气层外工作的宇航员经理，不能看到地面上真正发生的事情?
关于玄巴步:
“不要用眼睛看，用脚看……只看数字的人是最糟糕的。”
大野太一——丰田生产系统之父
约束2:算命驱动的开发和预算
- 人们知道这两者的区别吗“预测”和“承诺”？
- 谁来决定在特定的时间内“能做多少”?是做这项工作的人还是其他人?
- 你是否与长期的预算？它是否会在人才质量和招聘速度之间做出权衡，以使公司看起来规模迅速?
- 你的产品负责人/经理知道发布的成本是多少吗?
约束3:模糊的产品定义和衡量无关紧要的东西
- 你是项目公司还是产品公司?你对成功的定义是由内而外还是由外而内?
专业的产品负责人唐·麦克格雷尔、拉尔夫·约查姆著
即使你是一家B2B公司，按时间、预算、范围交付并不一定意味着你交付的东西会让你的客户满意。这些都是间接指标，你会发现更有价值的是确定更好的指标，解决结果而不是产出。
- 你在你的语境中定义过“价值意味着什么”吗?你已经确定了你的领先指标和落后指标是什么，与设定方向的人和交付价值的人一起吗?
我发现了一些对不同层次和需求的观点有帮助的资源: 2019年DevOps的加速状态，循证管理，可预测的可操作敏捷度量
- 如果你随机给公司里的人发一张纸和一支笔，他们能写出你的产品(或服务)是什么，以及你的客户为什么使用它吗?不仅仅是商界人士。每一个人。
- 你对自己产品的定义有多宽泛?你如何在认知能力过载和更广泛的学习机会之间建立正确的平衡?
- 你是否有专人负责将产品价值最大化?如果多个团队在开发一个产品，您是否有这个人订购的产品待办事项列表?
约束4:国防部缺乏共同的理解
- 当你把某件事标记为“完成”时，你能立即释放它吗?
https://less.works/less/framework/definition-of-done.html#UndoneWork-RiskandDelay
- 在计划能力和上下文切换方面，未完成的工作如何影响团队?他们是否经常抱怨为超出他们“完成”定义的环境中的bug分配容量?
- 你会做些什么来左移并缩小这个差距吗?
约束5:团队结构(管理依赖关系胜过消除依赖关系)
- 当前的结构是否允许团队拥有他们所负责的功能/服务/流的端到端流程?
- 团队是否抱怨花了太多时间来管理他们与其他团队的依赖关系?
- 团队是否有足够的空间更多地关注质量、创新和提高技术卓越性?
团队拓扑引入“使能团队”的概念，以缩小上述差距，并透过技术谘询支援以流程为导向的团队。
这些“使能团队”积极地避免成为知识的“象牙塔”，这些知识规定了其他团队要遵循的技术选择。他们以仆人式领导的方式运作。
结论
总而言之，在瓶颈之外的任何进展都是一种幻想。发现并意识到阻碍流动的系统约束是至关重要的。
没有灵丹妙药。没有万能的方法。尽管如此，根据我的经验，如果你能实现以下组织思维转变，你将改善上述5个约束条件。
- 仆人式领导胜过英雄式领导
- 比大预算更有适应性的计划
- 产品思维高于项目思维(结果高于产出)
- 早一点交付小的DONE增量，而不是晚一点交付所有东西
- 消除团队依赖关系，而不是团队管理依赖关系
最后一点，我们不应忘记组织结构也会对公司文化和软件设计产生影响(揭秘康威定律）.
感谢阅读。如果你想分享你自己的观点和经验，请不要犹豫，留下评论。你也可以通过sahin@vaxmo.co.uk．我总是喜欢在虚拟咖啡里聊天!
特别感谢Maarten Dalmijn＆大卫·佩雷拉感谢他们对本文的贡献。