不知道多少人有這樣一種經(jīng)歷：

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

至少我個(gè)人是有這種經(jīng)歷的。

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

程序員明明知道不應(yīng)該走捷徑去趕進(jìn)度，但給日程壓的沒辦法，就只能趕啊趕。

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

一個(gè)是加班，一個(gè)是降低代碼質(zhì)量。

最終產(chǎn)品倉促上市，在市場上發(fā)現(xiàn)了很多問題---最終很可能仍被歸結(jié)為程序員的問題。

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

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

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

先不管現(xiàn)實(shí)中這么做如何合理，但這樣至少是對事業(yè)本身是不利的。

很多事情往往只有身在現(xiàn)場的工程師才能清楚判斷其是否合理，如果在這個(gè)環(huán)節(jié)沒有聲音，那么就沒人知道實(shí)現(xiàn)層面是否有問題。

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

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

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

所以說回來，我感覺在上面的情形下，工程師要理智的發(fā)出自己的聲音，要能捍衛(wèi)技術(shù)的尊嚴(yán)，而不能一直說是。

當(dāng)然最終的選擇很可能和工程師期望的不一樣，這也沒有關(guān)系，責(zé)任和權(quán)利的比值應(yīng)該是個(gè)常數(shù)，只要做選擇的人也能負(fù)起相應(yīng)的責(zé)任那錯(cuò)了也沒什么關(guān)系。