※ 引述《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 就是协助角色, 不是真正决定的角色.
这三个只要有一个不行, 基本上不用撑, 能闪多远走多远,
不然就自己站到这三只脚的其中一只脚去, 至少是自食恶果.
毕竟, 你面对生锈报废的引擎的时候,
不会去考虑你该拿螺丝起子还是六角板手吧?
换个新的引擎才是真的.
方法论只是方法论, 人才是执行方法论的主体,
错误的人的环境长不出什么漂亮的花朵.