※ 引述《TonyQ (自立而后立人)》之铭言：
: 觉得有点感触，来写一下这几年我对软件专案的几个看法，
: 如果估计的时间有出入，通常都是 spec 的认知有出入，
: 那时候该厘清的是 spec 细节跟重新估算。
: 而不是在那边“我觉得要一个月”、“但我觉得要一周”，
: 这种愚蠢的菜市场喊价。
“时程估计”是 PM 与 Dev 之间的 eternal conflict 。有的时候
不是 PM 故意找麻烦，而是 PM 的上级在逼 PM 说出一个日期。
感觉上，以下这个模式是个还不错的平衡点
(1) 很明显要花五天以上去作的部分，应该重新检视，拆成更小的部
分
(2) 很明显是一天以内能作完的事 (尤其是很制式的流程) ，应该研
究将其自动化的可能性，及编列预算
(3) 两天至五天内的部分 (尤其是无制式流程可参考的时候) ，双方
要达成以下共识:
(a) 视情形，先花 1/4, 1/6, 或 1/8 的时间试作看看，试试水
温
(b) 试作时间结束后，很简短地开个 stand-up 会议， Dev 告
之 PM 他对原始时程估计值的 "gut feeling"
(c) 诚实地调整原始估计值
* 让 PM 成为你的盟友，帮助他建立 burn down chart ，掌握专案
进度，让他的上级闭嘴
* 让 Dev 成为你的盟友，一旦 Dev 愿意合作建立 burn down chart,
除非你带给他们 free food, 不然别再去烦他们
============================================================
以上这模式有个前提: 管理者不是昏君，团队里没有贱人