就去掉一部分，然后將余下的發(fā)下去。就如同很多企業(yè)所謂的“全勤獎金”一樣。沒有什么深奧的東西，心理策略而已。

所以雖然“開掉”是最有效和快速的方法，但是如果很多滋生壞蘋果的土壤不改善的話，再怎么開也沒有用，壞蘋果還是會一個接一個的冒出來。建立良好的團(tuán)隊文化，合理的公司制度，一個積極向上的團(tuán)隊才是最根本的解決方案。

跟蹤和反饋

在項目初期，項目還在掌控之中的時候這個做的還是比較好的，但是到了后期這些東西卻沒有被很好地執(zhí)行和貫徹。給我印象比較深刻的是對bug的跟蹤問題。到了后期，一些bug出現(xiàn)對應(yīng)不明確，甚至出現(xiàn)bug沒人修正的現(xiàn)象。bug的修正任務(wù)分配下去，下面卻忘記修正，或者雖然修正了，但是修正不正確不全面。還有就是下面的人對修正的bug不進(jìn)行測試，甚至連跑都不跑一下。出現(xiàn)這樣的現(xiàn)象，后期程序員比較累，惰性比較大是一個方面，但是更多的是因為沒有有效的跟蹤和反饋機(jī)制造成的。

參考解決方案——

剛進(jìn)公司的時候，趙問我“你們公司PL （Programmer Leader）是怎樣一個職位？都做些什么？”。我說，“其實PL就是PM到PG的橋梁”。也許那時候還沒有那么深刻的體會到所說的這個比喻，但是現(xiàn)在似乎有更深刻的理解了。這次項目，到后期，趙（PM）幾乎可以說忙的沒有辦法了，所以像bug跟蹤和反饋這樣的問題也只能放下了。但是PM不管，那讓誰了管呀。其實這樣的事情就是應(yīng)該PL來做的。PL去走整個完整的bug修正工作流，然后對PM匯報即可。什么bug，修正了沒有，修正好了沒有，有沒有測試，有沒有引起其它的新的問題，有沒有反饋給測試部。這些詳細(xì)的工作流都是應(yīng)該讓PL來跟蹤的。PL走完這個工作流以后，然后向PM匯報就可以了。這樣PM也可以在總體上進(jìn)行跟蹤。上個項目，有一個人沒有被充分的利用，那個人就是——我。我是負(fù)責(zé)頁面樣式和web標(biāo)準(zhǔn)的。這些東西在初期是最忙的，但是到了后期別人最忙的時候，我卻是最清閑的。不過是偶爾修正一下頁面上的反饋問題罷了。其實這個時候，我應(yīng)該充當(dāng)起PL的這個角色，把趙在初期做的一些過于細(xì)節(jié)性的東西（例如一些跟蹤和反饋的工作流）接過來做。而PM這個時候去專注于更緊急和更重要的事情上去。因為剛進(jìn)公司，所以，上個項目我完全是一個new comer。所以很多的事情，我都在盡量的保持低調(diào)。以免給別人留下過于突進(jìn)和浮躁的印象。所以，到后期，看到別人很忙，而我卻很輕松的時候，我有些不安。所以在下個項目中，我將盡量的主動的去承擔(dān)一些我能夠勝任的工作。以在一定程度上減輕趙的負(fù)擔(dān)。

代碼review太浪費時間？

這次項目算是吃夠了代碼質(zhì)量低下的苦頭。到了后期甚至出現(xiàn)很多代碼需要趙重新來寫一遍的情況。出現(xiàn)這種情況的代價是巨大的。部分模塊所編寫的代碼完全推掉重寫，毫無疑問這些所花費的資源都就將被浪費。到了項目后期項目最緊的時候，PM卻在寫代碼！PM的精力也是有限的，他的時間也是有限的，如果他在寫代碼，那么是誰在進(jìn)行項目管理呢？更重要的是他讓人們感覺整個項目漏洞百出，從心理上打擊整個團(tuán)隊。在項目初期，特別是項目時間估算過短的話，代碼review好像的確很浪費時間的樣子，但是“bug發(fā)現(xiàn)的越早，修正的越早，所付出的代價越小”這句話絕對是真理。

參考解決方案 ——

提高代碼質(zhì)量，重視項目品質(zhì)，絕對是項目管理中的重中之重。而提高代碼質(zhì)量和項目品質(zhì)的比較有效的方式就是代碼review手段。嚴(yán)格的、統(tǒng)一的代碼我感覺比“散落的”、“個性的”代碼擁有更好的可讀性和維護(hù)性。還有我感覺代碼review對于新人的進(jìn)步和編碼的習(xí)性上有很好的指