我们公司的流程是
评估市场需求→PM提案→设计师开规格→RD实作→QA→发布
实际上是什么开发流程我是不知道
网络上有看过离职的前辈说这是瀑布式
公司这几年又把一些敏捷的思想带进来...
说因为没有一个人神到可以设计出最终规格
所以产品要不断迭代 RD可以先做出一个成品给设计师看 跟设计师互相讨论
但矛盾的是 我们的产品上线时间很早就被敲定
所以大部分的专案 下场就是没有得到足够的迭代
最后不是砍规格 就是RD跟设计师一起加班赶进度
甚至还有上线两个月前规格才完成的状况
我也问过主管 这样迭代真的足够吗？ 主管只说：恩，公司要赚钱
PM最喜欢的就是预估时程 画满甘特图 预期最后有几个功能会完成
但最常见的状况就是规格大改(因为我们会迭代)
不然就是RD为了进度hard code才勉强满足进度
反正有问题就看谁倒楣谁修谁接手
RD大老虽然说要推行test 但是跟PM根本没有共识 专案进度也没有排入test撰写的闲暇
所以RD要不就是自愿加班写test 要不就是干脆不写 或是写一些无关紧要的test
我不知道是不是只有我们公司才这样
还是这是业界常态只是我太菜了
我是真的不太懂预估工时的意义到底在哪
工时预估准确 ─┬→ 可喜可贺
└→ 规格变更 ─→ 完成时间延长(然后叫你再估一次工时)
工时预估不准 ─┬→ RD逊砲，请重估
├→ RD报喜不报忧 留下技术债
└→ 规格变更 ─→ 完成时间延长(再估一次)
工时不管预估准不准确，都不能影响专案目前的进度以及实际上需要的时间
(实际需要的时间 大概只有神知道)
但预估工时反而会给PM“一切都在我的掌握之中 专案都在轨道上”的错觉
还是说我误解了预估工时的目的 有没有人可以指点一下？ 谢谢