工程师为什么讨厌流程

工程师为什么一听到“流程”就叹气、翻白眼？真正的原因并不是工程师天生排斥流程，而是许多流程只规定了“怎么做”，却没有人能够解释“为什么要这样做”。

要想让工程师在第一时间产生负面反应，只需要说出一个词：

流程。

“各位，为了确保项目能够按时交付，我们制定了一套新的缺陷分类流程。”

话音刚落，你大概就能听见一片叹息，看见有人开始翻白眼。

于是，你很容易得出一个看似合理的结论：

工程师天生讨厌流程。

但这个结论根本站不住脚。

工程师其实非常喜欢结构、秩序和可预测性，而一套健康的研发流程，目的恰恰是建立结构、维持秩序，并提高项目交付的可预测性。

软件工程师的工作是编写代码，而代码本身，就是把一套流程编码成机器可以执行的形式。

既然如此，为什么工程师一听到“流程”就开始叹气？

因为工程师并不憎恨流程。

他们憎恨的是那些无法解释自己为什么存在的流程。

流程管理不能拒绝回答“为什么”

在海外某家科技公司里，有一种工程项目经理的岗位。

他们的重要职责之一，就是确保研发流程得到执行。

他们会参加缺陷评审等会议，推动每个环节按计划完成。

我个人更喜欢把精力放在人和产品上，而不是每天盯着流程，所以我一直很欣赏这类角色的存在。

一位优秀的项目经理，应该运用一切合理手段，确保项目按时完成。

但根据我过去二十多年与项目经理合作的经验，其中相当一部分人虽然能够推动项目按时交付，却不明白自己为什么要采用当前这套做法。

当团队成员要求他们解释流程背后的逻辑时，他们往往会说：

“因为我们一直都是这么做的。”

如果你想迅速激怒我，或者让我大幅降低对你专业能力的评价，这是一种非常有效的方法：

当我提出一个会直接影响自己时间安排的问题时，不要给我答案。

时间是一个人最宝贵的资源。

如果你要求我按照某种方式使用时间，就应该能够解释为什么。

工程师真正厌恶流程的根源，往往就在这里。

流程本来应该是一种帮助人们恢复秩序的工具。

但当它落到不理解流程目的的人手中时，就会变成一件生硬而迟钝的武器，只会制造挫败和愤怒。

健康的研发流程非常有价值

写下这个标题，多少让我有些痛苦。

因为太多人机械地执行流程，已经彻底败坏了流程的名声。

但如果我们回到一套流程诞生的起点，通常可以看见三件重要的事：

• 当时为什么需要这套流程
• 这套流程究竟在保护什么
• 你在维持和改进流程时应该承担什么责任

小团队为什么不需要太多流程

在小团队中，通常不需要太多正式流程。

因为每个人都彼此熟悉，也知道事情的来龙去脉。

你不需要专门写下所有工作如何运转，因为大家本来就知道该怎么做。

即使有人不知道，也清楚应该去问谁。

当团队发现问题时，往往会立刻有人站出来说：

“这里有问题，我们把它修掉。”

之所以能这样，是因为小团队中的每个人，通常都对公司和团队怀有强烈的责任感。

大家都在竭尽全力让事情顺利向前发展。

而在这些日常协作之中，隐藏着公司最重要、却又最不容易被明确看见的东西：

价值观和企业文化。

小团队可能没有正式的使命宣言。

每天都有大量工作需要完成，团队甚至只是为了生存而不断解决问题。

但你们处理这些问题的方式，本身就在体现公司的文化和价值观。

假设你在这家小公司的走廊里随便拦住一个人，问：

“公司的价值观是什么？”

他可能会像看疯子一样看着你，然后说：

“我们一直都是这么做的。”

这听起来，和刚才那位无法解释流程的项目经理似乎没有区别。

但实际上，两者完全不同。

如果你继续追问，他往往能够解释得很清楚。

你问：

“为什么每个重要决定都要经过充分争论？”

他会回答：

“因为我们鼓励公开讨论，希望尽可能作出更明智的决定。”

在小团队里，很多价值观并没有被写下来。

它们存在于人们的行为、习惯和共同记忆中。

团队规模扩大后为什么需要流程

当公司发展到某个规模时，会同时跨过两个彼此相关的临界点。

首先，新员工增加的速度，开始超过老员工通过日常协作自然传递文化和价值观的能力。

其次，随着公司人数不断增加，新员工会逐渐产生一种错觉：

自己的行为已经无法影响公司的文化走向。

于是，公司开始出现两个目标看似相同、体验却完全不同的群体。

第一类：老员工

这些人似乎已经在公司待了很久。

他们了解公司的文化和价值观，因为他们早已深深融入其中。

他们熟悉不同部门如何运转，也知道遇到各种问题应该去找谁。

无论是否愿意，他们实际上都在代表和示范公司的价值观。

第二类：新员工

这些人大多在最近一年内加入。

他们知道公司应该存在某种文化和价值观，却没有人真正坐下来向他们解释。

而最有资格解释的人，通常又忙着推动公司继续向前发展。

因此，新员工经常对很多事情感到困惑。

更麻烦的是，他们不了解公司的内部运作方式，也不知道遇到问题时应该向谁求助。

最初的蜜月期结束后，他们会逐渐感到挫败，因为他们无法理解自己所做工作的意义，也不知道该如何影响现状。

老员工为什么难以传递企业文化

老员工很难想象一个并非人人都了解全部背景的世界。

他们也很难解释那些在自己看来早已显而易见的事情。

渐渐地，老员工开始听到新员工的抱怨。

但他们给出的建议往往是：

“别抱怨了，直接把它解决掉。这也是你的公司。我当年就是这么做的。”

这种听起来充满主人翁精神的建议，实际上几乎没有任何帮助。

新员工本来就非常想解决问题。

他们的问题不是不愿行动，而是不知道该从哪里开始。

老员工那种轻率而自信的态度，只会让他们觉得：

对方似乎在暗示，这明明是一个很简单的问题，只有自己解决不了。

这当然令人恼火。

企业流程是怎样诞生的

最终，团队会召开一次会议。

白板上写满各种意见和建议。

不同公司可能会用不同的名字称呼最终成果，但本质上发生的是同一件事：

有人主动把“我们究竟是怎样完成工作的”记录了下来。

这就是流程的诞生。

当你想到“流程”时，我希望你能想到这个瞬间。

因为它本来可能是一个非常有价值，甚至有些崇高的时刻。

流程最初并不是为了控制人。

它的目的，是记录团队的文化、价值观和已经积累下来的经验。

但我们后来往往只把流程理解为枯燥的“怎么做”。

于是，我们忘记了它更重要的部分：

为什么要这样做。

在研发团队中，也可以借助 PingCode 将需求评审、项目排期、缺陷处理、测试发布等流程固化下来，并通过 Wiki 同时记录流程背景、决策依据和经验教训。工具真正的价值不只是让所有人照着步骤执行，而是让后来加入的人能够理解：这套流程解决过什么问题、保护了哪些原则，以及在什么情况下应该被重新审视。

一个枯燥的内部调动流程

下面来看一套相当枯燥的流程。

这是一套内部岗位调动流程。

当员工想从一个团队转到另一个团队时，管理者可能会提到它。

有些人甚至直到真正需要调动时，才知道公司里原来还有这样一套流程。

规则可能是这样的：

• 员工必须在当前岗位工作满一年，才能申请新的内部职位
• 员工必须达到“良好”或以上的绩效等级，才能申请调动
• 员工可以先与新岗位的招聘经理沟通，再与当前经理正式讨论调动事宜

流程大概就是这样。

谁写下了这些规则？

你可能会想：

“一定是人力资源部门里某个特别喜欢制定规则的人。”

很有可能，这套流程确实是某位人力资源同事在很多年前写下的。

但他们当时的目标，可能真的是帮助员工和公司。

小公司里的内部调动

当公司只有四十多个人时，内部调动可能是这样发生的：

一位工程师想尝试设计工作，于是直接找到设计负责人聊了聊。

设计负责人又和他的现任经理喝了杯咖啡或啤酒。

一周之内，事情就解决了。

这种非正式方式在四十人的公司里非常高效。

但在四百多人的公司里，就会出现问题。

员工可能不知道设计团队是否有空缺，因为他根本不认识设计负责人。

即使他设法发现了一个机会，并和新团队负责人谈过，对方也未必会主动联系他的现任经理，因为两个人可能从未见过。

接下来，各种问题便会出现：

• 双方掌握的信息不一致
• 现任经理觉得自己被蒙在鼓里
• 新团队担心流程不透明
• 员工担心自己的发展受到阻碍
• 团队之间产生信任危机
• 谣言和内部政治开始出现

而这些问题，本来都可以通过提前达成共识，并把公司对内部调动的基本立场记录下来而避免。

企业流程背后隐藏的价值观

现在，请从一个关心企业文化传承的人的角度，重新看看这套枯燥流程。

这些规则究竟在试图保护什么价值观？

员工必须在当前岗位工作满一年，才能申请新的内部职位

这条规则可能想表达的是：

我们重视对团队承诺的履行。

公司愿意支持员工成长，但也希望员工对已经承担的职责保持基本的稳定性。

员工必须达到“良好”或以上的绩效等级，才能申请调动

这条规则可能想表达的是：

如果有人表现不佳，我们应该帮助他解决问题，而不是把问题转移到公司的另一个团队。

我们不会把绩效问题推给别人。

我们会正面处理，而不是假装问题不存在。

员工可以先与新岗位的招聘经理沟通，再与当前经理正式讨论

这条规则可能想表达的是：

我们理解人的目标会发生变化，也支持员工探索新的成长机会。

与此同时，我们重视透明沟通，因为我们知道，信息不对称会制造误解和伤害。

这些规则本身看起来很无聊。

但它们背后记录的，可能是公司对承诺、成长、责任和透明度的理解。

谁应该负责制定流程

遗憾的是，当公司决定制定内部调动政策时，这项任务往往会落到擅长设计流程，却未必擅长阐释企业文化的人手中。

这些人可能非常认真，也非常尽职。

但如果他们只写下了“应该怎么做”，却没有说明“为什么这样做”，就可能在不知不觉中削弱流程原本想传递的文化和价值观。

理想情况下，流程的制定者应该同时具备两种经验：

• 真正感受过缺少流程所带来的痛苦
• 深刻理解公司的文化和价值观

只有这样，流程才不会变成脱离现实的规定。

流程为什么会逐渐失去意义

你可以想象，所有流程最初都是为了记录企业文化、价值观和过去吸取的教训。

但在大公司里，事情不会永远这么简单。

即使最初由资深员工认真记录了问题和解决方式，这些人最终也会离开。

随着他们离开，那些没有写进流程的背景信息也会随之消失。

最初促使流程诞生的痛苦，会逐渐被人遗忘。

公司最后只剩下一堆规则，却忘记了规则为什么存在。

于是，当新人问：

“为什么一定要这么做？”

没有人知道答案。

他们只能说：

“我们一直都是这么做的。”

这正是流程开始腐化的时刻。

工程师为什么总要追问流程

工程师会本能地追问原因。

当他们对某个人或某件事感到困惑时，往往会举手问：

“这看起来效率很低，能解释一下为什么要这么做吗？”

当然，他们真正说出口的话可能没有这么客气。

有时，问题会带着尖刻、讽刺，甚至粗鲁的语气。

这很容易让负责执行流程的人感到恼火。

但如果暂时忽略这种语气，你会发现，工程师真正想做的是：

找到清单和规则背后的事实。

他们想知道，这套流程究竟在保护什么。

不要机械执行研发流程

所有参与流程的人都有选择。

你可以不加思考地照着清单执行。

也可以继续追问：

“为什么？”

第一次问，可能没有人理你。

第二次问，可能仍然得不到答案。

问到第七次时，你甚至可能被贴上“麻烦制造者”的标签，或者被排除在会议之外。

但我仍然建议你继续问。

只是要注意提问的方式。

提问应该帮助大家思考，而不是带着指责。

当对方尝试解释时，即使答案不够清楚，也要认真倾听。

因为他可能只掌握了部分背景，而不是完全没有答案。

健康流程必须经得起追问

这里存在一个常见误解。

有人认为，既然流程已经存在，就应该照着执行，不必反复质疑。

但一套健康的研发流程，不仅应该记录团队真正重视的事情，还应该能够解释并捍卫自己存在的理由。

它必须经得起审视和追问。

如果一套流程无法解释自己为什么存在，就应该被重新检查。

它可能已经不再适合当前环境。

也可能流程本身没有问题，只是团队忘记了它原本想解决的问题。

无论是哪种情况，都需要作出改变。

判断一套流程是否健康，可以问以下几个问题：

• 它试图解决什么具体问题？
• 它保护了哪些团队价值观？
• 它是否仍然适合当前团队规模和环境？
• 它为团队带来的收益是否高于执行成本？
• 当有人追问时，是否有人能够解释它为什么存在？
• 团队是否拥有修改和废除它的机制？

坚持理解流程背后的原因。

因为如果一套流程无法为自己辩护，就意味着组织很可能已经忘记：

自己曾经相信什么。