※ 引述《purin88 (原来我是愤怒的乡民)》之铭言：
: 唉，但工时估太短，就造成我不停的加班追进度，没有六日、没有晚上
: 请问我该怎么办？
: 还有更好的solution吗？
提供我自己的一点观感，
其实估工时都是屁，工时基本上不可能估的准。
国外有流行一套不估工时的作法，你可以去google "no estimates agile"
如果你工时估的准，表示你做过类似的功能。
如果这个功能有些地方是有不确定性，一定是估不准的。
因为你无法得知这些不确定性的地方需要花多少时间，
有些时候一些乍看之下很简单的问题，真正下去看才发现里面其实大有文章。
比方说，我要你解一个老鼠走迷宫的问题，
附加条件是老鼠要走过特定的check point，并且要走最短路境。
先看到这边，如果你从没解过老鼠走迷宫的问题，你觉得要花多久时间？
假设你没解过，但是你应该有听过，或是以前上课有看过类似的问题。
其实最基本的老鼠走迷宫就是很暴力的递回下去，答案就出来了。
只要你听过老鼠走迷宫，也许你会觉得这个问题只不过是老鼠走迷宫的变形，
上网查个资料就知道答案了。
所以你可能会估2-3个小时就可以完成，
不过就是上网查个资料加上自己local测试一下的时间。
但是你实际下去实作就会发现，它不是一个简单的递回问题，
如果要走最短路径，那就是shortest path的问题，
如果是走最短路径再加上走过所有check point，那就是travelling salesman的问题，
整个算法都和当初预想的不一样了，
而你当初却没有估到这一块。
就是因为软件开发时，对于"技术的掌握"以及"客户需求的掌握"有不确定性。
所以总是让你估的工时像屁一样。
而且你的工时又是主管估的，估工时的人和实作的人不是同一个人，
那估出来的时间更是不准。
(反过来说，如果客户要的功能很简单，需求很明确，而且你又做过类似的功能，
那就你的工时就会估得很准。)
那你该怎么办呢？
不知道你们有没有跑scrum，
基本上工时不应该是由来主管估，也不应该是由你自己一个人来估，
应该是开个会，整个team一起来估。(当然你也会去估其他team members的工时)
这样估出来的时间会相对比较准一些。(但还是有可能会不准)
然后应该把大的task breakdown，才知道那些地方是可掌握，那些地方不能掌握。
估出来会更准一些。
重要的是大家心里应该要有共识，有不确定性存在的话，工时一定估不准的。
其实估工时的目的不外乎就是
1. 想要知道有没有risk，会不会做不完，甚至做不出来
2. 有跟客户压deadline
3. 方便主管分配resources
如果有risk，一定要趁早说出来，寻求team member的帮助。
就算被骂也要说出来。然后看是要加人力，还是project要postpone。
risk其实是越早发现越好，而不是到deadline最后几天才发现作不到。
所以主管如果有sense的话，应该要去鼓励那些提出问题，主动寻求协助的人。
然后要去惩罚那些隐瞒问题的人。
而不是用言语去酸去骂那些提出问题的人，责怪他们能力不足，这样只会造成反效果。
因为这样会造成team member发现问题不敢讲，
然后自己加班埋头苦干，最后自己做不出来，deadline前几天爆发，
大家开始互批、互相推卸责任。
以上是我自己的一些看法，当然在某些senarios之下可能是不适用的。
有问题也可以来信讨论。