1
VVVVVEX 2018-07-09 21:13:58 +08:00 1
所有人估计的时间加在一起,人少乘 3,人多乘 5。
|
2
guoyuchuan OP @VVVVVEX 啥意思啊?我们就两个人负责后台,一个前台,都是新手。
|
3
VVVVVEX 2018-07-09 21:24:45 +08:00 1
max(your_time, his_time) * 5
|
4
guoyuchuan OP @VVVVVEX 这也太夸张了吧
|
5
ebony0319 2018-07-09 21:27:16 +08:00 via Android 1
(最悲观+最乐观+4*最可能时间)/6
|
6
0044200420 2018-07-09 21:29:28 +08:00 1
产品和项目经理在哪
|
7
ebony0319 2018-07-09 21:30:22 +08:00 via Android 1
纯理论:自下而上评估。大意就是比如你要做饭,你需要想每一个子工作包所有时间。比如砍柴,生火,煮饭,炒每一道菜时间。
|
8
guoyuchuan OP @ebony0319 感觉晾凉了
|
9
guoyuchuan OP @0044200420 对不起,都没有,只有一个项目助理(画原型图的,还画得不好的那种)
|
10
wwek 2018-07-09 22:31:01 +08:00 1
把你需要做的事 分解出来。 用甘特图排出来。 然后再加点冗余时间
|
11
xpresslink 2018-07-09 22:36:14 +08:00 1
理论上说时间是无法估计的。
因为你没有做过同类型的项目,也没有非常好的实践基础,所以时间是完全不可控制的。 |
12
guoyuchuan OP |
13
mcfog 2018-07-10 07:28:18 +08:00 1
想到哪写到哪儿
1. “时间预估” 对于外包和公司自有项目的意义和含义是不一样的。前者是真的雷打不动的 deadline,而且基本不能以客户需求变更或其他意外为借口来打破,但后者相反,有合理的问题发生 delay 是正常的,但代价是绝对不能用乘法(至少我认为这属于不负责任) 个人没做过外包所以对外包的描述是瞎猜的,下面所有的看法都是基于公司自有项目 2. 时间预估之所以叫预估就是因为不准。实际上每个任务的完成时间都不是一个数字,而是一个概率模型( 30% 半天做完 40% 一天做完 25%两天做完 5% 需要更长时间)而你给出的那个实际的数字,一般应当是 80%左右能做完,10%左右稍微超一些时间 or 加班 能做完的一个预期时间 3. 一份好的时间预估中,任何一天以上的任务都是不被接受,需要进一步拆分的 4. 以月为单位的项目当中,用几天的时间来做技术文档,并最终给出详细的时间预估是合理且必要的,这样的项目中表结构都没有定,技术文档都没有,你就给我时间预估我是不信的 5. 如果你有技术 leader,可以和他直接沟通你的困难,包括技术的选型和时间预估的困难,另外你的时间预估必须和你的搭档核对,并且写清楚你们所有的配合的时间点,什么时候定公共的数据结构、你们内部的接口形式和字段,什么时候你们两部分可以联调等 6. 题外话,要不是看到下面的数字列表还算整齐,我看到第一行其实就有关窗口的冲动。重复 3 遍想表达什么?你用什么语言和项目时间预估也关系不大。 包括你后面 7 里面写的一堆,你以为会呛你一句风凉话让你离职的人会仔细看你写的那么多东西?或者是看了以后他们就会认真给建议了? 论坛里面的一些信息噪音当作没看到就好( V2EX 甚至有 block 功能),不要和他们战斗,更不要这样因为他们影响其他人的阅读体验,要不是有数字列表方便我扫一眼就跳过,我可能就跑了 |
15
947211232 2018-07-10 08:54:47 +08:00
这种事情当然是预留充足时间(时间不够你要么加班并且上级对你能力怀疑),前期不停的赶,先把主体弄出来再细化。
|
16
xiaoshan5733 2018-07-10 09:18:21 +08:00
所以是,两个做 java 的把整个项目都包了~ 现在做 java 的都这么牛逼了吗
|
17
micean 2018-07-10 09:45:07 +08:00
没有详细设计就没办法估计
|
18
guoyuchuan OP |