1.8 常見的錯誤應(yīng)對方式

有時候，資源有限未必是壞事，因為它也是倒逼創(chuàng)新的最好方式。但是從短期視角來看軟件研發(fā)，這個觀點似乎并不明智。

最常見的錯誤方式是采用DDD（Deadline Driven Development，期限驅(qū)動開發(fā)），用Deadline來倒逼研發(fā)團(tuán)隊交付業(yè)務(wù)功能。但大量的實踐經(jīng)驗告訴我們，軟件研發(fā)就是在需求范圍、軟件質(zhì)量、時間進(jìn)度這個三角中尋求平衡的，如圖1-6所示。

圖1-6 軟件研發(fā)的三角平衡

短期來看，研發(fā)團(tuán)隊可以通過更多的加班來趕項目進(jìn)度，但如果這個時間限制過于苛刻，那么必然就要犧牲需求范圍和軟件質(zhì)量。當(dāng)需求范圍不可裁剪的時候，唯一可以被犧牲的就是軟件質(zhì)量了，這實際上就意味著在很短的時間內(nèi)往軟件系統(tǒng)中傾瀉大量的隨機(jī)復(fù)雜度。

而且，上述做法從表面上看可以更快地取得進(jìn)展，快速摘取成功的果實，但是經(jīng)過一段時間之后（一般是6～18個月），負(fù)面效果就會凸顯出來，會顯著降低研發(fā)的速度和質(zhì)量。而且這種負(fù)面效果是滯后的，等問題能夠被感知到的時候，往往已經(jīng)形成一段時間，軟件架構(gòu)的腐化就是這樣在不知不覺中形成的。

以上這種急功近利的做法，本質(zhì)上是將長期利益讓位于短期利益，過度追求短期交付效率，最終的結(jié)果只能是“欲速則不達(dá)”。

正確戰(zhàn)略方向下的“慢”，遠(yuǎn)遠(yuǎn)好過錯誤方向下的“快”。作為技術(shù)管理者必須學(xué)會兩者之間的平衡之道，并為此長期承擔(dān)后果。

當(dāng)然，如果你是在創(chuàng)業(yè)項目前期，則可以暫且不關(guān)注這些，畢竟幾個月后你的項目是不是還活著都是一個問題，但如果創(chuàng)業(yè)項目熬過了這段時間，還繼續(xù)這么做就會很危險。那么，你可能會問創(chuàng)業(yè)項目的代碼在前期積累了大量的隨機(jī)復(fù)雜度，后續(xù)該怎么辦？筆者的答案是，在適當(dāng)?shù)臅r候另起“爐灶”，在用戶無感知的情況下完成后臺服務(wù)的替換，這個適當(dāng)?shù)臅r候往往就是項目的商業(yè)模式完全走通的時間點。正確的技術(shù)戰(zhàn)略需要能夠在宏觀層面上幫助系統(tǒng)控制復(fù)雜度。

記得在一次行業(yè)交流的時候，有一位朋友說到一個觀點：“亂七八糟的生機(jī)勃勃，好過井井有條的死氣沉沉”，乍一聽這個觀點還是挺有道理的，但是筆者覺得對于軟件工程來講，這個觀點是完全不適用的。這個觀點對于需要創(chuàng)意的工作是成立的，創(chuàng)意工作一般是單次博弈（前后兩次擲骰子沒有關(guān)聯(lián)性），而軟件工程是工程，屬于連續(xù)博弈（前面的行為對后面的有影響），所以筆者認(rèn)為上面的觀點不成立。

另一種常見的錯誤方式是試圖通過招聘或借調(diào)更多的人來解決軟件項目的進(jìn)度問題。隨著項目參與的人越來越多，分工越來越細(xì)，人和人之間需要的溝通量也呈指數(shù)增長。很快你就會發(fā)現(xiàn)，溝通花費的時間漸漸地比分工省下來的工作時間還要多。簡單說，過了一個臨界點，不是人越多越幫忙，而是人越多越添亂。一個人3個月能完成的事，3個人1個月不一定就能完成，甚至3個月也未必能完成，更何況加入的新人還需要填上認(rèn)知負(fù)荷的“坑”，這些都需要時間成本。