这是一个创建于 2932 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近做一个功能点，做了一段时间（四五天吧，感觉那块交互是挺复杂的），总是想当然答应得很快，然后真的上手做起来，却碰到很多坑，进展不够好。主要项目急（领导一直说项目着急，那我就认为项目很急咯），自己写代码的心态也着急了，然后领导过来，小伙子啊，这功能估计多久完成啊。哎，每当这种情况就很尴尬啊，时间说多了感觉自己能力不行（能力确实 low ），说少了又觉得万一碰到坑没时间了怎么办。 找过一些建议说是，自己估计时间*1.5~2 。感觉一说领导估计觉得哪要那么长时间。 有时候觉得自己是应该说 No 的，对一些复杂的交互需求脑子过一下解决方案感觉挺顺畅，应该花不了太长时间，领导也急就答应下来了，到后来，会出现一些问题
- 碰到一些坑 时间就不够了
- 对于复杂交互，赶项目会让自己没时间思考，上来就瞎 XX 写了，结果发现其实思路数据结构方面根本没有理清楚，然后导致返工浪费时间了
- 当然特么最后搞不定就是自己挖的坑了
所以说对一些评估还是根据自己的能力诚实的去评估，不然搞不定就尴尬了。 要是你们领导让你评估一个功能或者项目做多久，你们怎么处理的呢，可以讨论下哦。
 |
1
xujialiang 2016-11-24 00:15:39 +08:00
合理评估每个功能的开发时间，很难评估的那就拆分后再评估。把风险点列出来，报备。这样，项目延期了，也是可以理解的，人手不够，申请增加人力。
|
 |
2
imcj 2016-11-24 00:56:09 +08:00 via Android
首先评估时间的目的是帮助项目整体计划的实施，目标在于尽可能的准确，是尽可能，不是绝对。一个项目需要若干环节的估时，产品设计、 Ui 设计、后端、前端、测试等等，所以从这个角度上来看，是不存在绝对准确的估时的。
那么，我们应该去追求尽可能的准确。有一个经验可以分享，对于功能估时，应该多个角色参与，产品、 UI 、小组 leader ，项目经理和测试。 为什么需要那么多人，一一道来，你在思考一个需求的开发过程从而给出耗时的时候，你的思路肯定是根据经验和直觉来的，很多时候你会高估和低估，或者遗漏某个重要的逻辑或者想多了。这个时候产品会把逻辑一一和梳理一次，解决我上面说的问题。 ui 设计和产品一样，遗漏了重要的设计需求会造成估时过少。不赘述。 部门 leader 很懂你，因为你每次 delay 的时候他替你背锅，他天天研究你，在估时上比你自己更懂你自己。 测试呢？道理和部门 leader 一样，他们在上线之前，听你说第七次这个 bug 这次一定搞定的时候，他们内心是不相信的，他们说你一个周搞定的事情，基本上已经是八九不离十了。 |
 |
3
FrankFang128 2016-11-24 01:18:21 +08:00
不管你得到什么的结果是几人天，
乘以 π， 即可。 |
 |
4
Keinez 2016-11-24 02:28:54 +08:00 via iPhone
如果你是单兵作战，那么功能评估将会……非常的不靠谱。推荐三人及以上的情况下进行评估。如果一定要单人进行评估，确实建议时间翻倍。因为你无法预计会出现什么样的问题。给进度留余量是很正常的事情，因为上头要根据你的进度定计划，你做不出来东西，大家一起倒霉。你提前做出来了，大家一起开心。如果你因为工时长被降薪，那说明你也确实只值这个钱。因为高速意味着高风险，反之则是低风险。抹平风险是需要钱的。
|
 |
5
Miy4mori 2016-11-24 03:16:53 +08:00 via Android
一般按最好情况估算出来后乘以三就差不多了
|
 |
6
murmur 2016-11-24 09:17:27 +08:00
@FrankFang128 不还有一句补充，必要的时候*10pi 么
|
 |
7
lifesimple OP |
 |
8
YzSama 2016-11-24 09:45:01 +08:00
@lifesimple 这真的是一个很尴尬的东西。
|
 |
9
bulldozer 2016-11-24 09:54:12 +08:00  1
贝塔分布，(乐观+悲观+4*可能时间)/6 ， 然后在估算数上加一定的 buffer 。
需求要清晰，需求要清晰，需求要清晰...一定要各方的意见都知道。 |
|
10
lifesimple OP @bulldozer 恩 谢谢你的建议
|
 |
11
mcfog 2016-11-24 10:44:32 +08:00 1
这样说吧，不拆分直接评估出来的时间，大于 3 天的一定不准，就算做乘法也不会准的
拆分后评估的时间，就算不准你也能准确的告诉对方，原本按我预计今天是第三天，预计进度是 40%，但实际进度只有 20%，可能会延两天解决 XX 难点，这个点是以前估漏了／估少了／需求变更导致的 比如常见的拆分 XX 功能点 表结构设计、 model crud 1d 新增、修改接口 1d 列表、筛选逻辑 1d 详情读取逻辑 0.5d 联调自测 1d 总计 4.5d ，留 buffer 后预计一周完成提测 |
 |
12
sampeng 2016-11-24 11:10:07 +08:00
心里预计时间然后乘以 1.5.然后预留 1 天 buffer 时间。几乎没问题
|
|
13
sampeng 2016-11-24 11:22:27 +08:00
还有赶时间不代表没有思考时间，一定要有整个开发的 3 分之二时间是在思考。。三分之一时在写代码。。如果是反的，或者压根没时间去思考，那基本是有问题的。思路通了，三分之一时间写代码效率是非常高的，思路不通，就会在开发过程中碰到所谓的坑。磕磕碰碰就会出现时间预估不准的问题。
ps ：时间不准，只能靠加班解决，别无他法。又想拿高工资，又想很轻松拿是不可能的。总要付出一部分来获取另一部分 |
 |
14
stormpeach 2016-11-24 11:28:44 +08:00
我一般是乘以 3.。。。
刚开始做得给自己 50%的思考时间，想清楚了再写 |
|
15
lifesimple OP @stormpeach 是啊 很赞同后一点，不然返工浪费时间。
|
 |
16
skywayman 2016-11-24 11:55:05 +08:00
1. 从不相信业务和市场部门反馈的:该功能很简单;
2. 所谓报时靠谱其实是经验,就是过的坑够多了,这个很重要; 3. 遇"坑"不要一坐坐 1 天,交流,刷贴,上个 WC,也许坑就豁然开朗了. 4. 活着才有可能完成,死了是没有价值了,为了活着,需要*系数 |
 |
17
fan1234nm 2016-11-24 12:00:56 +08:00
单兵作战，一般都是 d*2+检测遗漏+buff ，基本都没出什么纰漏。
|
|
18
Miy4mori 2016-11-25 10:51:54 +08:00 via Android
功能点就需要产品和主程一起讨论了，毕竟有些功能点遇到外行产品是割裂的看的，实际业务是有纠缠的
|
Select Language