計算機編程中極少人是真正的藝術家，大多數人充其量不過是房屋粉刷匠而已。Tim Bryce

　　管理顧問 Tim Bryce 不喜歡程序員，而許多程序員也不喜歡他。（注：Tim Bryce 發布過一篇名為《P理論：管理程序員的哲學》的文章。）

　　Bryce對程序員的看法：

• 程序員都是故弄玄虛，妄自尊大的家伙。
• 與其它大學程度的工作者相比，普通程序員的智商要低。
• 程序員總顯得邋里邋遢，精神渙散。
• 程序員做事雜亂無章，因此很難評估他們工作的進度，其技術也盡顯不足之處。
• 程序員的典型表現是常常埋怨自己工作過量，薪酬過低，所受的重視過少。
• 程序員自詡對科技發展懷有無比的好奇心。 然而，好奇心是需要通過管理慎重培養的，因為信息過多很可能會導致程序員在工作時分心。

　　在對Bryce先生文章（如上）的回復中，有很多優秀觀點，指出了他看法有失偏頗的原因。但是我想談談他興許正確的幾點看法。 我還想去了解為什么一些入行30多年的管理顧問會持有這樣的看法？當然， 我否認費絡伊德觀點論所說的 Bryce先生在童年時被某個無名的程序員傷害過。（主要的原因是當時世上只有為數不多的程序員，并且全都極負盛名。）

　　Bryce先生的目標聽眾不是程序員，而是 IT管理者和企業決策者（不管怎么說，程序員的低智商很可能會妨礙他們理解P理論）。 P理論的根本前提是：對程序員的管理越有效，我們就越能充分利用系統來支持企業的信息需要。這一理論并不是針對活生生的人， 而是針對講究實效的企業。人們應當從企業的角度來看待這一理論。因此，Bryce先生的以下三點看法看來并非全錯。

　　1. 程序員不是軟件工程師，而是翻譯。

　?。P于這點，請參見作者 Andriy Solovey 的另一篇文章：《程序員的本質》。）

　　我同意這種說法。程序員確確實實是翻譯。不過我并不認可他們翻譯的內容。 Bryce先生寫道說：程序員將人類可理解的指令翻譯成計算機指令。 實際上，程序員翻譯的是人類模糊隱晦的需求和想法，而不僅僅是不清不楚的指令。 有時候這兩者間的差別與畢加索化人類情感為藝術和房屋粉刷匠化顧客需求為斑斕墻面的差別無異。

　　如果客戶和程序員間的思想交流不足，蹩腳的翻譯及低劣的軟件將隨之產生， 而程序員本身也會看起來很糟糕。那么，Bryce先生的看法就言之有理了。 （系統思維 除外）

　　2. 許多程序員并非系統分析師。

　　不幸的是，在許多情況下確實如此。 Bryce先生寫道：真正的系統工程師或系統分析師會去了解業務需求，確定和開展能夠滿足這一需求的業務流程，并明確需要程序員實現的軟件要求。遺憾的是，擔當這一重任的人極少。因此，這樣的重任只能托付于那些不能勝任這項任務的程序員。

　　我確實認識很多不擅長去了解業務需求的程序員，或者說他們壓根兒就不愿意去了解。然而，與Bryce先生不同， 我認為程序員必須學會使用商業語言，學會與客戶進行直接交流并了解他們的需要。 程序員真正的工作不僅僅是編寫計算機程序，專業的程序員還應當熟練地將復雜的精神理念翻譯成軟件。

　　如若不然，業務理念的錯翻將會導致軟件低劣，也會因此抹黑程序員。 而Bryce先生的看法又將成為事實。

　　3. 程序員追求新興技術方案，而不是實用的解決方案

　　Bryce 先生寫道：要解決錯誤問題，簡單的方案是沒用的。 學會從業務的角度去驗證程序員自己的技術推薦十分重要。

　　的確，許多程序員對脫離業務理念的技術方案，甚至是新興的技術方案更感興趣。究其原因，是因為技術通常是程序員可以發揮才智與創造的唯一領域？還是因為程序員沒能參與企業決策并了解客戶需求？亦或是因為程序員素來脫離企業真正的需求和項目目標？

　　過度設計的解決方案是很糟糕的，它打著新興技術的幌子卻沒有實際的需要。 但是，如果能夠實現前面的兩點，即：1、程序員直接和客戶一同工作。2、程序員了解客戶需要并將其需求轉換為軟件，那么程序員就不會有時間和心思去理會天馬行空的技術解決方案了， 而是會努力尋求實用的方案，傾向并關注于那些重視客戶價值的解決方案。

　　P理論

　　Bryce 先生認為程序員是一群我行我素的極客，他們需要強而有力的監督管理。管理員應當想方設法控制程序員怠惰無常，偽知識的天性。 同時，軟件項目需要大批可以縝密分析業務需求的分析人員（低智商顯然不利于程序員直接獲取這一需要）， 當然，也迫切需要像Bryce先生這樣的管理顧問，他可以告訴你如何正確看待程序員及他們行為。

　　另一種方法，就是相信程序員是負責任的群體，允許他們直接與客戶一同工作并參與大部分的項目決策。 由于管理者和程序員現有的思維定式，要轉換觀念并非易事。但對完美軟件公司而言，一切皆有可能。