你的组织有这些障碍吗?
发布于 2021-09-22 09:13
很少有大公司的寿命能超过人均寿命的一半。根据荷兰皇家壳牌公司的一项统计发现，大型工业企业的平均寿命通常会小于40年，大概只有现在我们人平均寿命的一半。这项研究后来被美国EDS等其他几家公司复制，并成为Jim Collins 2001年出版的《Good to Great》一书的参照点。此书的读者将有50%的机会，能够在自己的职业生涯过程中看到自己现在公司的消亡。
以“适者生存”的法则看来，企业的不断消亡很正常，这只是经济更新，生产力资源重新分配给新公司而已。但是，这种公司高死亡率如果只是一些深层问题的表面症状呢？被这种深层问题折磨的如果不单是死亡的公司，而是所有公司呢？进而，有没有可能连看起来比较“成功”的公司也是很差的学习实践者---他们虽然存活了下来，但从未发挥应有的潜力？有没有可能，与组织将来做到的事情相比，现在所谓的“杰出”实际上只是“平庸”而已？
大多数组织的学习实践很糟糕，这不是偶然的。组织的设计和管理模式、人们对工作的定义，还有我们在组织和日常生活中所接受的教育，造成了根本的学习障碍。即使有聪明肯干的人做出很大的努力，这些障碍还是挥之不去。他们往往尽力解决问题，结果反而可能越来越糟。所有的组织都在某种程度上遭遇这种障碍，而学习实践的发展也都是在这种背景之下。
对于组织而言，学习障碍是悲剧，而且常常被忽视。我们来看看组织都有哪些障碍：
受传统文化影响，我们接受的教育往往强调忠于职守这一概念，以至于我们会把自己的工作混同与自己的身份。几年前我被挖到一家传统企业做产品，入职例行私下为团队做一些基础培训，其中会涉及到为开发讲一些产品和需求分析方法，同时为产品讲一些编码常识，以帮助他们可以更好的工作。然而，培训并不管用，结果发现，同事们遭受了严重的身份认同危机，“我怎么能做这些工作，学这些有什么用？我的职位是xxx啊~”
有的时候和同事聊天，当问到靠什么生活时，大多数人只描述每天做的工作，却没有谈到他们曾身处这家企业的目的。他们大多觉得，自己对身处其中的系统并没有什么影响力。他们干自己的工作，花时间做自己分内的事，最后，他们总是把自己的责任限定在自己的职责范围之内。
最近经常听到的一个话题就是，一个软件团队中产品、研发以及测试的矛盾。Development Team中的产品、研发以及测试的人只对“他们自己的”工作负责，不同的工作职责有不同的目标和产出，从单一视角来看，每一个人都认为自己的工作没有什么问题，每个人都很专注的干自己职责范围内的工作，但讽刺的是，随着项目逐步迭代扩展，开发速度会越来越慢，成本越来越高。
前几天和朋友去大学打篮球，有一个大三的学生在三分线外投了很多篮都没进，于是他开始抱怨道：“这个球场的篮筐不好，很不适合投三分。”当问题发生时，我们很多时候都会有这种倾向：去责怪我们身外的人或事。
有些组织也会把这种倾向提升为命令，比如说：“你们必须找到问题的外部责任方。”所以，产生了如下对话：
业务部门：我们不能完成指标的原因是研发的质量不行，没有竞争力。研发部门：这是因为产品的需求设计没做清楚，影响了我们的研发质量。产品部门：如果业务想清楚市场定位以及需要向用户提供什么服务，别再提一句话需求，研发能少写点bug，可能也不至于这样。
“敌人在外部”其实从来不是我们问题的全部，“内部”和“外部”通常都是在一个系统里。正是因为组织的学习障碍，我们几乎无法从“内部”找到关键的作用点，来有效解决横跨“内部”和“外部”界限的系统性问题。
Proactive最近成为了一种时尚，一个组织的管理常常要表达我们应当遇到困难迎难而上，并且要在问题演变成危机之前把它解决掉。这种在问题发生之前解决问题的思路必然会带来一种工作模式---预先设计，预先设计被当做“被动反应”的对症药，他常常会给人带来一种预先主动掌握一切的幻觉。
这种主动积极带来的预先设计有时候会让组织的执行陷入一个死胡同。近些年随着“中台”、“微服务”、“领域驱动设计”等概念的风行，越来越多的组织面对着日渐式微的业务，开始建设自己的中台，想把原来的单体系统拆成一个个的“微服务”。公司假设用户会像传说中某个互联网企业一样，用户以几何倍的速度增长，所以他不断扩大自己的团队，搭建了一个个各种命名为“某某中台”的系统，以满足构想中用户和业务的需求。
这时，我们看一看这种行为带来的产物，有希望获得用户的比例，系统承受最大负载的范围，预先解决市场危机产生的隐患带来的价值，以及无论系统建设是否成功都会产生的固定费用等等。很遗憾，看到最后会发现，这种主动的积极，往往只是被动反应的一种伪装掩饰，它是组织内某些人对主动掌控风险产生的幻觉。
你们有限的用户和并发使用“微服务”这种实践会有大炮打蚊子的感觉么？你们想了半天就只有一两个领域的业务，能建出一个怎样的“中台”系统？你们面向对象都用不利索，所有的服务全都耦合在了一起，能指望DDD设计出来什么呢？是觉得这些实践衍生的工具很新奇么？
如果我们只是对假象的“外部敌人”采取更积极的方式来工作，那我们还是在被动反应---不管怎么称呼它，都是这样。只有当我们意识到，我们是自己组织问题的始作俑者之一，才能够真正的积极主动。这种主动是我们基于组织思考的结果，而不是我们情绪状态的产物。
今天我们的组织和社会所面对的主要生存威胁，可能并不是来自突发事件，而是来自缓慢渐进的过程：军备竞赛、环境恶化、产品设计、交付质量下滑等等。如果大家的思维都被短期事件主导，那一个组织就不可能持续地从事有创造性的工作。
在企业失败案例的研究中，我们不难发现，企业对缓慢积累的生存威胁普遍缺乏应对举措。在软件开发的过程中有一个很典型的温水煮青蛙案例：为了名义上快速面对市场的不确定性，产品降低了需求的质量，用一页纸或者一句话来向研发描述自己的需求，开发降低了编码的标准，放弃了编写单元测试以及对质量的坚持，名义上用最快的速度开发没搞清楚价值的功能，出了问题再去改。在不断的迭代过程中，产品质量就像温水煮青蛙一样不断降低，但是很难察觉，最后发现问题的时候，往往以及为时已晚。
学会缓慢观察、渐进的过程，要求我们去注意那些细微以及戏剧性的变化，当我们在软件开发工作中，为了赶工放弃编写单元测试，放弃遵循固定的质量标准，刚开始可能看不出多少东西，但时间如果足够长，问题突然出现在我们面前时，我们可能会发现无论做什么都已于事无补。
如果不学会放慢脚步，去觉察那些常常是最危险的渐变过程，我们就不能避免温水煮青蛙的命运。
面对组织中至关重要的复杂问题，我们常常想到的就是一群经验丰富、来自不同职能部门的专业“经理”，那么企业团队陷入势力范围之争的时候，他们会怎么做呢？
他们可能常常会简单地回避使个人丢脸的事，假装在集体的策略上形成了统一的思想，以维护表面上的团结。为了保持形象，他们努力消除意见不合，避免公开表露严重分歧，这样集体的决策就退化为了大家都能接受的妥协，或者干脆就是强加在集体名义上的个人观点。如果有分歧，他们通常表现为互相指责和意见主张的两极分化，因而无法揭示深层问题，无法使团队得到根本的提升。
Chris Argyris 在哈佛大学的长期管理团队行为研究报告中写道：“管理团队在日常问题的处理过程中可能运作良好，但是，当他们面对可能使他们陷入窘迫或危险的复杂问题时，管理团队会在压力之下分崩离析。”
可能很多经理人会觉得集体探寻会具有威胁性，所以在组织中的经验是：不能承认我们不知道的答案。很多组织也在强化这种训练：奖励善于推销自己观点的人，却忽视复杂问题的探寻。先别急着否定我，你还记得你们公司上一次对公司现行政策提出难题，而不是解决某个紧急问题的人颁发奖励的人是什么时候吗？
为了保护自己，避免暴露我们无知带来的痛苦，这一过程会阻止新知识的形成。这样做的结果，就是 Chris Argyris 说的“老练的无能”（skilled incompetence）---团队成员可能非常擅长躲避学习。那些问我为什么有些团队口头上想做TDD，但实际上从未开始的人，希望从这里能够找到答案。
也许还有更多问题可以在极限编程合作社共同翻译的《敏捷组织设计》中找到启发吧？:) 敬请期待……
更多敏捷组织设计理论与实践
请期待极限编程合作社共创
《敏捷组织设计》中译本
本文来自网络或网友投稿，如有侵犯您的权益，请发邮件至：aisoutu@outlook.com 我们将第一时间删除。
相关素材