本文出自 “李云” 博客，請務(wù)必保留此出處http://yunli.blog.51cto.com/831344/168345
“老大”是我很要好的一個朋友，也是一個對于我的職業(yè)發(fā)展產(chǎn)生過很大影響的一個朋友。上個周末去了千島湖，順便給“老大”帶了一些枇杷，在送枇杷過去時和他好好地聊了聊。
我們倆在軟件行業(yè)做了都有近十年的時間，分別在全球知名的兩個通訊公司工作。在這之前，我倆是UTStarcom的同事，工作在同一個項目組。“老大”現(xiàn)在是公司的一名Manager（“老大”更喜歡Leadership這個詞
），而我是公司的一名Architect。
我倆的談話總是以“最近怎么樣”開始的，而我這次與他談到了對于現(xiàn)在所在公司的前景的擔(dān)憂。一方面公司在WiMAX上面并沒有達到期望的結(jié)果，另一方面，覺得通訊公司在軟件的開發(fā)方面并沒有很深的積累，不少開發(fā)方法還是“作坊式”的。當(dāng)然，這里說到的深是相對的，是相對于那種以軟件開發(fā)為本的公司，如Microsoft，等。對于“通訊公司在軟件的開發(fā)方面并沒有很深的積累”這一點，“老大”與我有相同的看法。比如，現(xiàn)在的通訊公司大量采用的都是C，除了據(jù)我所知Nortel在采用C++和OO開發(fā)接入網(wǎng)這一塊很有經(jīng)驗。OOP毫無疑問是一個能使應(yīng)用問題得到更好解決的一種開發(fā)方法，當(dāng)然，要真正的駕馭OO，對于開發(fā)人員的要求的確是更加的高。在Cockburn的《OO項目求生法則》中對關(guān)于OO開發(fā)的風(fēng)險有很好的闡述，但我想歸根到底還是人的問題。
我們談到了項目的管理。“老大”提到他現(xiàn)在所做的項目當(dāng)中有一部分的代碼質(zhì)量非常的差，只有通過重寫才能解決問題，但“老大”的老大的老大似乎并不知道應(yīng)當(dāng)讓大家這樣去做，而是一味的強調(diào)“測試！測試！再測試！”。對于這一點，我談了我的看法“說到底是相關(guān)人員其實并不了解軟件”。雖然，這些人也在軟件行業(yè)有八年仍至于十年以上了，但他（她）并沒有真正的掌握軟件行業(yè)的特點，主要存在以下幾方面的問題：
1）很多Manager在做Management以前都是技術(shù)出身，由于做技術(shù)期間沒有在軟件技術(shù)上有很深的積累，在做management時，當(dāng)別人提出一種的確行之有效的方法時，就沒有能力去判斷是否從長遠(yuǎn)來看有利于自己的團隊和產(chǎn)品，只相信那些能產(chǎn)生一定的數(shù)據(jù)的方法（比如，代碼覆蓋率）。在與“老大”談時，我們打了一個比方：比如，我們建了一座樓，如果這座樓的根基是好的，那么我們可以通過Refactor來“每次裝修一個房間”，從而達到最后的“量變產(chǎn)生質(zhì)變”的效果，在這種情況下，我們可以采用加強測試（如UT - Unit Test）來配合我們的Refactor；反之，如果這座樓的根基有問題，那“每次裝修一個房間”能解決問題嗎？此時，我想Restructure是更好的一個選擇。當(dāng)然，由于這些人并不明白這些道理，于是使勁的去做UT，那結(jié)果一定是：苦了工程師（沒錢沒生活）又害了產(chǎn)品（失去了重生的機會和用戶）。針對這種情況，Manager是應(yīng)當(dāng)鼓勵restructure呢？還是小的Refactor？Manager真的需要知道嗎？還是可以通過向相關(guān)的人問一問，怎樣做更好。問誰？專家？不。一線工程師會告訴你答案。當(dāng)然，我們談話中也持同一觀點：如果一個功能模塊很爛，但并不經(jīng)常出問題，或說是不占用大量的資源，在這種情況下即使是根基有問題，我們也不應(yīng)當(dāng)馬上去Restructure它。“老大”將根基不好的軟件比喻成“軟件黑哃”，很有新意！
2）不相信團隊。不相信團隊能通過采用新的方法從而改變現(xiàn)狀。我想很多的Manager在嘴上說“我相信我的團隊”，而內(nèi)心里其實是不相信團隊。為什么呢？其中，有一部分原因是他（她）自己從來就沒有通過技術(shù)的變化而成功的改變現(xiàn)狀的成功經(jīng)歷，因此，對于他（她）來說同意采用新方法就是一次“大冒險”。
3）不愿意承擔(dān)責(zé)任和風(fēng)險。這些人往往Offer都不錯，他（她）沒有必要讓自己去take risk，從而影響自己的“前（錢）途”。這其實是1）和2）所帶來的行為結(jié)果。
4）只關(guān)心自己。有些Manager只關(guān)心自己，并不關(guān)心自己的團隊以及自己所負(fù)責(zé)的產(chǎn)品。至于，團隊是否有太多的Overtime，或是士氣低下等等，一概視而不見，更不用說產(chǎn)品的未來了。
后來，我們也談到了開發(fā)方法，如Agile，SCRUM等等。我的觀點是：開發(fā)方法的出發(fā)點是好的，而且，很多方法的確是行之有效的，但關(guān)鍵在于我們在運用這些開發(fā)方法時，有時會“走火入魔”。在很多情況下，如果我們不能很好的把握運用這些方法的時機和分寸，那只能出現(xiàn)以下結(jié)果。
1）采用了方法論后，發(fā)現(xiàn)團隊更忙了，但是產(chǎn)出卻是更低了，質(zhì)量也沒有得到改善。進而
2）宣告這種方法無效。
其實，軟件行業(yè)一直以來就有很多行之有效的方法（但不是終級方法，別忘了No silver bullet!），只是，我們不能很好的去實踐和把握運用它們的時機和分寸。比如，現(xiàn)在很多軟件開發(fā)方法都鼓勵UT，但是UT這一概念是在30年前提出的。我們的從業(yè)人員對于UT真的有足夠的認(rèn)識和切身的體會嗎？除了UT，自動化測試也是很好的一種方法，但我們的測試人員真的覺得它重要嗎？
在很多的軟件書籍中都提到了人的重要性，但軟件行業(yè)真的是這么認(rèn)為的嗎？從現(xiàn)在狀況來看，我相信這一觀念還沒有深入到從業(yè)人員的骨髓中。甚至，不少人還用管理生產(chǎn)的方式來管理軟件產(chǎn)品。在《從優(yōu)秀到卓越》這一書中，作者指出其研究結(jié)果顯示：先人后事！即先找到合適的人然后再想要做什么。雖然，這書不是針對軟件行業(yè)的，但我想無論什么行業(yè)，其有些共性是相同的。我想“先人后事”在所有行業(yè)都通用。