“誰也無法改變現(xiàn)狀，唯有無數(shù)程序員血灑大地，才能使項目重建天日。”這一點也不夸張，軟件項目做爛了是個坑，參與者也不過是填坑的。像是在魔獸世界戰(zhàn)場遇到隊一樣，你贏也贏不了，出也出不去。
一、坑有多深？
當(dāng)我們進(jìn)入一個項目時，通過不斷觀察我們可以發(fā)現(xiàn)我們的項目到底是不是一個坑。造坑的項目，往往具有某些“臭味”，以下是我的一些認(rèn)識，這些“臭味”即是項目健康狀態(tài)不佳的明顯標(biāo)志：
編碼規(guī)范形同廢紙，代碼質(zhì)量低下。每個項目都有編碼規(guī)范，但真正嚴(yán)格實施卻是另一回事。太多的項目把編碼規(guī)范作為形式的存在，沒人在乎讓開發(fā)人員寫出“人能讀懂的程序”，注釋和命名也成了開發(fā)人員的隨心所欲。project上永遠(yuǎn)只有開發(fā)任務(wù)，而幾乎找不到單元測試的時間和代碼審查的時間。在高壓進(jìn)度之下的項目，顯得如此山寨。當(dāng)我們還在抱怨自己工資低的時候，先看看我們的程序還能稱作OOP嗎。
缺乏文檔或文檔質(zhì)量低下。前期文檔很重要，不論是框架的API使用手冊，還是需求或設(shè)計文檔，以及各種既定流程的規(guī)范，不同種類的模板及核對表，等等這些文檔，對于項目來說都是非常重要的資源。而往往有些項目，這類文檔是交由非軟件行業(yè)的人員來編寫，或者前期根本不打算在文檔上浪費時間。這導(dǎo)致了，缺少相關(guān)文檔或文檔質(zhì)量低下，在軟件構(gòu)建過程中，開發(fā)者和團(tuán)隊，不得不為這種“表面工程”的產(chǎn)物而糾結(jié)。甚至?xí)嘶氐角捌跍?zhǔn)備工作，完成所需的文檔。有些文檔可以在后期補(bǔ)，但有些必須在前期進(jìn)行準(zhǔn)備，以保住團(tuán)隊降低風(fēng)險，減少缺陷引人的幾率并提高編碼質(zhì)量，如果前期這類文檔沒有做好，那么會像考前不復(fù)習(xí)一樣，自食惡果。
無盡的需求變更，永遠(yuǎn)追不上的進(jìn)度。這是常見也是可怕的，因為無論怎樣，我們都無法完成它�？蛻艨赡苷J(rèn)為改個程序，像改個Excel一樣簡單省事，甚至?xí)褂每蓜佑玫囊磺袡?quán)利和資源來推行變更。好吧，我承認(rèn)這樣的客戶我遇到過很多。當(dāng)我向客戶解釋過變更的代價并提供備選方案后，也只能等待客戶的選擇了，這多少有些運數(shù)的成分，但也是無奈之舉。
僅僅靠加班應(yīng)對進(jìn)度落后。進(jìn)度落后并不可怕，可怕的是僅靠加班來追趕進(jìn)度。這是問題的關(guān)鍵，長時間的趕工仍然無法趕上進(jìn)度，這只意味著項目有某種更深層次的問題，已經(jīng)不是單開趕工可以解決的了。留意那些長時間加班的項目，他們往往在管理上存在很大問題，發(fā)現(xiàn)這些問題，在你成為PM時，不要犯類似錯誤。
溝通無門。如果你在一個“叫天天不應(yīng)，叫地地不靈”的項目里，那你好省心吧。項目中溝通很重要，但總有些項目，領(lǐng)導(dǎo)的工作太忙，人是找不到，發(fā)出去的郵件是沒人回，遇到問題是自己扛。在這樣的項目里也有一些好處，比如鍛煉自己的自學(xué)能力，以及磨練意志與根性。不過這些，也都是我的自嘲。低效的溝通將導(dǎo)致不必要的返工，這才是我所痛恨之處。我為惱火的一段經(jīng)歷是，甲方要進(jìn)行變更，開了一周的會沒人通知我，我的小組在這一周里完成了原計劃的數(shù)個需求并進(jìn)入到測試階段， 但這些需求均被砍掉 。本來只有甲方告知是可以調(diào)整進(jìn)度開發(fā)其它模塊的，但終演變?yōu)橘Y源的浪費。可見，溝通是多么的重要。
沒人關(guān)心質(zhì)量。因為軟件構(gòu)建屬于專業(yè)領(lǐng)域，客戶并不具備相應(yīng)領(lǐng)域的知識，由于這種信息不對稱，助長了軟件的質(zhì)量低下。我們開發(fā)的軟件可以是“低等級高質(zhì)量”的，但不能夠是“高等級低質(zhì)量”的。但是，太多的項目不在注重編碼質(zhì)量，這與軟件構(gòu)建的復(fù)雜度有關(guān)，也與整個行業(yè)的風(fēng)氣有關(guān)。但不管何種原因，提高代碼質(zhì)量仍然應(yīng)該作為團(tuán)隊的努力方向。團(tuán)隊?wèi)?yīng)該獎勵那些，編寫高質(zhì)量代碼的程序員。如果你的團(tuán)隊獎勵的是那些，“BUG殺手”（每天修改上百個BUG），而冷落那些缺陷檢出數(shù)量很低的程序員，那么，你的PM是個不懂技術(shù)的，至少我本人認(rèn)為，任何有技術(shù)背景的PM都應(yīng)該獎勵那些正在保持職業(yè)操守，認(rèn)真對待需求，保證代碼質(zhì)量的程序員。他們?yōu)轫椖扛冻隽烁�，更多的異常處理�?更多的測試調(diào)試，更多的檢查，更多的重構(gòu)，雖然他們的進(jìn)度并不快，但他們引人的缺陷數(shù)量很少。每個做過開發(fā)的人都會在質(zhì)量和進(jìn)度上做出取舍，而我敬佩那些選擇質(zhì)量程序員，因為他們才是真正拿開發(fā)當(dāng)事業(yè)的人。在此，向所有努力提高代碼質(zhì)量的程序員致敬！
沒人為缺陷買單，沒人為自己的成果負(fù)責(zé)。需求產(chǎn)出了低質(zhì)量的文檔，設(shè)計沒有進(jìn)行充分的迭代，開發(fā)可以怎么簡單怎么寫，測試可以隨意測測，沒人為自己的成果中的缺陷買單，除了項目經(jīng)理，他為項目承擔(dān)責(zé)任。當(dāng)項目組所有人員都在混時，是在給自己挖坑。這種缺陷的堆積，會像放射性元素在食物鏈中的堆積一樣，早晚項目會因此而崩潰。
過高的離職率。這個是明顯的“臭味”，這說明我們的同行已經(jīng)在這里無法忍受了。它所帶來的惡略影響不光體現(xiàn)在可用資源的減少，還體現(xiàn)在對成員士氣的極大影響。如果不及時改善，這將是一個非常惡性的循環(huán)，當(dāng)往一個進(jìn)度落后的項目中添加資源只會使進(jìn)度進(jìn)一步落后，而非正離職導(dǎo)致必須補(bǔ)充新的資源，資源從入職到培訓(xùn)都會對對團(tuán)隊產(chǎn)生震蕩，并降低現(xiàn)行團(tuán)隊的生產(chǎn)力。一個頻繁處于形成階段的團(tuán)隊，很難要求其有什么凝聚力，團(tuán)隊問題將會凸顯，尤其是在溝通上，在項目忙的時候很少能照顧到新人�；ㄙM在對新人進(jìn)行培訓(xùn)，和與其溝通上的時間，很可能得不償失。
團(tuán)隊中的不良情緒。不同團(tuán)隊開始扎堆并相互敵視，例如開發(fā)組認(rèn)為設(shè)計組是一幫搞業(yè)務(wù)的白癡，根本不懂編程；測試組認(rèn)為開發(fā)組的人是垃圾，BUG提交了多少便還是無法關(guān)閉；PM開始抱怨，自己的成員不配合；成員開始抱怨，PM是個純管理沒資格指揮內(nèi)行做事。等等，諸如此類的怨念會在團(tuán)隊中積累，并以某個導(dǎo)火索為契機(jī)爆發(fā)。面對現(xiàn)實吧，至少，我遠(yuǎn)沒有自己想象的那樣高尚。我承認(rèn)我曾經(jīng)會和別的程序員說：“你看XX他們寫的代碼...什么呀...”，這樣的話。在過去我也吐槽過別人代碼，這種做法是錯誤的，我為此表示歉意�，F(xiàn)在，如果有必要，我會說代碼有缺陷，但絕不會說他的代碼不好。我希望，我們能彼此尊重。對于技術(shù)人來說，不尊重他的成果是不尊重他的人，所以我還是建議PM在管理工作中，多用“缺陷”，少用“不行”、“不對”。但是，項目中也總是有些人，靠鄙視別人的成果來彰顯自己的實力。這些人，有，但很少。至少我遇到的很少，遇到過幾個，讓他們的話語成為你學(xué)習(xí)的動力吧。我曾經(jīng)被人諷刺UI做的太丑，之后我學(xué)會了SL和FLEX；被人鄙視基礎(chǔ)太差，之后開始閱讀《CLR Via C#》；我朋友被人嘲笑過數(shù)據(jù)庫設(shè)計，現(xiàn)在人家也開始買書深造。團(tuán)隊中是這樣，我們無法管住別人的嘴，但我們可以管住自己的。少說多聽，一鳴驚人，乃上上之策。不要受情緒的影響，保持一個平靜的心。
沒有項目或階段的后評價。不對項目的階段進(jìn)行后評價，也意味著沒人在乎你到底干了些什么，所有人都只是進(jìn)度是否完成，而沒有對完成的好壞進(jìn)行評價。這也意味了，僅靠做好你的工作，你是無法得到領(lǐng)導(dǎo)的重視的。終只有那些加班時間長的程序員被領(lǐng)導(dǎo)認(rèn)可。而能力強(qiáng)，口碑好的成員也只能在團(tuán)隊和客戶中間留下傳說。
