我们公司的流程是
评估市场需求→PM提案→设计师开规格→RD实作→QA→发布
实际上是什么开发流程我是不知道
网络上有看过离职的前辈说这是瀑布式
公司这几年又把一些敏捷的思想带进来...
说因为没有一个人神到可以设计出最终规格
所以产品要不断迭代 RD可以先做出一个成品给设计师看 跟设计师互相讨论
但矛盾的是 我们的产品上线时间很早就被敲定
所以大部分的专案 下场就是没有得到足够的迭代
最后不是砍规格 就是RD跟设计师一起加班赶进度
甚至还有上线两个月前规格才完成的状况
我也问过主管 这样迭代真的足够吗？ 主管只说：恩，公司要赚钱
PM最喜欢的就是预估时程 画满甘特图 预期最后有几个功能会完成
但最常见的状况就是规格大改(因为我们会迭代)
不然就是RD为了进度hard code才勉强满足进度
反正有问题就看谁倒楣谁修谁接手
RD大老虽然说要推行test 但是跟PM根本没有共识 专案进度也没有排入test撰写的闲暇
所以RD要不就是自愿加班写test 要不就是干脆不写 或是写一些无关紧要的test
我不知道是不是只有我们公司才这样
还是这是业界常态只是我太菜了
我是真的不太懂预估工时的意义到底在哪
工时预估准确 ─┬→ 可喜可贺
└→ 规格变更 ─→ 完成时间延长(然后叫你再估一次工时)
工时预估不准 ─┬→ RD逊砲，请重估
├→ RD报喜不报忧 留下技术债
└→ 规格变更 ─→ 完成时间延长(再估一次)
工时不管预估准不准确，都不能影响专案目前的进度以及实际上需要的时间
(实际需要的时间 大概只有神知道)
但预估工时反而会给PM“一切都在我的掌握之中 专案都在轨道上”的错觉
还是说我误解了预估工时的目的 有没有人可以指点一下？ 谢谢
作者:
b81314 (有点贵)
2019-07-24 17:14:00加油!
作者:
NDark (溺于黑暗)
2019-07-21 15:08:00先卡
作者: irvingray (TIR) 2019-07-21 15:20:00
真正落实敏捷也是种神话
作者:
rhox (天生反骨)
2019-07-21 15:22:00预估工时可以用来评估开出的规格是否可行
作者:
pttworld (批踢踢世界)
2019-07-21 15:29:00估工时是因为成本和报价，通常只有缩短
工时本来就是参考用阿...delay是正常的看那些游戏大作整天coming soon就知道了吧XD
作者:
art1 (人，原来不是人)
2019-07-21 16:00:00因为是用在管理上，高层就是看这些东西
敏捷一般常见的是fixed deadline, 但scope是变动的
http://bit.ly/30RFohr一般公司最大的误解就是time跟scope都不可变动那当然稳死的，这不是敏捷的问题，是滥用的问题还有一个大前提，签敏捷宣言的大神们，其实都是技术大神他们发现要解决人跟协作的问题，避免流程冗重浪费的问题所以用敏捷宣言来补上这一块，因为他们已经没啥技术问题现在搞敏捷的公司，技术跟工程基底能力普遍不足那根本敏捷不起来的，就像
http://bit.ly/30KC4nX"为什么 Scrum 害你们产能下降、品质低落、时程 delay"讲个结论，从你的描述看来，你公司只是把敏捷当银弹用跟人家在追求潮流词汇而已，但结果会比原本的瀑布还差
工程师能力不一跟对专案了解度不一 跑敏捷真的是会绝顶升天
恩，所以只是被“buzzword形式的agile”强暴了
工时是拿来让pm排开发功能的优先级一个功能复杂度13 另一个3 无相依 看pm是想先做13还是先做3的
作者: keyboard56 (奇伯) 2019-07-21 17:56:00
工时主要就用在管理 上面喜欢看到有在前进的感觉，二来就是报价用让上面知道要开发这个东西大约需要多少成本。但预估归预估实际上很难估得准，需求规格的不确定是主因，会压缩到后续相关的时程。
遇过很有趣的 工时不能估太长 太长的话强制拆成两个以上的排程 但根本就还没做也没确认规格
作者:
tx50xyz (想要好的房贷利率)
2019-07-21 21:28:00你能说不吗？工时估多一点，马上就说要这久，估少，你天天要加班加到死，估时程是对老板超有利的，反正工时开多老板会点头吗？跟本就是有依据让你加班不给加班费的
作者:
oopFoo (3d)
2019-07-21 21:48:00推landlord大
作者:
neo5277 (I am an agent of chaos)
2019-07-21 21:50:00通常压办年或是八个月上线然后会延两次
作者:
overhead (overhead)
2019-07-21 22:02:00你的抱怨超写实超有既是感哈哈哈
我遇过可能工程师里面那段只有一个人碰过 要其他人盲估的 这种我就觉得很微妙
作者:
molopo (mmm)
2019-07-22 03:08:00压久了 人都走光
作者: expup (linux) 2019-07-22 04:12:00
会问这个问题的估计是连预估都不会或常常预估错误但也不能怪妳啦因为预估时间这东西没人会教你
作者:
bndan (seed)
2019-07-22 08:22:00估工时 目前看到最经典的还是 公司老工程师估完新工程师承担 这种绝顶升天的程度不亚于实力或认知不同时实跑scrum
不估时程，谁知道大概做多久，盖个房子也要估时程阿，敏捷跟瀑布一样，前面需求分析架构做足，时程变动少，除非中间又更动到功能跟规格
作者:
WunoW (WunoW)
2019-07-22 09:17:00都说是估了，当然不会准啊
作者:
firtaily (firtaily)
2019-07-22 09:28:00跟小弟公司碰到的蛮像的 公司甚至sa跟pg是同步的 很常pg这边开发完了sa写出来发现不一样pg这又要再改
我们公司还发生新产品评估阶段 业务已经卖出去好几套
作者:
dong531 (猫王)
2019-07-22 10:55:001掌握进度避免无法如期交付而被罚钱2计算人力估价报价比如我现在的维护案，需求来了先评估人力、工时，然后回报这个需求需要多少人力做多久所以报价是多少，要做就开单不做就不开单
作者:
b6byc (oopp)
2019-07-22 17:48:00改动频率也太常了吧. 这个应该是规格沟通问题. 一直改啥方法都没用, 做一做, 反正还要改.压时间压久了, 受不了走人, 然后loop, 公司沉沦下去.
作者:
lordmi (星宿喵)
2019-07-22 18:00:00讲这么多，几个字就定义完了：陨石式开发
作者:
dancedolf (我想学paso><)
2019-07-22 21:29:00评估的时候 最好是能多花点时间 另外在评估之前 需求应该已经有至少八成的确定 如果推倒重来 那时间肯定要重估 返工肯定是往需求推如果需求连让你想像功能画流程图都不行 那就退货吧 另外需求通常都会比当前sprint 提早 最好还有人能够 review
作者: Tatum0119 (小赖) 2019-07-23 00:18:00
卡
估时间只能竟量估长0.0 有时候时间真的很难估*尽量
作者:
sa0124 ((恩恩))
2019-07-25 18:58:00这是好问题耶 但如果都不估时程 功能随意做做个一年 这样公司会倒吧 估时程主要还是让公司判断这个产品成本多少钱啊我们是工程师自己估，其实估久了真的就越来越准了，有时候发现自己估很准其实也蛮有成就感的XD
作者:
zased (我只是上PTT查资料)
2019-07-26 01:25:00这什么问题 RD看世界？你换个角色重新思考专案就知道预估工时的重要性，而且预估工时是RD的基本功...
作者: JingX 2019-07-28 09:16:00
RD自估最准 但高层一句"这么简单哪要这久你能力不足"就...