# I don't think AI will make your processes go faster # 我认为 AI 不会让你的流程变得更快

I have the feeling that every organization out there is, at least partially, focusing on process optimization, something that often happens when the market is down. These days there is also the AI angle to the entire thing, and the unrealistic expectations that follow it. 我有一种感觉，现在几乎所有组织都在至少部分地关注流程优化，这在市场低迷时经常发生。如今，整个事情又加上了 AI 这个视角，以及随之而来的不切实际的期望。 To come fully prepared for this, I’ve decided to re-read two absolute classics in this space: [The Toyota way](https://en.wikipedia.org/wiki/The_Toyota_Way) & [The Goal](https://en.wikipedia.org/wiki/The_Goal_%28novel%29) [^1]. I’ve read both of these books in college, but re-reading them made me realize that a lot of these process optimization exercises are too simplistic in nature, and often misunderstand what to focus on. 为了对此做好充分准备，我决定重温该领域的两本绝对经典之作：《丰田模式》（The Toyota Way）和《目标》（The Goal）[^1]。我在大学时读过这两本书，但重读后我意识到，许多流程优化的实践本质上过于简单化，并且常常对真正该关注的重点存在误解。 ## The visual bottleneck ## 可视化的瓶颈 Let me show what I mean. 让我来展示一下我的意思。 ```mermaid gantt title Project Timeline dateFormat YYYY-MM-DD section Scoping Feature exploration :s1, 2024-01-01, 10d Budget scoping :s2, after s1, 3d Legal :s3, after s1, 10d Documenting :s4, after s3, 5d section Development Exploration :d1, after s4, 25d Software Development :d2, after d1, 70d Documentation :d3, after d2, 5d section Deployment Deployment :dp1, after d2, 5d Hyper-care :dp2, after dp1, 10d ``` *This is a Gantt chart for demonstration purposes, normally you would look at BPMN. Showing a Gantt makes the point easier.* *这是一个用于演示的甘特图，通常你会查看 BPMN（业务流程模型和符号）。展示甘特图能更容易地说明问题。* If you take a look at this Gantt chart you will immediately see what takes the most amount of time: software development. If your task was to improve project throughput, that would be your first stop. And that would be correct. 如果你看一下这个甘特图，你会立刻发现耗时最长的是什么：软件开发。如果你的任务是提高项目的吞吐量，那将是你的第一站。这显然也是正确的。 The problem, however, is how I typically see people go about it: throw people at the problem[^2] or just assume AI is going to make it so much faster. 然而，问题在于我通常看到人们是如何处理它的：要么用“人海战术”解决问题[^2]，要么就直接假设 AI 会让它变得快得多。 What people typically don’t do is look at **why** this is taking so long, and even more importantly: long duration does not automatically mean the problem originates there. 人们通常不会做的是去探究**为什么**这需要这么长时间，更重要的是：耗时长并不自动意味着问题就出在那里。 ## Solving the issue upstream ## 在上游解决问题 We are now talking about software development, but this is applicable to all processes that take longer than you would like. 我们现在谈论的是软件开发，但这适用于所有耗时超出你预期的流程。 Every software developer knows that you can’t make projects go faster just by typing faster. If that were the case we would all be taking typing lessons. 每个软件开发人员都知道，仅仅通过打字更快是无法让项目进展得更快的。如果真是那样，我们早去上打字课了。 Software development is about translating a problem into a solution that a computer can understand and automatically resolve. Preferably in a secure and scalable way. 软件开发是将问题转化为计算机能够理解并自动解决的方案。而且最好是以一种安全且可扩展的方式。 To do something like that, you need a full overview of the problem. Either in feature or scope documents (if you’re going more waterfall), or with constant iteration with the domain experts (more agile). 要做到这一点，你需要对问题有一个全面的概览。无论是在功能或范围文档中（如果你更倾向于瀑布流），还是与领域专家进行不断的迭代（更倾向于敏捷开发）。 This is often the part that slows down software development. Trying to figure out what a vague, title only, feature request actually means. 这往往是拖慢软件开发进度的部分：试图弄清楚一个模糊的、仅有一个标题的功能需求究竟意味着什么。 What does “send mail to user once sale is completed” mean? Ok, we can send a mail, but what should be in the mail? What if there was an issue in the sales process, do we still send an error mail? When is a sale completed? “销售完成后向用户发送邮件”是什么意思？好吧，我们可以发送一封邮件，但邮件里应该写什么？如果在销售过程中出现问题，我们还要发送错误邮件吗？什么才算“销售完成”？ ## Just throw AI at it ## 直接把问题扔给 AI 吧 An argument that I keep hearing about the automation of software development (AI generated code) is that you can just bypass the development part and the software developer becomes the project manager. AI discussions around software development actually illustrate this problem perfectly. 我经常听到的一个关于软件开发自动化（AI 生成代码）的论点是：你可以直接绕过开发部分，软件开发人员将变成项目经理。围绕软件开发的 AI 讨论实际上完美地说明了这个问题。 A lot of people expect the outcome of AI development to look like this: 许多人期望 AI 开发的成果看起来像这样： ```mermaid gantt title Project Timeline dateFormat YYYY-MM-DD section Scoping Feature exploration :s1, 2024-01-01, 10d Budget scoping :s2, after s1, 3d Legal :s3, after s1, 10d Documenting :s4, after s3, 5d section Development AI development :d1, after s4, 3d section Deployment Deployment :dp1, after d1, 5d Hyper-care :dp2, after dp1, 10d ``` But that’s not how this works. Here we face the exact same upstream issue as before. 但这并不是它的运作方式。在这里，我们面临着与之前完全相同的上游问题。 Yes, AI can generate code quickly (whether that’s a good thing is open for debate), but that doesn’t mean it’s generating the correct code. 是的，AI 可以快速生成代码（这是不是件好事还有待商榷），但这并不意味着它生成的是正确的代码。 In comparisons between human vs AI development they always ignore the handholding that is needed for AI to do its thing. It looks a lot more like this: 在人类与 AI 开发的对比中，人们总是忽略了 AI 完成工作所需要的“手把手指导”（保姆式介入）。它实际上看起来更像这样： ```mermaid gantt title Project Timeline dateFormat YYYY-MM-DD section Scoping Feature exploration :s1, 2024-01-01, 10d Budget scoping :s2, after s1, 3d Legal :s3, after s1, 10d Documenting :s4, after s3, 40d section Development AI development :d1, after s3, 40d section Deployment Deployment :dp1, after d1, 5d Hyper-care :dp2, after dp1, 10d ``` Maybe this setup is faster compared to the old way of working. But I also think it’s an unfair comparison. Working like this requires a much deeper involvement of domain and product experts. This involvement would mean writing out every feature and bug fix down to the tiniest detail. 也许这种设定与旧的工作方式相比确实更快。但我也认为这是一个不公平的比较。像这样工作需要领域和产品专家更深入的参与。这种参与意味着要将每一个功能和错误修复都写到最微小的细节。 This exact thing is what software developers have been begging for since the beginning of the profession: Receiving a detailed outline of the problem and what the end result should look like. 而这正是软件开发人员自这个职业诞生以来一直梦寐以求的：收到关于问题的详细提纲，以及最终结果应该是什么样子的。 If you were to give human developers the same amount of feature/scope documentation you would also see your productivity skyrocket. 如果你给人类开发人员提供相同数量的功能/范围文档，你也会看到生产力呈火箭般飙升。 ## Actually speeding up processes ## 真正加速流程 If you want to speed up processes, you need to make sure that the people that need to do the work have all the means to actually do the work. 如果你想加快流程，你需要确保需要完成工作的人拥有实际完成工作的所有手段。 This means that if your legal approval process is going slow, you take a look at what is needed to start a legal approval process. If they need to chase five different people for incomplete documents, you’re not going to speed up said process by adding more lawyers to the department. 这意味着如果你的法律审批流程进展缓慢，你应该去看看启动法律审批流程需要什么。如果他们需要追着五个人去要不完整的文档，你在部门里增加更多的律师是无法加快该流程的。 One of the big lessons of The Goal is: ”bottlenecks should receive predictable, high-quality inputs”. 《目标》一书给我们的一个重要启示是：“瓶颈环节应该接收可预测的、高质量的输入”。 I think that should be the first stop in process automation. 我认为那应该是流程自动化的第一站。 *** ### Footnotes / 脚注 [^1]: The Toyota way is amazing and I would highly recommend it. The Goal is a bit of a less pleasant read, I would go for the comic version ↩︎ 《丰田模式》非常棒，我强烈推荐它。《目标》读起来相对没那么轻松，我会推荐去读它的漫画版。 ↩︎ [^2]: The Mythical Man-Month. Another classic ↩︎ 《人月神话》。另一部经典之作。