在我看來，程序員做的是開創性的工作?；ヂ摼W的發展不但推動了技術的發展，而且帶來了技術的普及。因此程序員不比以前，現在要找某方面的資料是很easy的事情了。看過大量的資料，各種新穎的技術方案和解決思路，不心動那是不可能的。OK，想用某某某框架，想用某某某技術，但是，因為各種原因，沒辦法應用到自己開發的項目中。這就是一個天花板。

在工作中往往有各種各樣的天花板，比如績效考核，項目進度，被打斷的思路，技術架構。因為你不是做決定的那個人，所以你就有天花板。

1、績效考核

很多公司都有績效考核，在我看來績效考核一個出發點很好，但是執行起來很扯淡的東西。從公司的角度來講，保證每個員工都在努力工作是很必要的一件事情。績效考核書面上講是一個激勵制度，我倒覺得更像是懲罰措施?？冃Э己耸滓膯栴}是由誰來考核，在一個團隊里不可能每個人都去考核一個人，也不會由普通員工之間進行考核，而是主管對普通員工進行考核。那就有可能滋生官僚主義，也會抑制主動性與創新力，增加犯錯機會。如果，對員工的考核都由主管來進行，員工絲毫沒有話語權，主管的人品就決定了團隊的運作方式。如果主管不太能接受意見，那誰還敢提意見？一個團隊了某人犯了錯誤，哪個主管敢給他背責任？因為也有更高的主管對小主管進行考核。團隊之間完全沒有了人情味，純粹就是機器的運作方式。

在這種情況下，大家都加班，你敢不加班么？在這種情況下，主管聽不進，你敢指出問題么？在這種情況下，你敢使用新技術，進行技術創新么？在這種情況下，你敢對現有代碼進行重構么？要是敢，那出了問題你就得背負。所有反而不如踏踏實實地，就用現有的東西，出了問題，就是已有的問題，沒有問題就是混日子。所以，績效考核成了程序員的天花板，抑制了想象力與創作的熱情。哪怕開發計劃肯定也是瞄準最容易的，而不會去挑戰什么了。

我認為，績效考核用在無需創新的場合比較合適，在軟件開發上，則面臨如何去劃分工作量，怎么客觀得評估工作量，還有就是上面提到的一些問題。大家都知道，這個工作量是很難被確定的，因為需求的變更等原因，即使需求不變，開始時估計的工作量能按時完成的有幾個？貌似很多書上都講很多項目完成的周期在預計的1.5倍時間左右。

我認為只有一種情況可以使用績效考核對程序員進行管理，那就是你不需要程序員進行思考，在軟件設計階段把所有的風險都規避了。比如瀑布模型開發，所有的東西都確定了，然后程序員只負責開發一個個方法，根本無需考慮算法問題，架構問題。程序員成了代碼工人。估計這個程序員離離職也不遠了。

2、項目進度

項目進度應該被強調。雖然項目進度也會對程序員的開發有一些抑制，但是不會太過明顯。因為項目進度本身就是由他自己來確定的。項目進度雖然會抑制創新，但是會加強團隊的整體感。假如甲開發的東西，是乙依賴的，那甲和乙肯定會保持溝通，并且，甲會對乙的進度負有一定的責任。如果甲是由責任感的話，只會讓甲對團隊有歸屬感。

但是如果本來是要一個月的開發任務，非要壓縮到一周完成的，團隊又會滋生新的問題了。一個是互相推諉，一個是團隊不穩定（跳槽）。

3、被打斷的思路

思路被打斷是很惱火的事情，如果經常發生這樣的情況，那是公司流程上有問題。只能從制度、流程上盡量規避這種事情。

4、技術架構

很多小公司其實并不存在這樣的情況，因為技術架構就是由工程師直徑決定的。在大一點的公司里，架構師設計的架構，就是程序員必須遵循的法則。比如，讓你用Mysql你就不能用mongodb。有一些架構師設計出來的技術架構，還留有開發人員自己思考的空間，而有些架構師設計的技術架構，則完全抹殺開發人員的嘗試。雖然技術架構保證了業務的穩定性，程序的規范性，可復用性，可維護性，可擴展性。..。.但對開發人員來講，那種架構師好則自然不言而喻。

在團隊管理中，要注重每個人，考慮每個人的發展，而不是抹殺掉他們的思考。總的來講，團隊里人才是最重要的。