※ 引述《AmosYang (泛用人型编码器)》之铭言：
: ※ 引述《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, 不然别再去烦他们
: ============================================================
: 以上这模式有个前提: 管理者不是昏君，团队里没有贱人
这个模式的专案执行应该不会在台湾，而且可能也只有软件专案才会发生。
若以web system的专案而言，
PM和PG之间还有SA和SD，压力通常不会从PM直接传导到PG上。
PM还有分大PM和team PM。PG多半都是在和team PM沟通。
专案执行过程中，大PM根本不会(不屑?笑)理会PG，更别说是成为盟友之类的角色。
就时程估计而言，比较老练的team PM也不会问你办不办得到。
反而是自行订下日期，并在期间多次问你有没遇到困难，需不需要支援。
就程式开发而言，计算的是开发交易的完成度和数量，PG不会有试水温的机会。
唯一可以试水温的人和事，是经验不足的架构师和可能砍掉重练的系统架构。
这也只有专案初期到中期才有可能发生的事，并且如果不想让专案执行失败的话。
就文件撰写而言，专案规模和参与公司之数量，往往和依照文件开发真实度成反比。
那些在专案初期产出的文件并不完整，尤其是跨公司开发的部分通常会模糊带过。
专案初期撰写的文件主要是应付给客户看的，并且在事后可能也不会再变动。
就PG同侪之间，除了有习惯性倚赖的同事以外，工作外的互动几乎很难有。
当然这和专案规模及PG年纪也有不小的关系。
与其要当实质盟友，不如直接翻版控观摩同侪写的程式，可抄可改可参考。
专案执行中，
PM和客户开会的次数与专案进度的严重程度正相关。
PG和上层最忌讳的是业务资讯不对称的程度。
PG和PG彼此之间的嫌隙会发生在对业务资讯掌握程度的比较和team PM的信赖度，
尤其是team开会也不请你参加的情况，就要自己小心了。
总之，web system 专案是结果论的，
当PG者，只需参与并从中学得自己想要的技术，
剩下的，是以后身为SD以上才需要知道的事。