就是每次估计项目开发需要的时间，都不准，有时能相差千里。
讲真，大家怎么估计项目所需时间？
讲真，大家怎么估计项目所需时间？
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 2065 days ago, the information mentioned may be changed or developed.
 |
1
预计多久，往两倍计划，往三倍上报，最后批下来的时间折中一下 1.5 倍
|
1 |
2
你知道“天气预报方法”吗？只要你改变估计结果的频率够快，估计错误就追不上你，doge
|
 |
kiracyanMar 9, 2021
3
往大了说
|
 |
4
有种方法叫乘三升级 ，比如你觉得一天能完成，先乘三 在升一级，那就是三周
|
 |
flgn88Mar 9, 2021 via iPhone
5
不是叫测不准原理吗
|
 |
lithiumiiMar 9, 2021 via Android
6
心理学上叫 planning fallacy，计划谬误
|
 |
smart9527Mar 9, 2021
7
量子力学
|
 |
8
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. 今天在 InfoQ 读到的（滑稽
|
 |
JoooooooooMar 9, 2021
9
多读人月神话
|
 |
littlewingMar 9, 2021
10
@nuistzhou 买买提测不准原理
|
 |
11
多看量子力学，在项目还未完成时，如果能知道准确的完成时间，则具备了预测未来的能力，那为何要做项目，炒股票它不香吗？
|
 |
13
不太清楚估不准原理是怎么表述的，不过好在高中时候学过一点物理竞赛，我知道海森堡测不准原理。
海森堡测不准原理指的是，你永远无法同时测准一个微观粒子的位置和动量。你可以在一次测量中尽量保证位置的精度，也可以在一次测量中尽量保证动量的精度，但位置的精度和动量的精度乘起来是一个定值。这个定值就是普朗克常数除以 4π。 如果想仿照这个来表述一个架空的工程量估不准原理的话，我觉得可以这样表述：你目前手头上的工程，永远无法同时精确地知道你目前工程的进度和你目前正在做工程的速度。如果你能够更加精确地测定完成这项工程需要多少代码，你就会不知道你一天能写多少代码，如果你更精准地知道了你每天写多少代码，你就搞不明白你究竟还需要写多少代码才能完成这项工程。 这个理论符合实际吗？好像还有那么一点点味道？ |
 |
xiaoming1992Mar 9, 2021
14
@xmumiffy 估计一个月，乘三，三个月，升级，三年[狗头
|
 |
XuanFei990Mar 9, 2021
15
往多了估计，这不常规操作么，不管啥项目都适用
同类项目做多了多少有个大概时间，据以往经验。。 项目分配了一个任务，去年做的时候，我第一次做估计要 21 天，实际大概用 30 多天才差不多做完 有了以前的经验，弯路可以少走不少，如果高效去弄，大概 14 天差不多吧，但是我还是上班按照 24 天 然后即便是老板着急了，只给 15 天，我觉得也还是可以的，前期可以快速准确的做完，避免后期返工，压缩出来的时间在可控范围内，划划水，慢慢弄，在时间节点前后，完成就行了，省的干的太快，又安排其他任务。。。狗头 |
 |
16
一般至少预估时间乘以三
|
 |
18
粒子在测量之前没有一个确定的状态，只有在程序写完后，状态才确定
|
 |
xuanbgMar 9, 2021
19
我能说凭直觉吗？反正我直觉都很准，但往外说基本 x5 。因为我 3 天能写完的，别人真的要 3 周……
|
 |
murmurMar 9, 2021
20
直接*pi 特别不靠谱的*10pi 就是算上调试 维护 还有公司零散开销的成本
|
 |
SpiderXiantangMar 9, 2021
21
遇事不决 量子力学
|
 |
22
经验很重要。每个项目完成后都要回顾对比估算时间和实际花费时间，这样次数多了，误差就会越来越小。排除一些奇葩项目有不可预知的变更，按照 2/8 原则，起码大多数项目的估算还是可以掌控的。
|
 |
hugo54Mar 10, 2021
23
@SpiderXiantang 那没事了
|
 |
wnpllrzodiacMar 10, 2021 via Android
25
不放余量的？
|
 |
yuruizheMar 10, 2021 via iPhone
26
因为开发工程中总有千奇百怪的新坑，谁也说不准多久能解决
|
 |
daysvMar 10, 2021
27
还好吧， 我估时间一般都比较准， 但是产品喜欢在开发了一半的时候搞事情。
|
 |
falconeyeMar 10, 2021
28
按时间倒排，只保留本期的核心功能，确定搞不完的就放到下一期。
量小了，评估就能相对准确；有 deadline 就能确保核心功能和优先级；目标是能持续交付和快速迭代。 |
 |
liuzhaowei55Mar 10, 2021
29
@xmumiffy 我觉得乘 PI 就可以了，开发人员估时间的时候太太谦虚了。
|
 |
tiedanMar 10, 2021
31
个人而言，比较新的任务类型前几次估不准很正常，但是做了十次八次的几乎不存在估不准的情况。
|
 |
joshuacavellMar 10, 2021
32
遇事不决,量子力学.
|
 |
zlhsvcMar 10, 2021
33
一般往大了说 2 倍时间是保底，因为你不知道中间会出什么幺儿子
|
 |
wangkun025Mar 10, 2021
34
人的问题。
|
 |
35
需求明确 * 2
需求一看就不靠谱 * 4 |
 |
no1xsyzyMar 10, 2021
36
@falconeye 这个涉及到管理学领域的三难问题：时间限制（ Time ）、预算限制（ Budget ）、成果要求（ Specification ）三者很大程度上相关，但只要降低一个要求通常能够符合
（当然，人月神话否定了软件工程领域放开预算限制的作用，但影响不大，反正传统上就比较少地采用加预算） 似乎一个实例就是 Linux 分两条发布，稳定内核放弃成果要求，不一定要把所有这段时间内新添加的功能加进去，而最新内核没有固定发布时间。 |
 |
LaFayetteMar 10, 2021
37
我知道 海森堡测不准原理： 无法同时测得粒子的位置和速度.
|
 |
MaverickLeeMar 10, 2021
38
我知道买买提测不准原理：你无法同时得知一个 msl 携带的炸药量和他要引爆的地点。
|
 |
CodingNauxMar 10, 2021
39
领导恨不得把迭代周期排的满满，不给人留一点 buffer
所以得多估 = = |
|
CodingNauxMar 10, 2021
40
或者是这个需求匆忙进入迭代，之前没好好评审，没让开发做技术调研之类。赶鸭子上架
|
|
CodingNauxMar 10, 2021
41
开发估时太大，大概是产品流程出了问题，可能产品自己就没调研清楚需求，需求都没经过大家评审
开发这锅不背 |
 |
zhuweiyouMar 10, 2021
42
一般来说 我是乘 2~3 的时间 (因为最终会被压缩一些 加上其它项目可能并行)
千万不要"高估自己的速度" 如果是长期项目, 一般是分阶段进行, 比如第一期先完成哪些模块功能, 第二期再完成哪些 |
 |
HoshinokozoMar 10, 2021
43
有句话怎么说来着：
凡是你觉得可能会出错的地方，最后肯定会出错 再加上你觉得不会出错的，和你根本没想到的，最后完成的时间会大大超出预期 以我的经验： 心理非常有底的项目，按照完全不出错的时间*2 心理有底，但是具体细节不是很清楚的项目，按照完全不出错的时间*3 心理没啥底，只是知道大致的实现思路的，*4 心理完全没底的，那就随便报了，反正最后肯定要么多次调整，要么跑路。。[手动 Doge |
 |
titan2006Mar 10, 2021 via iPhone
45
量子力学不符合直觉与逻辑 是骗人的东西
|
 |
meepo3927Mar 11, 2021
46
估，经验比较重要
|
 |
zeromakeMar 11, 2021 via Android
47
我之前领导有个任务他设计的方案，然后让我做说啥二到三天，然后和他确认了好几次设计方案(一大把问题没考虑)，最后花了 7-8 天才差不多做完，就这他还要时常说那个设计没考虑到。还有一次让新人去处理一份代码改动，新人花了 2-3 天，还要说别人慢，我个人觉得还挺快的了，感觉他是在拿我和他自己在做对照。
|
Select Language