功能点时间评估？你们怎么评估的呢？

[lifesimple]

最近做一个功能点，做了一段时间（四五天吧，感觉那块交互是挺复杂的），总是想当然答应得很快，然后真的上手做起来，却碰到很多坑，进展不够好。主要项目急（领导一直说项目着急，那我就认为项目很急咯），自己写代码的心态也着急了，然后领导过来，小伙子啊，这功能估计多久完成啊。哎，每当这种情况就很尴尬啊，时间说多了感觉自己能力不行（能力确实 low ），说少了又觉得万一碰到坑没时间了怎么办。 找过一些建议说是，自己估计时间*1.5~2 。感觉一说领导估计觉得哪要那么长时间。 有时候觉得自己是应该说 No 的，对一些复杂的交互需求脑子过一下解决方案感觉挺顺畅，应该花不了太长时间，领导也急就答应下来了，到后来，会出现一些问题

1. 碰到一些坑 时间就不够了
2. 对于复杂交互，赶项目会让自己没时间思考，上来就瞎 XX 写了，结果发现其实思路数据结构方面根本没有理清楚，然后导致返工浪费时间了
3. 当然特么最后搞不定就是自己挖的坑了

所以说对一些评估还是根据自己的能力诚实的去评估，不然搞不定就尴尬了。 要是你们领导让你评估一个功能或者项目做多久，你们怎么处理的呢，可以讨论下哦。

[xujialiang]

合理评估每个功能的开发时间，很难评估的那就拆分后再评估。把风险点列出来，报备。这样，项目延期了，也是可以理解的，人手不够，申请增加人力。

[imcj]

首先评估时间的目的是帮助项目整体计划的实施，目标在于尽可能的准确，是尽可能，不是绝对。一个项目需要若干环节的估时，产品设计、 Ui 设计、后端、前端、测试等等，所以从这个角度上来看，是不存在绝对准确的估时的。

那么，我们应该去追求尽可能的准确。有一个经验可以分享，对于功能估时，应该多个角色参与，产品、 UI 、小组 leader ，项目经理和测试。

为什么需要那么多人，一一道来，你在思考一个需求的开发过程从而给出耗时的时候，你的思路肯定是根据经验和直觉来的，很多时候你会高估和低估，或者遗漏某个重要的逻辑或者想多了。这个时候产品会把逻辑一一和梳理一次，解决我上面说的问题。

ui 设计和产品一样，遗漏了重要的设计需求会造成估时过少。不赘述。

部门 leader 很懂你，因为你每次 delay 的时候他替你背锅，他天天研究你，在估时上比你自己更懂你自己。

测试呢？道理和部门 leader 一样，他们在上线之前，听你说第七次这个 bug 这次一定搞定的时候，他们内心是不相信的，他们说你一个周搞定的事情，基本上已经是八九不离十了。

[FrankFang128]

不管你得到什么的结果是几人天，
乘以 π，
即可。

[Keinez]

如果你是单兵作战，那么功能评估将会……非常的不靠谱。推荐三人及以上的情况下进行评估。如果一定要单人进行评估，确实建议时间翻倍。因为你无法预计会出现什么样的问题。给进度留余量是很正常的事情，因为上头要根据你的进度定计划，你做不出来东西，大家一起倒霉。你提前做出来了，大家一起开心。如果你因为工时长被降薪，那说明你也确实只值这个钱。因为高速意味着高风险，反之则是低风险。抹平风险是需要钱的。

[Miy4mori]

一般按最好情况估算出来后乘以三就差不多了

[murmur]

@FrankFang128 不还有一句补充，必要的时候*10pi 么

[lifesimple]

@FrankFang128
@Miy4mori 恩 感觉评估的时候还是要多考虑一点 留一点 buff

@murmur *10pi 额 这感觉领导要重新招人了

[YzSama]

@lifesimple 这真的是一个很尴尬的东西。

[bulldozer]

贝塔分布，(乐观+悲观+4*可能时间)/6 ， 然后在估算数上加一定的 buffer 。

需求要清晰，需求要清晰，需求要清晰...一定要各方的意见都知道。

[lifesimple]

@bulldozer 恩 谢谢你的建议

[mcfog]

这样说吧，不拆分直接评估出来的时间，大于 3 天的一定不准，就算做乘法也不会准的

拆分后评估的时间，就算不准你也能准确的告诉对方，原本按我预计今天是第三天，预计进度是 40%，但实际进度只有 20%，可能会延两天解决 XX 难点，这个点是以前估漏了／估少了／需求变更导致的

比如常见的拆分

XX 功能点

表结构设计、 model crud 1d
新增、修改接口 1d
列表、筛选逻辑 1d
详情读取逻辑 0.5d
联调自测 1d

总计 4.5d ，留 buffer 后预计一周完成提测

[sampeng]

心里预计时间然后乘以 1.5.然后预留 1 天 buffer 时间。几乎没问题

[sampeng]

还有赶时间不代表没有思考时间，一定要有整个开发的 3 分之二时间是在思考。。三分之一时在写代码。。如果是反的，或者压根没时间去思考，那基本是有问题的。思路通了，三分之一时间写代码效率是非常高的，思路不通，就会在开发过程中碰到所谓的坑。磕磕碰碰就会出现时间预估不准的问题。
ps ：时间不准，只能靠加班解决，别无他法。又想拿高工资，又想很轻松拿是不可能的。总要付出一部分来获取另一部分

[stormpeach]

我一般是乘以 3.。。。

刚开始做得给自己 50%的思考时间，想清楚了再写

[lifesimple]

@stormpeach 是啊 很赞同后一点，不然返工浪费时间。

[skywayman]

1. 从不相信业务和市场部门反馈的:该功能很简单;
2. 所谓报时靠谱其实是经验,就是过的坑够多了,这个很重要;
3. 遇"坑"不要一坐坐 1 天,交流,刷贴,上个 WC,也许坑就豁然开朗了.
4. 活着才有可能完成,死了是没有价值了,为了活着,需要*系数

[fan1234nm]

单兵作战，一般都是 d*2+检测遗漏+buff ，基本都没出什么纰漏。

[Miy4mori]

功能点就需要产品和主程一起讨论了，毕竟有些功能点遇到外行产品是割裂的看的，实际业务是有纠缠的

[mingyun]

@mcfog 赞同