老板问做完某个功能要多长时间，怎么回答

让有相关或类似经验的团队成员来估会比较靠谱，如果依旧无法估算那就作为项目风险记录并估计其对项目的影响以及相关利害关系者的承受能力。比如成本的增加或进度延期

对于一个没有先例的新任务，我一般会自己估个大概时间（PT）（按普通水平程序员能力估算），然后问程序员乐观估计要多长时间，悲观估计要多长时间，最后我给个计划时间（RT）【RT=（乐观时间*1+悲观时间*4）/5】。如果RT>PT则分析情况说服程序员同意PT，如果RT<PT则按RT。

等领导审批的时候会先按RT报，看领导反应，如果领导同意则按RT走，不同意则最低不能低于PT。


问题已回答，LZ给分！闪人~~~~

我也最怕问这个问题了，我总感觉有一个期限的话，自己心里老是不爽。。。

这样的估算方式是正确的，有点类似PMP理论中的PERT

那个理论前面有人回答，（乐观*1+可能*4+悲观）/6 ，不过一般这个公式在实际中特别是中国现在的行情下对一般的程序员不太有效，需要加点班才能完成，但是按照（乐观时间*1+悲观时间*4）/5的时间一般都能做的很好

大家估的时间是指单完成coding还是指能deploy的时间。。。，我最近被老大问了几次这个问题了。都没有很好的答案，太少了到时候会被说拖进度，太多了老大有点不高兴了。。。

不管老大高兴不高兴，不能少估，测试一定要做到位，因为项目出bug，造成金钱损失，主开发人员是要被罚钱的，做电商的，谁能保证不出错

正常来说，你应该对每个功能，每个页面，每个按钮，每个后台做核对。
核对的角度有：功能复杂度（前台、后台），员工生产性（工作经验，动手能力，工作态度），外界因素（天气、假期心态、员工家庭情况），需求方合作态度（需求是否明确、是否会变动、是否有隐含需求），非开发因素（美工时间、测试时间、修改时间），可重用因素（相同或相似页面可以缩短工时），架构因素（公用功能建设，公共文档建设），等等诸多因素考虑在一起。

如果你的考虑面够宽，计算比较精准，时间是很好掌控的。 我一般都是按估算的时间×1.2汇报，即便有延期，也不会超过 × 1.5，经过多次项目经验的验证，基本是成功的。

正确做法，先提上去，不能说我没完成，走bug单的事情，谁也说不好，修改bug嘛就不是能估计的啦。

bug驱动开发，高端黑。。。。。。

好像通信行业不少公司这么搞， 先是开发加班玩命写，进度紧张，不自测就直接提测，测试眼巴巴等到升级包发现不能用，reject，开发再玩命修bug，看上去大部分项目都能按期提测，不过最终到了市场、销售手里的时候基本都延期了。