软件项目估算是软件工程领域的一大难题，因为影响工程进度的因素太多。不过业界一般有两种评估的方式，一种是自顶向下的评估方法，另一种是自底向上的评估方法。

第一种方法你需要向功能业务最为接近的三个移动APP的开发团队询问他们的开发时间，了解他们的团队规模，多少个开发多少个测试多少项目经理多少产品经理，各个开发人员、测试人员的水平（可以用薪水大致衡量）等等。在你得知了一个成熟的团队水平、规模和相应的开发时间之后，你就可以规划自己的团队该如何组建，开发计划应该如何安排了。听取其他团队情况的时候不要只听开发时间，要把实际的需求产品设计测试等时间都了解一下，中途返工了多少次，大改了多少次都要问问。另外最好了解一下人家上线后的迭代周期，第一版有哪些功能，经过了多长时间多少次迭代变成现在的样子。

千万不要想当然认为自己的需求很明确，而且以后不会改了，以市场上同类产品那么成熟稳定的东西还在每个月迭代升级，你完全有可能在第一个版本项目进行到80%的时候突然想做一个小调整，而开发人员却发现要推倒重来，如果你追问这个真的要完完全全推倒吗？他们一定会回答你还是有可用的东西的，然并卵，剩下需要的开发周期和重做相比不会缩短多少的。当你充分了解了三个同类应用的情况之后，你要做的就是在他们的基础上加入风险成本估算，比如能力强的开发一时间就是招不到，或者难得见到一个还不错的家伙开价太高，检查计划发现时间过去了40%，队伍人数却只到预计的五分之一等等。

第二种方法你要先有一个团队，或者你找到信任的朋友帮你组建一个团队，或者干脆收购一个团队。然后你可以把想要的功能一个个列出来，给你信任的团队头头做任务分解，当然实际上这个过程可能会花掉一两个星期，他负责任的话会和你反复确认细节，如果他不负责任的话可能就直接开始做计划了。总之任务交下去团队里每个具体执行人会估算具体的每个部分的时间，然后把所有人评估的这些时间全部加起来乘以风险系数，就是你的团队做这个项目需要的时间。

询问时间的时候一定要让对方自己评估，不要用“三天够不够”之类诱供式的问话方法。你可以主动提出让他回去好好想想再给个靠谱的答复，不要对方谨慎地说要考虑考虑你就强调只要个“大概”。如果真的每个人都只报一个大概，那么你估计出来的结果会偏差极大。

尤其千万不要在听到对方答复的时间之后反问“一个月太长了，三个星期行不行？”你如果是老板或者高管反问这句话八成以上的结果是开发人员回答你加加班应该可以，但最后你会发现现实是一个月也不可能完成的。你需要清楚你的目的是更精准地估算你的项目，而不是逼人回答一个你想要的结果。

开发人员总喜欢乐观估计，他们有的人会明确告诉你“假如一切外部条件都完备”，那么需要多长时间，有的人可能隐含地认为外部条件不完备不是他的责任。讫今为止我还没有见过哪个管理者能真正协调好扫清所有外部障碍。真实情况一般是一开始管理者对开发人员说不用担心外部影响，只管估计自己的部分就行。然后真到了他自己的部分都做好了，因为外部问题没协调好而需要项目延期的时候，管理人员再出来一边扣着项目奖金边同意延期。

我和身边朋友所总结出的经验数据是在团队人员稳定的情况下，项目实际花费的时间大约是项目一线开发人员自己估算的每个模块的时间全部加起来再乘以3到5，没错，风险系数就是那么高，软件项目不可预知的因素实在太多了。