作者yukimatoi (缠)
看板Soft_Job
标题[请益] 预估工时的意义在哪？
时间Sun Jul 21 15:01:55 2019
我们公司的流程是
评估市场需求→PM提案→设计师开规格→RD实作→QA→发布
实际上是什麽开发流程我是不知道
网路上有看过离职的前辈说这是瀑布式
公司这几年又把一些敏捷的思想带进来...
说因为没有一个人神到可以设计出最终规格
所以产品要不断迭代 RD可以先做出一个成品给设计师看 跟设计师互相讨论
但矛盾的是 我们的产品上线时间很早就被敲定
所以大部分的专案 下场就是没有得到足够的迭代
最後不是砍规格 就是RD跟设计师一起加班赶进度
甚至还有上线两个月前规格才完成的状况
我也问过主管 这样迭代真的足够吗？ 主管只说：恩，公司要赚钱
PM最喜欢的就是预估时程 画满甘特图 预期最後有几个功能会完成
但最常见的状况就是规格大改(因为我们会迭代)
不然就是RD为了进度hard code才勉强满足进度
反正有问题就看谁倒楣谁修谁接手
RD大老虽然说要推行test 但是跟PM根本没有共识 专案进度也没有排入test撰写的闲暇
所以RD要不就是自愿加班写test 要不就是乾脆不写 或是写一些无关紧要的test
我不知道是不是只有我们公司才这样
还是这是业界常态只是我太菜了
我是真的不太懂预估工时的意义到底在哪
工时预估准确 ─┬→ 可喜可贺
└→ 规格变更 ─→ 完成时间延长(然後叫你再估一次工时)
工时预估不准 ─┬→ RD逊炮，请重估
├→ RD报喜不报忧 留下技术债
└→ 规格变更 ─→ 完成时间延长(再估一次)
工时不管预估准不准确，都不能影响专案目前的进度以及实际上需要的时间
(实际需要的时间 大概只有神知道)
但预估工时反而会给PM「一切都在我的掌握之中 专案都在轨道上」的错觉
还是说我误解了预估工时的目的 有没有人可以指点一下？ 谢谢
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.163.98.5 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1563692517.A.FF3.html
1F：→ NDark: 先卡 07/21 15:08
2F：→ MOONY135: 工时就是用来delay的 （误 07/21 15:20
3F：推 irvingray: 真正落实敏捷也是种神话 07/21 15:20
4F：推 rhox: 预估工时可以用来评估开出的规格是否可行 07/21 15:22
5F：→ pttworld: 估工时是因为成本和报价，通常只有缩短 07/21 15:29
6F：推 abccbaandy: 工时本来就是参考用阿...delay是正常的 07/21 15:38
7F：→ abccbaandy: 看那些游戏大作整天coming soon就知道了吧XD 07/21 15:39
8F：推 art1: 因为是用在管理上，高层就是看这些东西 07/21 16:00
9F：→ fgh81113: 工时就是拿来压榨你用的 做不出来你的问题 07/21 16:00
10F：推 anandydy529: 就是一个半套的工作流搞的程式很爆炸 07/21 16:21
11F：→ landlord: 敏捷一般常见的是fixed deadline, 但scope是变动的 07/21 16:44
13F：→ landlord: 一般公司最大的误解就是time跟scope都不可变动 07/21 16:45
14F：→ landlord: 那当然稳死的，这不是敏捷的问题，是滥用的问题 07/21 16:45
15F：→ landlord: 还有一个大前提，签敏捷宣言的大神们，其实都是技术大神 07/21 16:46
16F：→ landlord: 他们发现要解决人跟协作的问题，避免流程冗重浪费的问题 07/21 16:47
17F：→ landlord: 所以用敏捷宣言来补上这一块，因为他们已经没啥技术问题 07/21 16:47
18F：→ landlord: 现在搞敏捷的公司，技术跟工程基底能力普遍不足 07/21 16:47
20F：→ landlord: "为什麽 Scrum 害你们产能下降、品质低落、时程 delay" 07/21 16:49
21F：→ landlord: 讲个结论，从你的描述看来，你公司只是把敏捷当银弹用 07/21 16:50
22F：→ landlord: 跟人家在追求潮流词汇而已，但结果会比原本的瀑布还差 07/21 16:50
实际上我们公司的规格也几乎都是口传 文件只是当参考注记用 没有common lang
更没有什麽user story的概念 或sprint的名词
只是一直讲产品要迭代 规格会改 进到QA後规格调整功能追加也是常态
※ 编辑: yukimatoi (1.163.98.5 台湾), 07/21/2019 16:54:41
23F：→ MOONY135: 工程师能力不一跟对专案了解度不一 跑敏捷真的是会绝顶 07/21 16:56
24F：→ MOONY135: 昇天 07/21 16:56
25F：→ landlord: 恩，所以只是被「buzzword形式的agile」强暴了 07/21 16:56
26F：→ JingJing00: 工时是拿来让pm排开发功能的优先顺序 07/21 17:47
27F：→ JingJing00: 一个功能复杂度13 另一个3 无相依 看pm是想先做13还是 07/21 17:48
28F：→ JingJing00: 先做3的 07/21 17:48
29F：→ keyboard56: 工时主要就用在管理 上面喜欢看到有在前进的感觉，二 07/21 17:56
30F：→ keyboard56: 来就是报价用让上面知道要开发这个东西大约需要多少 07/21 17:56
31F：→ keyboard56: 成本。但预估归预估实际上很难估得准，需求规格的不确 07/21 17:56
32F：→ keyboard56: 定是主因，会压缩到後续相关的时程。 07/21 17:56
33F：→ SimonAllen: 敏捷只做半套就是在压榨工程人员.. 07/21 18:07
34F：推 TheOneisNEO: 遇过很有趣的 工时不能估太长 太长的话强制拆成两个 07/21 20:27
35F：→ TheOneisNEO: 以上的排程 但根本就还没做也没确认规格 07/21 20:28
36F：→ MOONY135: 楼上那个我遇过喔 07/21 20:39
37F：嘘 tx50xyz: 你能说不吗？工时估多一点，马上就说要这久，估少，你天 07/21 21:28
38F：→ tx50xyz: 天要加班加到死，估时程是对老板超有利的，反正工时开多 07/21 21:28
39F：→ tx50xyz: 老板会点头吗？跟本就是有依据让你加班不给加班费的 07/21 21:28
40F：推 oopFoo: 推landlord大 07/21 21:48
41F：推 anandydy529: 我也遇过只有一句话就要你估工时的，估完还不能改 07/21 21:49
42F：→ neo5277: 通常压办年或是八个月上线然後会延两次 07/21 21:50
43F：推 overhead: 你的抱怨超写实超有既是感哈哈哈 07/21 22:02
44F：→ MOONY135: 我遇过可能工程师里面那段只有一个人碰过 要其他人盲估 07/21 23:36
45F：→ MOONY135: 的 这种我就觉得很微妙 07/21 23:36
46F：推 molopo: 压久了 人都走光 07/22 03:08
47F：推 expup: 会问这个问题的估计是连预估都不会或常常预估错误 07/22 04:12
48F：→ expup: 但也不能怪你啦因为预估时间这东西没人会教你 07/22 04:13
49F：→ bndan: 估工时 目前看到最经典的还是 公司老工程师估完新工程师承 07/22 08:22
50F：→ bndan: 担 这种绝顶升天的程度不亚於实力或认知不同时实跑scrum 07/22 08:22
51F：推 doranako: 不估时程，谁知道大概做多久，盖个房子也要估时程阿， 07/22 09:07
52F：→ doranako: 敏捷跟瀑布一样，前面需求分析架构做足，时程变动少， 07/22 09:07
53F：→ doranako: 除非中间又更动到功能跟规格 07/22 09:07
我们就是三餐在改啊
54F：→ WunoW: 都说是估了，当然不会准啊 07/22 09:17
※ 编辑: yukimatoi (1.163.98.5 台湾), 07/22/2019 09:25:33
55F：→ firtaily: 跟小弟公司碰到的蛮像的 公司甚至sa跟pg是同步的 很常pg 07/22 09:28
56F：→ firtaily: 这边开发完了sa写出来发现不一样pg这又要再改 07/22 09:28
57F：推 hakama99: 我们公司还发生新产品评估阶段 业务已经卖出去好几套 07/22 10:24
58F：推 dong531: 1掌握进度避免无法如期交付而被罚钱 07/22 10:55
59F：→ dong531: 2计算人力估价报价 07/22 10:56
60F：→ dong531: 比如我现在的维护案，需求来了先评估人力、工时，然後回 07/22 10:56
61F：→ dong531: 报这个需求需要多少人力做多久所以报价是多少，要做就开 07/22 10:56
62F：→ dong531: 单不做就不开单 07/22 10:56
63F：推 sirius65482: 简单啦 预估完的时间全部乘以1.5 这样就准多惹 07/22 12:37
64F：推 b6byc: 改动频率也太常了吧. 这个应该是规格沟通问题. 一直改啥 07/22 17:48
65F：→ b6byc: 方法都没用, 做一做, 反正还要改. 07/22 17:49
66F：→ b6byc: 压时间压久了, 受不了走人, 然後loop, 公司沉沦下去. 07/22 17:50
67F：推 lordmi: 讲这麽多，几个字就定义完了：陨石式开发 07/22 18:00
68F：→ dancedolf: 评估的时候 最好是能多花点时间 另外在评估之前 需求 07/22 21:29
69F：→ dancedolf: 应该已经有至少八成的确定 如果推倒重来 那时间肯定要 07/22 21:29
70F：→ dancedolf: 重估 返工肯定是往需求推 07/22 21:29
71F：→ dancedolf: 如果需求连让你想像功能画流程图都不行 那就退货吧 另 07/22 21:31
72F：→ dancedolf: 外需求通常都会比当前sprint 提早 最好还有人能够 rev 07/22 21:31
73F：→ dancedolf: iew 07/22 21:31
74F：→ viper9709: 推同感~有一样的疑问+1 07/22 22:14
75F：推 Tatum0119: 卡 07/23 00:18
76F：推 shooter555: 估时间只能竟量估长0.0 有时候时间真的很难估 07/23 10:55
77F：→ shooter555: *尽量 07/23 10:56
78F：嘘 b81314: 加油! 07/24 17:14
79F：推 sa0124: 这是好问题耶 但如果都不估时程 功能随意做做个一年 这样 07/25 18:58
80F：→ sa0124: 公司会倒吧 估时程主要还是让公司判断这个产品成本多少钱 07/25 18:58
81F：→ sa0124: 啊 07/25 18:58
82F：→ sa0124: 我们是工程师自己估，其实估久了真的就越来越准了，有时 07/25 19:00
83F：→ sa0124: 候发现自己估很准其实也蛮有成就感的XD 07/25 19:00
84F：推 zased: 这什麽问题 RD看世界？你换个角色重新思考专案就知道预估工 07/26 01:25
85F：→ zased: 时的重要性，而且预估工时是RD的基本功... 07/26 01:25
86F：推 JingX: RD自估最准 但高层一句"这麽简单哪要这久你能力不足"就... 07/28 09:16