我告诉你一个很靠谱的估算方式，但是这个估算方式上不了台面，你知道就好，不要真的在报告上把这种计算方式写进去。

你先按照最土的方式去估计成本，比如你知道模块数量，已经每个模块大小，根据历史经验估计一下不同大小模块需要多少人月，得到一个数字N，然后，你把这个数字乘以π，差不多就是3.14，最后的3.14*N就是你应该估计出来的人月。

不要笑，我有理论依据的。

你的项目从『开始』到『结束』，你预期就是按照这个箭头前进，对吧？

但是，无论你如何计划，从你开始那一刻开始，就会有各种狗血事情发生，有需求变化，有人员变动，有理解错误......总之你肯定不会沿着直线前进的，你开始绕一个弯路，但是你会努力让前进方向靠近结束，所以实际路径趋向于这样。

没错，差不多就是画了一个半圆，你才能够做完，但是，当你做完的时候，发现做出来的东西和想要的并不一样，这其中当然有很多原因，但是总之你做错了，咋整？

你当然只能接受搞错了，然后设定新的『真正的结束』，重新出发，这时候你计划的路程和之前从『开始』到『错误的结束』路程一样。

当然，当你重新开始的时候，你会经历前一阶段一样的事情，开始那一刻开始，就会有各种狗血事情发生，有需求变化，有人员变动，有理解错误......总之你肯定不会沿着直线前进的，你开始绕一个弯路......

最后你终于完成了项目！

这时候你回头看一下你走过的路， 实际上是走了两个半圆，合起来就是一个圆，而你最初计划的路程，就是这个圆的直径——所以，实际的成本是最初计划的π倍！

现在你知道该怎么估计软件成本了吧，不用谢。