【IT168 評論】“我會(huì )更加努力地工作”——一匹名叫Boxer的馬(出自喬治·奧威爾的《動(dòng)物農莊》)

　　彼得·圣吉在其著(zhù)作《第五項修煉》中提到的系統思維定律同樣適用于軟件開(kāi)發(fā)。

　　1. 今日的問(wèn)題源于昨日的解決方案(Today’s problems come from yesterday’s solutions)

　　當解決問(wèn)題時(shí)，我們會(huì )感到很高興。我們經(jīng)常不考慮后果。令人感到意外的是，我們提出的解決方案可能會(huì )產(chǎn)生反作用，并帶來(lái)新問(wèn)題。

　　•作為對取得巨大成功的團隊的獎勵，公司決定為團隊中的少數骨干成員發(fā)放獎金并晉升職位。團隊中的其他成員會(huì )感到不公平，并且會(huì )喪失積極性。最終使團隊成員之間的關(guān)系更加緊張，后續項目也就很難再取得成功。

　　•項目經(jīng)理頻繁要求開(kāi)發(fā)者修復一個(gè)新的軟件Bug，或者處理客戶(hù)的緊急需求，而開(kāi)發(fā)者盡力滿(mǎn)足這些要求。但是，過(guò)于頻繁地分散精力會(huì )妨礙他們完成迭代過(guò)程中的主要任務(wù)。因此，項目進(jìn)展很慢。

　　2. 用力越大，系統的反作用力也越大(The harder you push, the harder the system pushes back)

　　當事情的進(jìn)展結果并非如我們所愿時(shí)，我們會(huì )固執地堅持自己的方法。我們沒(méi)有時(shí)間來(lái)停下來(lái)思維并尋找更好的替代方案，而是“義無(wú)反顧”地向前沖。有時(shí)候雖然解決了問(wèn)題，但往往又發(fā)現深陷于其他問(wèn)題之中。

　　•當一個(gè)系統遠未完成時(shí)，經(jīng)理通常會(huì )不斷催促員工加班加點(diǎn)地工作，并且要求按時(shí)完成。系統bug數量的持續增加及整體質(zhì)量的急劇下降，導致更多的延誤。因此，需要做更多的工作來(lái)部署軟件系統。

　　•為了滿(mǎn)足新系統的要求，開(kāi)發(fā)者勇敢的對原有的系統架構進(jìn)行擴展，但死板陳舊的方法已經(jīng)不能滿(mǎn)足這些新需求。他們忙于做這件事，以至于沒(méi)有時(shí)間停下來(lái)仔細分析并且改變方法，從而導致系統質(zhì)量下降。

　　3. 福兮禍之所伏(Behavior grows better before it grows worse)

　　短期的解決方案，會(huì )給我們帶來(lái)短暫的休息和狀況的暫時(shí)改善，但是不會(huì )從根本上解決問(wèn)題。這些問(wèn)題終究會(huì )使情況變得更糟。

　　•公司為顧客提供豐厚的優(yōu)惠并投入巨資宣傳，讓很多人購買(mǎi)軟件 。但是，顧客購買(mǎi)之后很不滿(mǎn)意，因為軟件無(wú)法使用也不可靠。

　　•如果開(kāi)發(fā)小組能夠按時(shí)完成系統開(kāi)發(fā)，管理層承諾，如果開(kāi)發(fā)團隊能夠按時(shí)完成系統開(kāi)發(fā)，公司會(huì )提供巨額的獎金。一個(gè)團隊開(kāi)始努力的工作，但很快他們就意識到這是不可能實(shí)現的。于是開(kāi)發(fā)者變得悲觀(guān)并喪失動(dòng)力。

　　4. 最容易出去的方法往往會(huì )導致返回來(lái)(The easy way out usually leads back in)

　　在生活中學(xué)到的一些解決方案能夠幫助我們輕易地并且更早的地獲得成功。我們總是試圖把它們強加到任何情形上，而忽略了特殊的背景以及相關(guān)人員。

　　•開(kāi)發(fā)者還沒(méi)有準備好接受結對編程或者測試驅動(dòng)開(kāi)發(fā)這樣的實(shí)踐時(shí)，敏捷教練強行實(shí)現完全的極限編程。這會(huì )給任何敏捷方法帶來(lái)壓力、沖突以及負面影響。

　　•開(kāi)發(fā)者把設計模式應用到任何地方，這是徒勞的，而且這會(huì )讓系統變得復雜。

　　5. 治療帶來(lái)的結果可能會(huì )比疾病導致后果更嚴重(The cure can be worse than the disease)

　　有些熟知的方法可能會(huì )更危險，比如在編程的時(shí)候喝啤酒，來(lái)減輕不切實(shí)際的任務(wù)期限帶來(lái)的壓力。

　　•由于不信任全職開(kāi)發(fā)者，一家公司雇傭了大量的承包商來(lái)開(kāi)發(fā)核心功能。結果，系統不具有概念完整性，自己公司的開(kāi)發(fā)者看不懂，并且無(wú)法做出修改。所以，公司員工也不了解相關(guān)領(lǐng)域的知識、解釋以及概念。

　　•開(kāi)發(fā)者會(huì )走捷徑，拷貝相似功能的代碼來(lái)趕進(jìn)度，并且爭取盡快發(fā)行第一個(gè)版本。他們一開(kāi)始進(jìn)展迅速，但是代碼最終會(huì )變成大泥球(比喻系統結構不清晰)。

　　6. 欲速則不達(Faster is slower)

　　當我們看到成功的曙光，我們會(huì )全力以赴，不再小心謹慎。然而，最優(yōu)增長(cháng)速率通常會(huì )比可能的最快增長(cháng)速率要慢得多。

　　•經(jīng)理們往往為已經(jīng)成功的項目增加很多人手，但總體進(jìn)展就會(huì )變慢，因為交流所用的花費增加，以及團隊成員之間失去默契。

　　•在沒(méi)有對代碼進(jìn)行合理重構及改善的情況下，開(kāi)發(fā)者快速的為系統添加新的功能，會(huì )使系統變得難懂，而且難以修改。

　　7. 在時(shí)間和空間上，因果并不密切相關(guān)(Cause and effect are not closely related in time and space)

　　我們善于為出現的困難尋找原因，即使這些原因很牽強，并且遠非是真正的根本原因。

　　•為了按時(shí)完成系統，開(kāi)發(fā)團隊不再接受來(lái)自客戶(hù)的需求改變。因此，客戶(hù)對發(fā)行的軟件不滿(mǎn)意。

　　•實(shí)時(shí)系統歷經(jīng)坎坷之后，管理層迫使開(kāi)發(fā)者同意，并且在給系統做出任何修改之前撰寫(xiě)詳細的技術(shù)說(shuō)明。結果開(kāi)發(fā)者失去了為系統做出任何改進(jìn)的動(dòng)力，并且開(kāi)始拖延。

　　8. 微小的改變可以產(chǎn)生明顯的效果，但這種杠桿效應最大的地方往往也最不明顯(Small changes can produce big results-but the areas of highest leverage are often the least obvious)

　　像改變公司政策、愿景或者廣告用語(yǔ)這樣顯而易見(jiàn)并且關(guān)系重大的解決方案往往不起作用。相反，小而普通，但持續的改變卻會(huì )帶來(lái)大不相同的效果。

　　•開(kāi)發(fā)者每天都與客戶(hù)進(jìn)行交流，并且做出大部分決定。因此，能夠更好地理解客戶(hù)的需求、做出更好的決定并且給出最優(yōu)的解決方案。

　　•開(kāi)發(fā)者為系統的每項功能設計自動(dòng)化單元測試。因此，設計更靈活、人們更自信、系統在每次修改之后都能得到完全的測試。

　　9. 魚(yú)與熊掌可以兼得，但不是同時(shí)兼得(You can have your cake and eat it too – but not at once)

　　我們經(jīng)常會(huì )面對刻板的“非此即彼”選擇。如果我們改變一下自己的觀(guān)點(diǎn)及系統規則，這些選擇有時(shí)并不會(huì )使我們進(jìn)退兩難。

　　•經(jīng)驗豐富的項目經(jīng)理知道增加系統特性的數量與削減時(shí)間和開(kāi)支不可兼得。然而，如果我們完善一下想法、尋找合適的人才并且避免過(guò)度開(kāi)發(fā)，這也是可能做到的。

　　•開(kāi)發(fā)者認為他們應該要么采用事務(wù)腳本，要么采用域模型體系架構模式。然而，復合域中的高性能解決方案可以將兩者結合，以得到最佳性能。

　　10. 把一頭大象分兩半不會(huì )得到兩頭大象(Dividing an elephant in half does not produce two small elephants)

　　無(wú)法整體了解系統，往往會(huì )做出次優(yōu)決定。

　　•項目經(jīng)理往往通過(guò)生成的代碼量和迭代過(guò)程中實(shí)現的功能數來(lái)評估開(kāi)發(fā)者。而開(kāi)發(fā)者往往會(huì )生成大量無(wú)用代碼。

　　•管理層承諾，每發(fā)現一處系統bug，測試者將得到5美元。測試者對跟開(kāi)發(fā)者合作不再感興趣，并且不再試圖消除產(chǎn)生bug的根本因素。團隊之間良好而且高效的關(guān)系不復存在。

　　11. 無(wú)可非議(There is no blame)

　　我們喜歡歸咎于客觀(guān)條件，或對別人指指點(diǎn)點(diǎn)，甚至對此深信不疑。但是，我們自己以及問(wèn)題的原因都是系統的一部分。

　　•今天早上團隊沒(méi)有發(fā)布系統完全是喬的過(guò)錯。即使項目經(jīng)理親切地為其提供了免費的啤酒、T恤以及披薩，他也沒(méi)能在一晚上的時(shí)間內修復所有的缺陷。

　　•人們不會(huì )使用一個(gè)公司優(yōu)秀的Web 2.0社會(huì )化應用，用戶(hù)喜歡簡(jiǎn)單實(shí)用的東西，并且不會(huì )感激你辛勤工作的成果。

　　然后呢?

　　以上11條系統思維定律表明，我們提出的所有解決方案都會(huì )產(chǎn)生一定的后果，有時(shí)非常嚴重并出乎意料。我們周?chē)南到y本就那樣，我們不應苛責它們，而是要從中學(xué)習。要掌握系統思維方式并控制這些系統，我們需要做到如下幾點(diǎn)：

　　•1. 要明白我們是在跟什么樣的系統打交道，是人或是軟件;

　　•2. 有意識地學(xué)習相互關(guān)系、因果鏈;

　　•3. 把系統看做一個(gè)整體，并且視其為其他系統的一部分。

　　系統思維方面有很多挑戰，通過(guò)獲取并且利用有關(guān)系統工作方式的知識，我們可以戰勝其中的很多挑戰。但是，大部分嚴峻挑戰是我們人類(lèi)與之相沖突的本性。我們的激情、感情以及本能可以輕易改變我們理智、條理分明的思維方式。掌握系統思維方式的第一步就是要學(xué)習如何跟自己合作。

　　后話(huà)

　　在軟件開(kāi)發(fā)過(guò)程中，你有(或缺乏)哪些系統思維的使用經(jīng)驗?