销售的和企划的定好了规格和日期，把他们都作为不可更改的目标发配给程序员。程序员明明知道不应该走捷径去赶进度，但给日程压的没办法，就只能赶啊赶。

　　在限定场景下，一个人所能完成的工作其实是个确定值，因此这时候能采取的手段其实不多：一个是加班，一个是降低代码质量。最终产品仓促上市，在市场上发现了很多问题---最终很可能仍被归结为程序员的问题。

　　不知道大多时候，面对这种场景，工程师(包括开发和测试)会做什么样的选择?

　　我猜由于在这种多方博弈的时候，工程师的声音总是最弱的一个，所以大多时候，大多的工程师会选择忍受。

　　大致场景是按title一层层排下来的，最基层的每次都选择说yes。 先不管现实中这么做如何合理，但这样至少是对事业本身是不利的。很多事情往往只有身在现场的工程师才能清楚判断其是否合理，如果在这个环节没有声音，那么就没人知道实现层面是否有问题。

　　高级别的人也许大局观会好，但在实现层面是否有问题是不清楚的。一旦缺乏工程师的声音，那么商业需求，企业能的政治需求都会有影响力，唯有技术上的考量会被漠视。而技术这东西更像一支橡胶棒，很多人很多时候都可以弯曲它，达成自己想要的形状，但一旦达到某个界限后它就会反弹回来把所有试图弯曲它的东西砸个稀烂。

　　所以说回来，我感觉在上面的情形下，工程师要理智的发出自己的声音，要能捍卫技术的尊严，而不能一直说是。

　　当然最终的选择很可能和工程师期望的不一样，这也没有关系，责任和权利的比值应该是个常数，只要做选择的人也能负起相应的责任那错了也没什么关系。