工程师为什么讨厌流程？揭开研发流程管理的真相

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

流程。

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

话音刚落，你大概就能听见一片叹息，看见有人开始翻白眼。于是，你很容易得出一个看似合理的结论：工程师天生讨厌流程。

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

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

软件工程师的工作是编写代码，而代码本身，无非是被固化、被自动执行的流程。

那么，问题究竟出在哪里？工程师为什么一听到“流程”就开始抱怨？

因为工程师真正讨厌的，并不是流程，而是那些无法解释自身合理性的流程。

工程师真正讨厌的不是流程

在海外某家大型科技公司里，有一个叫作工程项目经理的职位。他们的一项重要职责，就是推动流程落地。

他们会参加缺陷评审等会议，确保流程中的每一个环节都得到落实。我个人更愿意把精力放在人和产品上，而不是整天盯着流程，所以我一直很欣赏这个角色。

一名优秀项目经理的职责，是通过一切合理手段确保项目按时完成。

然而，在过去二十年里，我接触过的项目经理中，大约有 70% 都算不上优秀。

问题不在于他们无法推动项目按时完成，而在于他们并不知道，自己为什么要这样推动。

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

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

想让我生气其实很容易。

当我提出一个澄清问题，而这个问题会直接影响我如何安排自己的时间——也就是我最宝贵的资源——你只需要拒绝回答，就足够了。

这种拒绝解释的态度，正是工程师厌恶流程的根源。

流程原本应该帮助混乱的世界恢复秩序，但当它落到不理解流程的人手中，就会变成一件迟钝而粗暴的工具。它既无法解释问题，也无法说服任何人，只会不断激起抵触和愤怒。

健康的研发流程为什么重要

写下这个标题时，我甚至有些难过。

因为那些盲目执行流程的人，已经彻底败坏了“流程”的名声。

但如果你愿意追溯一项流程是如何产生的，就会发现三件事：

第一，是什么背景让这项流程变得必要；

第二，这项流程究竟优秀在哪里；

第三，也是最重要的一点，你在维持这项流程有效性时，究竟承担着什么责任。

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

每个人都彼此熟悉，也知道事情的来龙去脉。你不需要专门记录一件事情应该如何完成，因为所有人都知道该怎么做。即使有人不知道，他也清楚应该去问谁。

如果发现某个地方出了问题，你会毫不犹豫地站出来说：

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

之所以会这样，是因为在小团队里，每个人都会对公司产生强烈的责任感。大家都在拼尽全力，也都认为自己有义务让公司变得更好。

在所有这些日常行为背后，隐藏着公司最重要、却也最难被直接看见的东西：

价值观和企业文化。

当公司规模还很小时，你可能根本没有正式的使命宣言。每天都有大量事情等着完成，公司甚至还在为生存而努力。

但你选择如何完成这些事情，实际上已经构成了公司的文化和价值观。

假设你在这家虚构公司的走廊里拦住一名员工，问他：

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

他可能会像看疯子一样看着你，然后给出一个和前面那位项目经理完全相同、同样令人不满意的答案：

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

这是双重标准吗？

并不是。

区别在于，如果你真的让这个人停下来，继续追问下去，他通常能够解释清楚。

你问：

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

他会回答：

“因为我们鼓励争论。我们希望听见不同意见，从而作出尽可能明智的决定。”

也就是说，小团队里的很多做法虽然没有被写下来，却不意味着它们没有逻辑。

恰恰相反，这些做法通常深深扎根于团队共同的经验和价值判断之中。

团队规模扩大后，为什么必须建立流程

但当公司规模增长到某个神奇的临界点，也就是人们常说的“邓巴数”附近时，两个彼此关联的拐点就会出现。

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

其次，由于公司里已经有了大量老员工，新员工会逐渐产生一种错觉：公司的文化早已定型，自己不可能再对它产生影响。

于是，公司内部开始形成两个目标相同、认知却截然不同的群体。

第一类：老员工

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

他们熟悉公司的文化和价值观，因为他们早已成为其中的一部分。他们了解各个部门是如何运作的，也知道出现问题时应该找谁。

无论他们是否意识到，老员工本身就是公司价值观的化身。

第二类：新员工

这些人通常是在过去一年左右加入公司的。

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

而那些最有资格解释的人，往往忙着推动公司继续前进，没有时间向新人讲述那些在自己看来理所当然的事情。

结果，新员工对很多事情感到困惑。

更糟糕的是，他们不了解公司的内部运作，也不知道某个问题究竟应该去问谁。

等入职初期的新鲜感消退之后，他们开始因为无法理解工作的意义、决策的逻辑和组织的运行方式而感到愤怒。

问题在于，老员工很难想象一个“并非所有人都知道一切”的世界。

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

当他们开始听到新员工的抱怨时，给出的建议往往是：

“别废话，赶紧去解决。这也是你的公司。当初我就是这么做的。”

这种话几乎毫无帮助。

新员工当然希望解决问题，但他们根本不知道应该从哪里开始。老员工却用一种自信而轻率的态度暗示：问题明明很简单，你为什么还不行动？

这只会让新人更加抓狂。

最终，公司会召开一场会议。

白板上写满了建议和讨论。不同公司可能会给最终成果起不同的名字，但本质上发生的是同一件事：

有人主动把“我们是如何完成工作的”记录了下来。

于是，流程诞生了。

流程管理的本质不是控制

当你再次想到“流程”时，我希望你能想起这个时刻。

因为流程被创造出来的那一刻，可能是一个非常高尚的时刻。

流程最初并不是为了控制人，而是为了记录和传承文化与价值观。

你可能已经很难这样理解流程了。因为在长期与各种僵化制度打交道之后，我们已经习惯把流程看作一份乏味的操作说明，只告诉人们应该怎么做，却从不解释为什么要这样做。

但一套真正优秀的流程，不应该只记录“怎么做”。

它还应该解释“为什么做”。

这也是研发管理工具真正应该发挥作用的地方。以 PingCode 为例，它不仅可以承载需求、评审、排期、开发、测试和发布等研发流程，还可以通过 Wiki 把流程背景、决策依据和团队经验持续沉淀下来。工具的价值，不只是让每个人按步骤执行，更重要的是让后来加入的人能够理解：这套流程为何存在，又在保护什么。

一份看似枯燥的内部调动流程

下面介绍一套非常枯燥的流程：内部调动流程。

当一名员工希望从一个团队调到另一个团队时，管理者通常会提到它。运气好的话，你甚至知道公司里存在这样一套流程。

它可能包含以下几条规定：

1. 员工必须在当前岗位工作满一年，才能申请新的内部职位。
2. 员工必须达到“表现良好”或以上的绩效等级，才能申请调动。
3. 在正式告知现任经理之前，员工可以先与目标岗位的招聘经理进行一次初步沟通。

就是这样。

看上去是不是非常无聊？

是谁写的？大概又是人力资源部门写下的一堆陈词滥调，对吧？

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

但对方当时也许真的想帮助你。

想象一下，公司只有 42 个人时，内部调动是如何发生的。

弗兰克想尝试设计工作，于是他找设计负责人卢克聊了聊。卢克又和弗兰克的直属经理亚历克斯一起喝了杯啤酒。几个人把事情聊清楚之后，一周之内，调动就完成了。

但当公司从 42 人发展到 420 人时，这种依赖非正式关系的沟通方式就很难继续运转。

原因有很多。

弗兰克可能根本不知道设计团队是否有空缺，因为他不认识卢克。

即使他偶然发现了一个职位，并主动和卢克聊过，卢克也未必会想到去找亚历克斯沟通，因为两个人同样不认识。

于是，各种误解开始出现。

有人抱怨信息不透明，有人怀疑管理者在背后操作，有人觉得自己被绕开。接下来便是信任危机、沟通障碍和内部政治斗争。

而这些问题原本都可以避免。

我们只需要提前达成共识，并把公司对于内部调动的立场记录下来。

流程背后真正想保护的价值观

现在，请试着从一个关心文化传承的人的角度，重新审视这套枯燥的流程。

它真正想传递的价值观是什么？

再看一遍。

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

这条规定背后的价值观是：

我们重视对团队作出的承诺。

当你加入一个团队时，团队会为你投入招聘、入职、培训和协作成本。因此，我们希望每个人都能认真履行一段合理期限的承诺，而不是频繁地在组织内部流动。

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

这条规定背后的价值观是：

当一个人表现不佳时，我们会帮助他解决问题，而不是把问题转移给公司的另一个团队。

我们不会假装问题不存在，也不会通过调岗把管理责任推给别人。

我们会直面问题，并努力解决它。

员工可以先与目标岗位的招聘经理进行初步沟通

这条规定背后的价值观是：

我们理解人的情况和职业目标会发生变化。

我们希望员工成长，也允许员工探索不同的发展机会。

与此同时，我们坚持沟通透明，因为我们知道，沟通不足很容易制造误解，而误解最终会伤害信任。

可惜的是，当公司需要制定内部调动政策时，这项工作往往会交给那些擅长设计规则、却不擅长阐释企业文化的人。

结果是，他们可能非常认真地完成了流程设计，却在无意中削弱了公司原本想传递的文化和价值观。

真正合适的流程设计者，既应该亲身感受过“缺乏流程”所造成的混乱，也应该深刻理解公司的文化。

当流程失去原本的背景

理想情况下，每一套流程都应该用来捕捉和记录企业文化与价值观。

但在大型公司里，事情没有这么简单。

即使某位深刻理解文化的资深员工，愿意花时间梳理问题、记录痛点，并据此设计流程，这个人最终也可能离开公司。

当他离开时，与流程相关的历史背景和文化记忆也会随之消失。

人们会逐渐忘记，当初究竟发生了什么，才让这些规定变得必要。

最终，流程只剩下一串条款。

当有人追问：

“为什么要这样做？”

没有人能够回答。

于是，流程开始变质。

工程师为什么总是在追问“为什么”

工程师有一种本能：追问原因。

当他们对某个人、某件事情或某套制度感到困惑时，他们会举手问：

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

当然，工程师通常不会这么客气。

他们更可能用一种尖锐、讽刺，甚至略显粗鲁的方式提出问题。这自然会惹恼那些负责执行流程的人。

但如果抛开语气问题，工程师真正想做的，是寻找那份清单背后的真相。

每一个参与流程的人都有两个选择。

你可以盲目地照着清单执行，也可以继续追问：

“为什么？”

第一次提问时，对方可能不理你。

第二次也是如此。

到了第七次，你可能会被贴上“麻烦制造者”的标签，甚至被取消参加相关会议的资格。

但我的建议是：继续追问。

当然，提问时应该以启发和理解为目的，而不是以指责为目的。

当对方试图解释时，即使他的解释不够完整，也请认真倾听。因为他可能只知道部分历史，却依然掌握着某些重要线索。

优秀的流程必须经得起质疑

很多人误以为，挑战流程就是反对秩序。

事实恰恰相反。

一套健康的研发流程，不仅应该记录我们所重视的事情，还必须有能力解释和捍卫自己。

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

如果一套流程无法说明自己为什么存在，无法解释它试图解决什么问题，也无法证明它仍然有效，那么这套流程就必须被重新审视，甚至改变。

因此，无论团队使用 PingCode 这样的研发管理平台，还是采用其他方式管理流程，都不应该只是把线下规则搬到线上。更重要的是让需求、任务、评审、缺陷、交付数据和决策记录能够相互关联，使团队既看得到流程如何运转，也找得到流程为什么这样设计。

请坚持理解每一套流程背后的原因。

因为当一套流程已经无法为自己辩护时，真正暴露出来的问题并不是流程设计得不够好。

而是组织已经忘记了，自己最初究竟相信什么。