我上个月因为「需求没说清」白做了三天

三天前刚交付，客户说「我以为是另一个版本」。我盯着屏幕，不知道该怪自己还是怪对方。后来我在一个程序员论坛上看到一句话，突然觉得被戳中了： 「需求永远不会在项目开始时就完整。」 不是客户坏，是这件事本来就这样。我之前一直以为是自己沟通能力不行，原来这是所有做项目的人都会踩的坑。

这些「规律」是什么，谁在用

有个网站叫 Laws of Software Engineering，收集了程序员几十年总结出来的项目规律。听起来很技术，但我翻了一遍，发现里面说的事情跟写代码没什么关系，说的是 人、需求、时间、复杂度这些东西。

比如有一条叫「布鲁克斯定律」：往一个已经延期的项目里加人，只会让它更晚交付。我朋友小雯在上海做品牌设计，去年接了一个大单，中途拉了两个朋友进来帮忙，结果三个人对齐沟通花掉的时间比省下来的还多，最后延期了两周。她说「早知道自己扛完算了」。这条规律说的就是这个。

还有一条我很有感触： 「任何系统，只要还在被使用，就会持续变复杂。」 你的报价表、你的客户群、你的内容选题 —— 只要还在跑，就会越来越乱。不是你的问题，是规律。

你今天可以怎么用（不需要懂技术）

钱： 0 元，网站免费。
时间： 读完核心 10 条规律大概 15 分钟。
技术门槛： 会看中文翻译就行，我用浏览器自带翻译功能全程没障碍。
第一步：打开 law sofsoftwareengineering. com，直接往下滚，找到「 Brooks ' Law」和「Complexity 」这两条先看。

我自己的用法是：每次接新项目之前，对照这几条规律想一遍「这次哪个坑最可能踩」，然后在和客户的第一次沟通里提前说清楚。不是照本宣科，就是心里有底。

这工具不是所有人都需要，如果你现在项目流程已经很顺，完全可以跳过。

分人群建议

如果你刚起步、还在摸索接单流程： 我会建议你先只看「需求会变」和「越改越复杂」这两条，对照自己上一个项目想想哪里返工了，比看任何方法论都管用。

如果你已经有 1-2 个稳定客户： 我会建议你把「布鲁克斯定律」打印出来贴在桌边 —— 下次客户说「要不要再找个人帮你」的时候，你心里会有答案。

如果你在扩规模、开始带人或外包：这个网站里关于「沟通成本随人数指数增长」的部分值得认真读，它会帮你想清楚什么时候该加人、什么时候该砍需求。