老板要求你估计新项目需要多少时间, 你一般是怎么估算的

老板说多久就多久

我一般是在估算时间的基础上 ×5

自己没经验，怎么估算！

如果是熟悉的内容，看领导着急情况！

尽可能估计你能用的最长时间，然后*2再*1.1。经验公式，没啥理由。不过一般都比较准。

@fkbd 码受你好

@virushuo 我基本也是按照这个公式算的.
但是当我说出我的估计, 和老板心里的估计差几倍的时候, 我估计他心里有一万匹草泥马跑过.

拍照上服器取返回信息? 用系相直接拍照, 到服器拿回 JSON 然後理一下示出, 也就不到一天的工作量. 除非老要求此相一包含十的拍引擎什的...

@alexrezit 关键是他没经验！

对老板说 你觉得一周那你来做

@cxl008
老也啊, 老得一的那他自己做啊. 要他做嘛? 道的就不用工了? 自己成本都算不清楚, 老是?

@alexrezit 其实这个场景和让你现在去一个实验室洗实验器材一样的……看起来容易，做起来就有坑了。要是生物/化学的学生看到你要洗，也会说不就一会儿的事。但是你敢担保你能对保证每种材质、不同用途的的器皿都了解么。

你没经验很难估计准确吧…

如果使用对于你来说新的技术, 那么任何一个坑都可能耽误你一周的时间...

零经验一周没问题啊，还多了，第一版这需求也就hello world级别。

lz的估算方式的最大问题在于，你把三件本来是同时进行一周完成的事情，拆开算了三次。

你不应该学一周SDK再动手，而是看一眼SDK目录和几篇综述性的文档就立即开始，边学边做。
你不会是全部写好了，才开始debug，而是一边开发一边调试，而且这个需求实在没什么出bug的空间。

先要求产品需求文档和设计。确定这些后，开发一天。

让 2B 队友先估算 然后 x2 甚至 x3

老板当然想你一天就搞出来呢！

@hbc
其真心不... 做我的直接以前的代面 copy 出段, 一小搞定了.
所以同一公司 iOS 和 Android 者的比例通常是 1:5... 233

@monkeylyf 真要这么说，lz估计要走人了。。。

老夫觉得首先先把mac和iphone买到再来估算时间。

小公司老板，说话别当真，你了解他，顺着他说，你不了解他？早点走人吧。

对没接触过的东西，不要马上去估时间，先要求 1-2 天做些 research, 再根据自己情况去预估，估时间不要太死，可以是一个范围，比如你这情况，向老板说明哪些坑自己把握不是很大，可能会要两个星期，同时也告诉老板如果顺利的话，最快 2-3 天(给老板一点安心) 也可以

这个很简单呀，一天行不行？不行就两天，两天行不行？不行就三天 ，一直循环...

三周的确太长了 直接报出来老板是比较不好接受，
从0开始（以前写过其他GUI的代码就可以），看几个demo project，搬一点代码拼在一起，自定义修改一下，一周时间基本是能完成的

所以应该跟老板说我尽量一周内完成，最多再加三两天

我这边的产品 才有意思呢。
今天刚发来一个文档。N多东西。
然后说 6.1放假前 客户希望看到。

我直接拒绝了。手上还有N多事情呢。搞什么呀

@dingtianran 我知道的,80%的情况下, 三天甚至一二天就够了.
不过以前吃过很多乐观估计的亏, 另外有时候自己对需求的理解和老板的理解可能不同.

忽略我这个案例, 预估项目时间始终是一件很难的事.

上班最厌恶的就是让预估时间这件事了，因为这反映出老板对你的不信任，以为你要多搞点时间出来自己玩呢，作为在职业道德上对自己要求比较严格的人，还有什么比这更令人难受的吗

我一般是自己估算时间*1.5，但很多时间领导说多久就多久，没反抗的余地。

有个朋友老板让做个商城的网站，我说最快三个月上线，结果那个老板立即嘴一歪说拉机吧倒.....

后来找了几个人开发，半年多过去了还没上线

@maddot 是的, 你说出了我的心里话, 我也是这样的感受. 但是换位思考下, 作为老板, 他需要预估成本, 也可以理解.

@guoqiao 这个分寸是很难把握的，这个项目完不完成是小事。不好的情况是老板觉得你忽悠他，以后给的时间越来越短。。。。

你怎么算你自己想
我告诉你老板怎么算：必须满足你的工资*时间<<<项目价值
花一周的工资让你“学习”，这个怎么说也不划算
就两个功能，测试也要一周的花费，也是不划算
that's it

估算了又有毛用，领导又不那么想，遇到这种事情要么就做好心理准备
和@Yegrit说的一样，现实情况就是那样
老板，你拉鸡巴倒吧

领导说多久就多久，做的时候延误了那不管你的事，原因都记好，像雷锋一样要写日记，要不然到头来都是你的问题

@honk 这才是靠谱的答案

我觉得项目估计的时间，基本都是扯谈。除非是做非常 routine 的项目。没事出个错，学个新东西啥的，哪有那么好估算时间。当然，项目质量不用保证，还是容易估算时间的...

老板其实挺容易做的，就是不停的问你：啥时候能做完? 啥时候能做完?
你要是被问的不耐烦了，说了一个时间，好吧，从此之后，就是你的错的，你“按时”玩不成，就天天催你，谁叫你估算了时间呢？

有经验的一周差不多，没经验3周远远不够，3个月也不算多

感觉这个最重要的是需求明确吧，
拍照上传就完了吗？照片如何管理，如何跟其他模块集成。如何复用。。。这些不要考虑吗？

@honk 嗯, 很受用. 感谢

@PrideChung 哈哈,这个有意思.

@wuyazi 嗯, 这就是我前面说的, 老板对项目的理解和程序员的理解经常不同.
他觉得就这么几个功能, 很简单啊. 而如果你严格按照他说的去做, 最后他会问你, 为什么XXX功能都没有? 这还用说吗?
实际上, 当你真正动手去做一个软件项目, 没有真正简单的.
各种细节, 各种坑, 各种改进,各种变更, 还会被别的事情打扰.
当你预估时间时, 尽管你的老板没有意识到这些问题, 但是作为程序员, 你要有一些考量.
预估进度确实扯淡, 但如果你非要给项目定一个期限, 我希望是一万年----越久越好, 否则你就很被动, 累死累活还充满负罪感.
那些没有多少经验, 而自以为自己很聪明的人, 那些看完"21天精通C++"就觉得自己很厉害的人, 那些把3天做完一个项目视为骄傲的人, 是无法理解这些的.

没有人纠结代码质量问题啊
好吧， 我是处女座...

估计时间x2 还有时间能慢慢研究一下项目用到的新东西，急急忙忙的赶工没啥太大收获

我觉得你们老板这个叫拍脑袋
首先一个项目,要做成什么样子的计划有没有?项目架构有没有?这些都没有让程序员直接干活,后面发现架构需要重构,且不是更浪费时间?
coding的确并不需要时间,你甚至可以直接套个web页面来做,不过后期定然是重构再重构了

拍照是个可简单可复杂的功能需求，简单的可以用系统内置的解决，复杂的需要深入底层框架自己做，一不小心使用到OpenGL ES也是可能的。

开发都是怎么死的？老板拍脑袋，拍死的。哈哈

一周真的搞不了，学习iOS就得一点时间。
预估时间再乘个2，3倍比较好。

估也没用，老板说多久就多久，做了再说。

说实话，我不太明白那些说只要一天、两三天、一个星期的人是怎么想的。
项目我规划得不少，有时候领导不懂技术，甚至不明白自己想要什么，只是有个模糊的概念，有时候可能一个非常简单的方法就能满足需求，有时候可能根本是个不可能完成的任务。
所以估算时间的关键在于跟老板充分地沟通，事先在做成什么样子方面达成一致，如果能有参考范本图文并茂地直观地说明更好，否则你很难“按时”完成并让老板认可。
楼主的实际是没有做过IOS开发，所以肯定要把学习、填坑的时间都算进去。
从楼主描述来看，有一个麻烦是，老板想要的是个IOS的App，所以他很可能用常见的app的标准来要求你。所以你一定要摸清楚老板的心理预期才好定时间。
时间方面在老板心里这跟买菜一样的嘛，讨价还价，你开口就是三周，人家不砍对不住自己，何况你还谈判力还不如老板。但只要你能充分说明理由，我想老板肯定也会理解，策略前面@honk 也提到了，给个乐观点时间（这个时间点你起码要拿出一个能看到的雏形），然后给个悲观时间（相当于deadline）。
另外换位思考一下，老板不深入了解技术，所以才让你来估算，他为什么要缩短你的时间呢，因为他想压榨一下水分，试探一下底线，这我想大家都能理解。所以大家不要技术做多了脑子僵化，要多少天就说多少天，不留一点解决问题的机动时间，卖东西也不可能报个成本价呀，累累活还不讨好，那是自己作死。
总之，充分沟通，订好目标，再定时间，努力完成，皆大欢喜。
说实话我觉得对于新手楼主来说，3周都可以说是乐观的估计，一不小心掉个坑里不知花多少时间才能出来。

跟老板说，you can you up.

就这个需求的话，先开口说两个月。后面再慢慢谈。他要快，也可以，严格限制条件，把需要做多少功能，做到什么程度，在谈的时候都列清楚，以及开发这个项目的期间其他工作的处理办法，然后压缩回到2-3周，最后尽量1周内做出来，然后慢慢测试优化一周。

@guoqiao 可惜，我还没老板

曾经经历过过楼主这种情况。
先做任务的划分，对每个点做评估。 心里预估的时间 * 3.
参考这篇博客的附件：（有进度计划的excel)
http://witcheryne.iteye.com/blog/1835254

汇报时间，实际上实在做承诺，承诺一定要靠谱，不要刻意缩短时间。
如果时间超出老板预期，他会跟你沟通的。例如沟通优先级的问题，版本迭代的问题......


BTW, 不要把加班也算进去。

不管老板要求多少，按照自己的经验评估，并X2.

“学习Obj-C以及SDK”一个月
开发半天
其它两天

然后乘以三

@lyazure
@ivvei
@wity_lv
@geekHarvey
@hbc
@honk
@maddot
@dcoder

谢谢各位.
看了你们的答案, 我突然意识到, 这就是v2ex有意思的地方.
每次我提出一些问题, 尽管有很多不靠谱的答案, 但也总是能得到很有价值和共鸣的回答, 比如你们的.
经过这个帖子, 我心中的困惑算是基本解除了, 至少有了一个基本思路去处理预估的问题.
我注意到我发帖后很多同学收藏了这个帖子, 所以你们的答案默默的影响了很多人.
感谢!

@honk 和 @lyazure 的方法不错，给一个乐观时间和悲观时间。另外，我个人感觉楼主把问题划分一下是一个不错的办法，这样有利于更准确的时间估算。之前我估算时就只估算了编码时间了，没有考虑方案选择，单元测试，文档修改，bug修改，以及每天其实工作时间其实也就5小时左右，而不是8小时，所以也经常是把时间估算的太短，也因此受到傻逼管理者的批评

八年过去了，楼主能提供一下您现在的解决方案吗？帮助下后来者，感谢感谢。

@yurong333333 楼上也有人说了，先分析需求。然后按你心中一切进展顺利的情况预计一个时间，然后乘以 3 (or PI).

@guoqiao 哈哈，这是一个老手才能正确预估的方法。感谢楼主。