※ 引述《yukimatoi (缠)》之铭言：
: 工时预估准确 ─┬→ 可喜可贺
: └→ 规格变更 ─→ 完成时间延长(然后叫你再估一次工时)
: 工时预估不准 ─┬→ RD逊砲，请重估
: ├→ RD报喜不报忧 留下技术债
: └→ 规格变更 ─→ 完成时间延长(再估一次)
: 工时不管预估准不准确，都不能影响专案目前的进度以及实际上需要的时间
: (实际需要的时间 大概只有神知道)
: 但预估工时反而会给PM“一切都在我的掌握之中 专案都在轨道上”的错觉
: 还是说我误解了预估工时的目的 有没有人可以指点一下？ 谢谢
估计准不准,不同功力的工程师还是有差.
我记得我上次写过资深工程师的差异.就有提到这点.等等我再贴连结.
我换过 八间 大到几千人 小到十人的不同规模公司.
我甚至还写过游戏软件管理的文章.
原PO讲得这些问题都发生过.有些是制度文化问题.有些是工程师自己想太多.
很难概括而论.每间公司每个团队每个主管可能问题都不一样.
只能回归一句. 找适合自己"文化"的公司/团队/主管 很重要.
除此之外我只能分享我的经验.
我目前专案是上线专案.每个月要固定更新.也就是每个月都在压死线.
对我们来讲每个月就是一直重复 设计/估计时程/实作/测试/上架/更新.
一旦上架延迟,更新就会延迟. (因为苹果商城审核的时间不是我们能够控制的)
所以在这种环境下时程比规格重要.
一旦发生有危及时程的状况.就是砍规格. 宁愿少一个功能道具/不要延迟整个更新.
但是当然这种事情最好不要发现/发生太晚.要砍规格调整时程都已经来不及了.
(更新延迟在我一年半的观察以来还是发生过一次)
(每个月拼上架一年来只有一次不加班)
我目前直属主管跟专案主管都是蛮实际(practical)的印度人.
专案主管(PM)面试我的时候就谈过类似的问题,他是这样讲的:
"我宁愿你早点告诉我(做不到),不要放马后炮(说早告诉过你)"
直属主管(TD)在我反映这个议题上也直接明讲:
"如果你觉得要留测试*的时间,记得报时程的时候自己要抓缓冲(浮报)"
(补充:这边TD不能明讲一些灰色地带.留测试只是好听.
因为不懂开发的人会觉得实作就应该要高效能,应该要正确,
但是实务上一定会有做完了但是不满意的情况.
尤其是在表现上的功能,如动画,粒子特效,接口,甚至是接口流程.
如前述,我们的每个周期是约二十天,设计可能只有五天.
五天不是只设计一个东西.一个月可能是几十项.
很多功能就是丢一句话就要干了.
自然无法准确预估.但是经验还是让我可以估出一个可能要预留这些改来改去的时间
缓冲就是不要让管理层排出一个没有风险管理太理想的时程.
避免临时有状况,结果时程就爆炸要加班砍规格大家都不爽)
为什么我敢实话实说? (而原PO工程师朋友们老是担心报太多会黑?)
我研判是这样
因为我团队同职缺目前就配三个工程师(PG)就算刚好.
如果一个休长假,另外两个人还可以轮流请假.不会任何一天没PG开天窗.
然这个职缺新聘进来到理解7成功能能扛专案.要训练至少半年.
所以公司禁不起人离职.找人很难.人进来要半年才能回到三人效率.
所以对工程师都毕恭毕敬.(当然地位没有到横著走)
没有那种台湾职场常听到的名言:"后面能接替你工作的很多"
(公司大,想进来的是很多,但是专案的knowhow太多,每个人进来都得花时间慢慢搞懂)
给各位参考.