不知道多少人有這樣一種經歷：

明明從技術上看是不對的或者說是不可能的，但還是要按照一種不對的方向做下去。

至少我個人是有這種經歷的。

銷售的和企劃的定好了規格和日期，把他們都作為不可更改的目標發配給程序員。

程序員明明知道不應該走捷徑去趕進度，但給日程壓的沒辦法，就只能趕啊趕。

在限定場景下，一個人所能完成的工作其實是個確定值，因此這時候能采取的手段其實不多：

一個是加班，一個是降低代碼質量。

最終產品倉促上市，在市場上發現了很多問題---最終很可能仍被歸結為程序員的問題。

不知道大多時候，面對這種場景，工程師（包括開發和測試）會做什么樣的選擇？

我猜由于在這種多方博弈的時候，工程師的聲音總是最弱的一個，所以大多時候，大多的工程師會選擇忍受。

大致場景是按title一層層排下來的，最基層的每次都選擇說yes。

先不管現實中這么做如何合理，但這樣至少是對事業本身是不利的。

很多事情往往只有身在現場的工程師才能清楚判斷其是否合理，如果在這個環節沒有聲音，那么就沒人知道實現層面是否有問題。

高級別的人也許大局觀會好，但在實現層面是否有問題是不清楚的。

一旦缺乏工程師的聲音，那么商業需求，企業能的政治需求都會有影響力，唯有技術上的考量會被漠視。

而技術這東西更像一支橡膠棒，很多人很多時候都可以彎曲它，達成自己想要的形狀，但一旦達到某個界限后它就會反彈回來把所有試圖彎曲它的東西砸個稀爛。

所以說回來，我感覺在上面的情形下，工程師要理智的發出自己的聲音，要能捍衛技術的尊嚴，而不能一直說是。

當然最終的選擇很可能和工程師期望的不一樣，這也沒有關系，責任和權利的比值應該是個常數，只要做選擇的人也能負起相應的責任那錯了也沒什么關系。