作者TonyQ (得理饶人)
看板Soft_Job
标题Re: [请益] 预估工时的意义在哪？
时间Wed Jul 24 09:01:15 2019
※ 引述《yukimatoi (缠)》之铭言：
: 我们公司的流程是
: 评估市场需求→PM提案→设计师开规格→RD实作→QA→发布
: 实际上是什麽开发流程我是不知道
: 网路上有看过离职的前辈说这是瀑布式
: 公司这几年又把一些敏捷的思想带进来...
: 说因为没有一个人神到可以设计出最终规格
: 所以产品要不断迭代 RD可以先做出一个成品给设计师看 跟设计师互相讨论
: 但矛盾的是 我们的产品上线时间很早就被敲定
: 所以大部分的专案 下场就是没有得到足够的迭代
: 最後不是砍规格 就是RD跟设计师一起加班赶进度
: 甚至还有上线两个月前规格才完成的状况
: 我也问过主管 这样迭代真的足够吗？ 主管只说：恩，公司要赚钱
: PM最喜欢的就是预估时程 画满甘特图 预期最後有几个功能会完成
: 但最常见的状况就是规格大改(因为我们会迭代)
: 不然就是RD为了进度hard code才勉强满足进度
: 反正有问题就看谁倒楣谁修谁接手
: RD大老虽然说要推行test 但是跟PM根本没有共识 专案进度也没有排入test撰写的闲暇
: 所以RD要不就是自愿加班写test 要不就是乾脆不写 或是写一些无关紧要的test
: 我不知道是不是只有我们公司才这样
: 还是这是业界常态只是我太菜了
: 我是真的不太懂预估工时的意义到底在哪
: 工时预估准确 ─┬→ 可喜可贺
: └→ 规格变更 ─→ 完成时间延长(然後叫你再估一次工时)
: 工时预估不准 ─┬→ RD逊炮，请重估
: ├→ RD报喜不报忧 留下技术债
: └→ 规格变更 ─→ 完成时间延长(再估一次)
: 工时不管预估准不准确，都不能影响专案目前的进度以及实际上需要的时间
: (实际需要的时间 大概只有神知道)
: 但预估工时反而会给PM「一切都在我的掌握之中 专案都在轨道上」的错觉
: 还是说我误解了预估工时的目的 有没有人可以指点一下？ 谢谢
这问题要看你从哪个角度来看,
基本上你是 PG / SA / PM / sales / Manager 角度都不一样.
PG: 预估工时是为了估算自己的价值跟确保自己的产能顺利不受干扰
SA: 预估工时是为了协调系统跟系统间界接,
确保对接的 frame 最小跟架构调整最适合
PM: 预估工时是为了确认业务单位(user side) 跟市场需求的满足程度
SALES: 什麽时候可以开记者会(敲碗)
Manager: 用来评估 Cost & Resource 是否合理.
但请记得, 上面的其中没有任何一点是为了[增进产品的品质] .
Product Quality 跟时间永远是带点矛盾的事情.
这就跟差勤或打卡纪录或工作日报一样, 本身是多做的虚工,
但却为了组织的协调跟因为不存在上帝视角, 所以不得不存在的产物.
另外所有专案的成败跟专案是不是正确的,
都应该有个 product owner 要为其负责. 谁做决定, 谁扛责.
如果负责人没有话事权, 那就不会有稳定的专案.
不管你觉得自己是什麽式,
没有脑袋清楚的人掌握产品线, 最後产品就会什麽都不是.
我管 team , 我手上的时程有两种,
一种叫真的, 一种叫假的.
假的并不是说我估的不准, 而是只要有更重要的事情进来, 他就会被推後.
真的是时候到了没做好, 那美克星就会毁灭.
(虽然毁灭那美克星的那前五分钟通常会特别久,
但那肯定不是我们时程估的不准, 而是编剧想拖戏.(喂) )
我待过很多间公司, 不是公司想做好, 产品就会做好,
也不是有钱的公司就会做好,
这题本质重点还是在带队的人脑袋清不清醒.......
而且一间公司至少要有三只柱子是清醒的,
一个是 leader 不能昏庸, 一个是开发端架构规划不能蠢,
最後一个是 user 不能只想把责任丢给开发端.
pm 我倒不是非常看重,
多数情况下 pm 就是协助角色, 不是真正决定的角色.
这三个只要有一个不行, 基本上不用撑, 能闪多远走多远,
不然就自己站到这三只脚的其中一只脚去, 至少是自食恶果.
毕竟, 你面对生锈报废的引擎的时候,
不会去考虑你该拿螺丝起子还是六角板手吧?
换个新的引擎才是真的.
方法论只是方法论, 人才是执行方法论的主体,
错误的人的环境长不出什麽漂亮的花朵.
--
I have a dream, it's silly but beautiful.
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 61.231.21.72 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1563930077.A.0DF.html
※ 编辑: TonyQ (61.231.21.72 台湾), 07/24/2019 09:04:33
※ 编辑: TonyQ (61.231.21.72 台湾), 07/24/2019 09:07:14
1F：→ pttworld: sales拿到PM预估的工时是要换算後报价给客户的 07/24 09:12
2F：→ MOONY135: 三本柱 07/24 09:13
3F：→ pttworld: 正规的专案公司还有养PM Team, 怎麽可能只有协助 07/24 09:15
4F：→ benqm300: 人柱力 07/24 09:20
5F：→ pttworld: 这篇一看就知道没当过专案经理，你说的时程就是 07/24 09:24
6F：→ pttworld: 你的头衔不是专案经理是因为不是专案公司 07/24 09:25
看不懂你在讲什麽，先组织组织再回吧。
7F：推 jack0204: 是不是要先抓一只神兽封印在身上才能当柱子? 07/24 09:29
那个叫祭品，不是柱子喔。QQ
8F：推 xam: 这篇就技术base的PM+PL啊, 我支持.. 07/24 09:46
9F：→ ckp4131025: 第三根柱子是user? 07/24 10:21
这里我讲的 user 比较算是企划或是负责需提供求的角色，有所节制的 user 是很重要的。
10F：推 ime5566: 原来是Tonyq 07/24 10:39
11F：→ fgh81113: 架构规划已经倒了 还有没有救... 07/24 10:41
理论上其实要把架构做倒但公司不倒，还满难得，通常的情况是人倒了而不是架构倒了。
12F：推 massrelay: 蛮认同，不过还是需要PM帮忙盯不然容易漏东西。 07/24 10:53
这篇是在谈时程预估对专案管理的影响，如果谈专案本身的管理要补的也不是这三言两语而已。
※ 编辑: TonyQ (223.137.92.174 台湾), 07/24/2019 11:03:44
※ 编辑: TonyQ (223.137.92.174 台湾), 07/24/2019 11:04:18
※ 编辑: TonyQ (223.137.92.174 台湾), 07/24/2019 11:04:39
※ 编辑: TonyQ (223.137.92.174 台湾), 07/24/2019 11:08:48
※ 编辑: TonyQ (223.137.92.174 台湾), 07/24/2019 11:12:39
13F：→ Feis: 不认同，预估工时跟品质当然有关 07/24 12:15
广义来说，所有事情都跟结果有关，员工家庭生活是否和谐都会跟品质有关。
但实际上还是有些更核心的事情要探讨。举例，如果没有人钉时程，那时程就会形同虚设。
这种情况下他对专案影响就不会太大。
又举例，老板是个 asshole 整天叫你用一天做一个月的事情，你就会觉得预估时间真是问题的根源。
但真正的问题并不是预估时间本身，而是权力怎麽被挥舞跟决策怎麽形成。
你越认为预估时间重要，他对你来说的伤害就越重要。
我的风格比较算是价值管理，每个东西的时间是分级的，有些时间重要，有些时间不重要。
会觉得预估时间对品质重要的，实质上是因为环境把权力寄生在无辜的预估时间上而已。
另外预估时间对改善品质，我还是要强调，我认为没有帮助。
14F：→ lnmlee: 预估工时就是预计时间成本 讲那麽多平行世界要尬嘛？ 07/24 12:40
※ 编辑: TonyQ (223.137.92.174 台湾), 07/24/2019 12:54:52
15F：推 banana13: pm就是为了给老板交代产出产品，pg就是被要求使命必达 07/24 12:57
16F：→ banana13: 达不到就加班 07/24 12:57
17F：→ Feis: 如果连明天能不能上架都无法预估，真不知道怎麽做专案… 07/24 13:12
假设是正常的专案流程，到上架之前至少有六次的预估跟检核要做。
如果你跳过所有的检核，直接到上架前一天才来倚赖预估，我想是真的不知道要怎麽做专案没错。
没有准确的预估，不代表你放弃 QA 放弃 review ，放弃所有确认专案目前状态的手段好吗？
18F：→ Feis: 见识太少，尊重你的看法 07/24 13:14
不是不预估，而是估不准不会死。
※ 编辑: TonyQ (223.137.92.174 台湾), 07/24/2019 13:29:25
※ 编辑: TonyQ (223.137.92.174 台湾), 07/24/2019 13:31:23
19F：推 ian90911: 中肯推 07/24 14:49
20F：推 hakama99: 推 07/24 15:28
21F：推 mathrew: 理想总是美好的 07/24 16:26
22F：推 menesn: 感谢分享 07/24 17:31
23F：推 SuperCry: 一直想到陈绮贞的歌 07/24 19:10
24F：推 gmoz: 扳手 不是板手QQ 07/24 22:22
25F：→ gmoz: 最近靠北乐团才在吵这个(X 07/24 22:23
26F：推 Feis: 「预估时间对品质，我认为没有帮助」这中文理解有障碍 07/24 22:27
27F：→ Feis: 我有说要放弃其他方法吗 07/24 22:27
28F：→ Feis: 我只是不认同没帮助这件事，没帮助还是要做，所以就是有帮助 07/24 22:28
29F：→ Feis: 呀 07/24 22:28
30F：→ Feis: 这逻辑…… 07/24 22:28
31F：→ Feis: 软体专案以人为本，预估时间也是个工具，政治手段也是个工 07/24 22:31
32F：→ Feis: 具，不要以偏概全 07/24 22:31
33F：→ Feis: 抱歉，一开始就不应该回应… 07/24 22:34
你每天过马路要看红绿灯，这是个要做的事情。
他对你的帮助叫做保护你的安全。而不是让你赚大钱。
当然你可以说你被撞死了就不能赚大钱，定义上不会有错，但他毕竟不是直接相关。
同理，预估工时只是个概估的基准，他让你的团队心里有个底。
但这个底跟品质没关系。
要说的话，顶多只跟这件事情能不能被完成有关，但能不能被完成跟品质好不好是两码子事。
34F：→ thund: 没帮助还是要做=有帮助 这等式不成立吧 07/25 00:32
35F：→ Feis: 是的，我们都在做没帮助的事。我猜原作者的论点不是这方向 07/25 00:36
36F：→ Feis: 我原本的认知是要透过测试稽核之类的去决定状态 07/25 00:38
37F：→ Feis: 而测试稽核不是建立在预估工时上是我原本以为的论点 07/25 00:39
38F：→ Feis: 我自己的论点是，短期的预估工时是无可避免的 07/25 00:40
39F：→ Feis: 而预估工时是个工具，工具有好有坏，有用对有用错 07/25 00:41
我不太理解为什麽对品质没帮助等於不需要做的事情。
专案中多的是对品质没帮助，但需要做的事情。
比方说砍功能或在功能未完成时，提早上线，就是个牺牲品质来成就市场的手段。
品质不是一切啊。
40F：→ thund: 本篇也没说要放弃预估工时啊 只是说对品质没有帮助 07/25 00:42
41F：→ thund: 重点是在更上层的问题 而不是预估工时这件事的好坏 07/25 00:43
42F：→ Feis: 了解，所以现在主题变成为什麽要做没帮助的事 ? 07/25 00:43
43F：→ thund: 没啥毛病啊 07/25 00:43
44F：→ Feis: 是吗？如果完全没办法预估工时，你怎麽决定什麽时候稽核? 07/25 00:44
不管我我预估多久，我还是可以每周稽核啊。
45F：→ thund: 喔 我的天 我看是你理解有问题....... 07/25 00:46
46F：→ Feis: 我能理解有更上层的问题，但是这篇的意思就是『预估时间对 07/25 00:46
47F：→ Feis: 品质没有帮助』 07/25 00:46
48F：→ Feis: 可以指教一下吗？ 07/25 00:46
49F：→ Feis: 我只是对这点表达不认同 07/25 00:47
50F：→ Feis: 『估不准不会死』我也认同，要估六次十次我也认同 07/25 00:57
51F：→ Feis: 那结论不就是要嘛做这些事与品质无关要嘛有关 07/25 00:58
52F：→ Feis: 原作者论点是『无关』，但我无法认同而已 07/25 00:58
53F：→ Feis: 抱歉纠正，是有没有帮助 07/25 00:58
54F：→ Feis: 如果『没有帮助』却又要『做』的逻辑是什麽，需要有人指导我 07/25 00:59
55F：→ Feis: 我想表达的是工具本身是中性的，使用工具的人才是问题 07/25 01:05
56F：→ Feis: 不要因为人的问题就去说工具没有用 07/25 01:05
我没说他没用，只是他的用途不是提高品质。
57F：→ Feis: 而工具有学习成本有使用风险，这些都是专案管理要考量的 07/25 01:08
58F：→ Feis: 挑适合的工具给适合的团队创造适合的文化 07/25 01:28
59F：→ Feis: 才是专案管理者该走的路跟价值 (当然是我自以为 07/25 01:31
60F：推 bakedgrass: 不太明白User不能把责任都丢给开发端是甚麽意思？ 07/25 02:16
61F：→ bakedgrass: 是指User必须试着适应开发出来的软体？ 07/25 02:16
62F：→ bakedgrass: 一般说来User不会是开发团队可以掌握的因素吧 07/25 02:17
这里的 user 基本上是企划或是自认为自己是 user 代表的人。
举例，明明就是个 toto list ， user 要求系统要能看客户的行事历猜到他要干嘛帮他写 todo 就是个 over kill 的要求。
很多时候他们会跳入提供更多功能，而不是解决问题的陷阱里面。
63F：推 zombiesky: To Feis, 人活着需要氧气和食物,氧气和饱足无关,但没有 07/25 08:14
64F：→ zombiesky: 氧气会死, 所以还是要氧气 07/25 08:15
65F：→ zombiesky: 专案管理要顾的不是只有品质,预估时程的目的不是提升品 07/25 08:17
66F：→ zombiesky: 质,但有其他作用,本文有提到 07/25 08:18
67F：推 zombiesky: To Bakedgrass,前面TonyQ有回应,这里的User指的是代表 07/25 08:21
68F：→ zombiesky: User的人,ex. Product Owner 07/25 08:21
69F：推 ku399999: ...开宗明义不是就讲估工时的功能了吗 07/25 08:36
70F：推 jjwei: push 07/25 08:37
71F：推 bakedgrass: 看到了，谢谢zombiesky 07/25 08:46
72F：→ Feis: 了解，可能是大家对品质的定义不同。可能是我误解，谢谢 07/25 09:08
73F：→ Feis: 没有氧气会死，所以饱足跟氧气无关。可能是这逻辑我误会了 07/25 09:10
74F：→ Feis: 我原本以为是不需要预估时程也可以确保品质。 07/25 09:10
的确是不需要准确的预估工时也能确保品质，准确的预估工时实际上是跨团队合作才需要的东西。你跨的团队越多他准确性越重要。
但他实际上是个政治工具，而不是品质工具。
就算你能把时间都估到神准，还是不会让产品变厉害，要让品质变好需要的是别的东西，例如正确的规划跟品管。
时间是品质的劣化指标，加入对时间的要求都很难避免对品质的负面影响。
(但我的意思并不是因为这样就不要求时间，而是要留意到赶工跟品质的取舍。)
75F：→ Feis: 每个人对专案品质的定义不同，打扰大家了 QQ 07/25 09:11
76F：→ DrTech: 这根公司产品性质强相关吧。有些工时估不准，或随意延後。 07/25 09:16
77F：→ DrTech: 公司会被罚钜额的。 07/25 09:16
78F：→ DrTech: 某些产业或环境，乱估工时真的是会没工作的。要看环境。 07/25 09:18
但那是环境给他的限制，而不是预估工时本身的需求。
※ 编辑: TonyQ (223.137.92.174 台湾), 07/25/2019 09:28:25
※ 编辑: TonyQ (223.137.92.174 台湾), 07/25/2019 09:30:06
※ 编辑: TonyQ (223.137.92.174 台湾), 07/25/2019 09:31:02
※ 编辑: TonyQ (223.137.92.174 台湾), 07/25/2019 09:31:39
※ 编辑: TonyQ (223.137.92.174 台湾), 07/25/2019 09:32:13
※ 编辑: TonyQ (223.137.92.174 台湾), 07/25/2019 09:34:47
※ 编辑: TonyQ (223.137.92.174 台湾), 07/25/2019 09:39:19
79F：→ Feis: 所以规划不需要预估时间的意思吗，我越来越混乱XD 当然不用 07/25 09:50
80F：→ Feis: 神准 07/25 09:50
我从来没说不需要预估时间, 这应该是我第三次强调了,
我说的是预估时间不会提升品质.
是你要加上[不会提升品质的就不用做]的前提才会解读成这样.
81F：→ Jockey66666: 上述的规划应该是指产品设计面上的规划, 不包含时间 07/25 10:03
82F：→ Feis: 照这意思是产品设计时不考虑做不做得完，那我就完全理解了 07/25 10:05
83F：→ Feis: 感恩 07/25 10:05
你只做做得完的事情跟品质提升有什麽关系?
通常就是因为你只做做得完的事情品质才会下降啊.
[品质]不是专案的唯一指标, 更多的时候我们是不考虑品质的再进行专案,
我是觉得你把[品质]跟[完成专案]这两个词弄混了.
※ 编辑: TonyQ (61.231.35.153 台湾), 07/25/2019 10:10:17
84F：推 bakedgrass: 谢谢解释 07/25 10:12
85F：→ Feis: 我没误会，我以为品质是建立在有做完产品的前提 07/25 10:14
我认为完成产品是完成产品, 品质是品质.
不然在你这定义底下的 [完成产品], 会很容易变成被情绪勒索的基础,
任何人只要试着透过政治力加需求让你无法完成, 就可以靠北你品质很烂了.
在这样基础上你在技术上的攻防会花非常多的时间, 在处理需求的进出.
品质跟完成还是独立线, 才是比较适合的评估工具.
通常我都会说, 你想要改善专案品质我明白,
但你改善品质的手段过头专案就会无法完成.
所以我说, 预估时间是个政治问题, 不是品质工具.
※ 编辑: TonyQ (61.231.35.153 台湾), 07/25/2019 10:17:50
86F：→ Feis: 是我误解品质，抱歉 07/25 10:14
87F：→ Feis: 这产品品质很好只是没做完，我以为这不是前提的 07/25 10:16
所以现实上才会有砍产品品质要素, 来加速上线的手段啊.
完成专案也是重要的, 只是完成专案本身也不是一个品质指标,
为了让专案完成本身并不会提高体验, 也不会让产品更好.
没人说你要只顾品质而不让专案完成.
只是讲清楚专案完成跟品质一点屁关系也没有.
※ 编辑: TonyQ (61.231.35.153 台湾), 07/25/2019 10:20:49
88F：→ Feis: 我不觉得独立比较好，不过尊重你论点 07/25 10:20
89F：→ Feis: 加速上市不一定要牺牲品质 07/25 10:20
我说有 (牺牲品质(P) -> 加速上市(Q) 的手段) 是基於这样的目的.
你要跟我说有 加速上市 Q -> 非P (不用牺牲品质),
这两个不是冲突的好吗......
我说的是在某些时候我们会选择牺牲品质来加速上市,
并不等於我说所有的加速上市都是牺牲品质.....
如果你连这麽基本的理则学都没办法想清楚再回,
我会建议你, 先再想一想.......
不然你会一直搞不懂别人再回什麽.
※ 编辑: TonyQ (61.231.35.153 台湾), 07/25/2019 10:23:13
90F：→ Feis: 不过还是回到品质的定义问题，是我误会。 07/25 10:21
※ 编辑: TonyQ (61.231.35.153 台湾), 07/25/2019 10:23:58
91F：→ Feis: 了解，我那句并不是要否定。抱歉 07/25 10:24
92F：→ pttworld: 预估工时的时候就要把品质预估进去 07/25 10:24
那你预估工时的时候,
要不要把明天会发生七级大地震的风险也估进去.
※ 编辑: TonyQ (61.231.35.153 台湾), 07/25/2019 10:25:31
93F：→ pttworld: 估出来的工时就是品质预测後所定的时程 07/25 10:26
94F：→ pttworld: 你所谓的品质也是你预测做出来会是怎样的 07/25 10:27
95F：→ pttworld: 时程3个人月和6个人月，做出来的品质本来心里就要有底 07/25 10:32
96F：→ pttworld: 开发中期review後发现要tune, 要看有没buffer可以用 07/25 10:40
97F：→ pttworld: 这个buffer也是当初预估工时就要留的 07/25 10:41
这串在讨论的就是预估过程中产生的变化, 导致原本的估计是异常的,
在这样的前提下在探讨预估的价值.
不会变动的或可预测的, 自然不会有这种问题.
※ 编辑: TonyQ (61.231.35.153 台湾), 07/25/2019 11:06:07
98F：推 yahuichang: 一般要做一年案子，前家公司总经理要求三个月上线，理 07/25 11:32
99F：→ yahuichang: 由是要让业务员早点使用，这也是我有有史以加班破表， 07/25 11:32
100F：→ yahuichang: 当然上线品质不佳，假日被on call。 07/25 11:32
101F：推 Arctica: 认同估工时就只是个政治工具，通常就是为估而估，搞到最 07/25 11:37
102F：→ Arctica: 後还是会有对内对外两套工时.... 07/25 11:37
103F：推 yahuichang: 我那是完全没估，PM应当手上有多少资源，排出工期工时 07/25 11:42
104F：→ yahuichang: ，只会压时程。 07/25 11:42
105F：推 strlen: 没错！一堆方法 人不配合 还是搞不出什麽毛 人才是最大的 07/25 13:54
106F：→ strlen: 变因 其实也差不多什唯一严重的变因 07/25 13:54
107F：推 vencil: 推这篇 07/25 16:11
108F：→ umum29: 我在国外看到的PM是真的可以主导产品走向的要角 07/26 03:00
其实职称是假的，重点是他被赋予的职责才是真的。我在美国也待了一年，国外没比较厉害，重点还是在不同角色之间的彼此妥协。
※ 编辑: TonyQ (223.137.92.174 台湾), 07/26/2019 08:10:11
109F：推 DirtyVegas: 推 07/28 23:33
110F：推 justbecause0: 推 跟我看的的状况比较吻合 07/29 08:31
111F：推 masan22305: 认同Tony大观点，不过很清楚的看到PG跟PM所认定的品 08/15 09:19
112F：→ masan22305: 质不同 科科 08/15 09:19