ADD / XOR / ROL

一个关于逆向工程、数学、政治、经济等内容的博客…

2016年9月3日，星期六

关于大型组织管理的随笔（一）：流程与灵活性

尽管我常声称自己的主要兴趣在技术领域，但至今我已接触过多种不同的组织和管理风格：从1996-2002年破解/黑客团体的自组织混沌，到以工程为中心的小型初创公司zynamics，再到我曾咨询过的各种政府及行业组织，直至谷歌庞大（但仍以工程为中心）的文化。

我喜欢思考组织——它们的结构、信息流动方式、优势及功能障碍。部分原因可能受我父亲的影响（他广泛著述于矩阵组织，也包括失败的组织）；另一部分则是认识到公司文化和组织文化都至关重要。在任何组织中，设定文化组织结构并保持其健康是至关重要的，可能是长期成功的关键要素。忽视文化和组织结构（无论是显性还是隐性）都将自食恶果。

过去一年我有大量时间思考，因此在未来几个月我将写几篇关于公司文化和管理文章。

第一篇文章关于组织流程——它们为何重要，但也如何自成一体并扼杀灵活性。

从一个技术轶事开始

2004年初，BinDiff的第一个原型开始正常工作——恰逢微软发布MS04-001：微软ISA服务器（一款现已停产的防火墙产品）H.323解析组件中存在一系列有趣的小内存损坏问题。对补丁使用BinDiff后，明显问题出在中央库的ASN.1 PER解析例程中——但补丁并未修复该库，而是在ISA服务器内部修复了问题。

该补丁仅修复了一个利用路径，但实际漏洞仍然存在。这意味着任何使用同一库的其他程序仍然易受攻击，而补丁现在有效地披露了安全问题。我开始搜索使用该库的其他应用程序。我发现的第一个受此漏洞影响的程序是Netmeeting——微软无意中向所有人提供了Netmeeting中的远程代码执行漏洞。直到4月份的MS04-011，该漏洞才在正确的位置——库中得到修复。

该漏洞的技术细节并不特别有趣——有趣的是错误揭示了微软组织结构中的缺陷，以及他们如何应对漏洞报告。

我们能从这一事件中推断/学习/推断出什么？

漏洞报告可能被路由到产品团队——例如，如果在你的产品中报告了一个漏洞，漏洞报告会路由给你。

修复漏洞的责任似乎在于产品团队（见上文），并且团队有动力（直接或通过功能截止日期等间接方式）快速将漏洞报告“从桌上清除”。

修补共享的中央代码比修补你拥有的代码更困难（原因多种多样——可能是兼容性问题、其他团队的其他优先级，甚至可能是请求更改关键代码的繁重流程）。

可能发生的情况是，ISA团队认为处理他们这边的问题就足够了——要么因为他们没有意识到同一问题会影响其他人，要么因为与其他团队/库打交道很痛苦，或者出于其他未知原因。微软的漏洞修复流程激励了“浅层”修复，因此对于攻击者来说，找到漏洞的根本原因可能会暴露其他易受攻击的程序。

这是一个典型的做出局部便利决策却对更大组织产生不利影响的例子。

据我所闻，微软从这一事件中吸取教训，并进行了组织变更以防止未来类似错误。他们引入了一个流程，所有补丁在发布前都经过中央审查，以确保不会无意中在错误位置修复错误，或披露其他地方的漏洞。

流程作为组织学习

在MBA所谓的“组织学习”中，流程是从先前失败的经验中创建的，以防止错误再次发生。流程有点类似于组织疤痕组织——组织伤害了自己，为防止未来此类伤害，建立了流程。

令人惊讶的是，大多数组织建立流程时没有明确记录导致流程建立的失败和事件类型。这种知识通常只存在于当时在场的个人头脑中，或存在于与那些在场者交谈者的民间传说中。大约五年后，没有人记得原始事件——尽管流程将生机勃勃。

流程可以防止组织重复做愚蠢的事情——但太常见的是，流程自成一体：人们开始盲目应用流程，在过于字面思维的人手中，流程成为生产力或效率的障碍。负责应用和执行流程的人自己可能不知道它为什么存在——只知道它是“流程”，并且不遵循它可能会发生坏事。

我祖父曾说过（我将转述）：“有责任的工作不是简单应用规则，而是需要判断如何以及在何处做出例外”。这句话包含一个重要真理：

组织中所有地方的人都需要……

被授权做出例外：在展示出合理判断后，人们需要感到被授权在流程字面意义阻碍更大利益且更改流程会过度时（例如，在一次性情况下）做出例外。

被授权挑战流程：流程背后的推理必须对组织成员可访问，并且需要有一种（相对无痛）的方法来提议更改流程。由于无力感是职业倦怠的主要驱动因素之一，这将有助于保持个人和组织结构的健康。

一些组织在“例外”部分做得好——大多数大型组织仅因为人们经常愿意弯曲/扭曲/忽略流程而运作。非常非常少的组织在“挑战”部分做得好——确保每位员工知道并理解流程是为公司服务的，并且欢迎对流程的改进。

我认为未能实现挑战流程通常是由于“缺乏机构记忆”。当组织未能跟踪流程创建的原因时，会产生各种有害副作用：

• 没有人能有意义地判断流程的精神——它旨在防止什么？
• 对流程做出例外风险更大——如果你不知道它旨在防止什么，你怎么知道在这种特定情况下该风险不适用？
• 修改流程风险更大。（同上原因。）
• 挑战流程无法以分散/自下而上的方式发生：通常是最初级的员工可能对 obstructive 流程有最新鲜的眼光——但由于他们不知道流程存在的历史，他们通常无法有效提议更改，因为他们对组织不够了解以排除不必要的副作用。这直接破坏了工作流程的分散、自下而上的改进。

处理流程的健康方式是什么？

认识到它们是“组织记忆”的一种形式：它们通常是作为对某些不愉快事件的反应而形成的——旨在防止该事件重复发生。同样重要的是要认识到，未经检查和挑战的流程可能成为组织“疤痕组织”——阻碍大于帮助。

跟踪创建每个流程的确切动机——“为什么”。这将涉及写半页或更多，并与参与流程创建的其他人核对描述是否准确和可理解。

流程背后的动机应对受其影响的每个人可访问。

每个人都应该知道公司流程应该支持而不是阻碍完成工作。每个人都应该感到有权提议更改流程——理想情况下同时说明这些更改不会导致流程旨在防止的问题重复发生。

人们应该被授权偏离流程或忽略它——但频繁或甚至不频繁但重复的例外是流程需要改进的危险信号。不要通过授予例外的机制积累“遗留流程”和“组织债务”。

每个人都应该意识到保持流程功能性和精简对保持组织健康至关重要。即使流程不合理且 obstructive，大多数人本能地尝试接受它——但第一本能理想情况下应该是为了更好而改变它。建设性地挑战 broken 流程是对组织的服务，而不是攻击。

将流程视为代码可能明智——包括相关流程的所有权、版本控制，以及人员换工作时流程所有权的移交。然后可以对流程的修正作为文本提交，由流程所有者审查、讨论并最终批准——很像补丁或删除死代码。

保持组织健康是困难的。然而，保持其健康的最关键因素是组织成员关心保持其健康。因此，鼓励在出现问题时修复组织至关重要——并且不鼓励人们“盲目遵循流程”。