對中國自發產生的軟體企業的思考——（4）管理和人：微觀 (轉)

對中國自發產生的軟體企業的思考——（4）管理和人：微觀 (轉)[@more@]

很抱歉這麼久才有第4篇，希望還有朋友記得本文。歡迎大家提出意見。

 

原本預計寫7個主題，但是在完成的過程中合併了幾個主題，因此下一篇將是最後一篇，多謝關注。謝謝。

 

4. 管理與人-微觀

 

在上一篇中我們探討了管理和人其中一個方面，即從宏觀的角度來說，對於目前公司和高層管理者在日常管理中的一些誤區進行了討論。我想我們可以同意，在日常的管理中，存在著相當多的地方是需要改進的。

 :namespace prefix = o ns = "urn:schemas--com::office" />

但是，我想沒有人會認為當前中國企業中的種種問題就純粹是由於上層的管理不善造成的，作為問題的另一面，我們每一個開發人員，每一個專案經理和每一個部門經理，對於我們在日常工作中的工作方式，工作方法以及工作態度和工作意識，也都存在著相當的問題。下面，我就想和大家探討一下管理和人的另一個方面：每個人的微觀行為。

 

當然，在我短短的職業生涯中，所見過的，聽過的肯定極為有限，曾經一起工作過的同事們也並不具備廣泛的代表性。同時，既然是反思，自然會很少談到優點，而並非我忽視了中國的人員身上所蘊含的優秀品質。因此，如果有什麼說錯的地方或是以偏概全了，還請大家不吝批評指正。

 

讓我們首先從幾乎我們每個人都經歷過的，也是我們最有感情的角色，一個普通開發人員說起吧。

 

開門見山。第一，在員群體當中，有相當部分的程式設計師，其技術水平相當之低。我並非信口開河，而是根據我在實際工作中所見到情景才這麼說的。

 

這樣的程式設計師，其首要的表現就是不愛學習，得過且過。所謂的不愛學習，並不是說他真的不學習，不看書，而是說他缺乏一種真正學習技術的激情，缺乏上進心。

 

由於我們國家大學計算機教育的問題，基本上我們在開始參與實際的開發工作時，很多具體應用層面的東西，都需要自己重新進行學習。在學習的時候，很多人就只是淺嘗輒止，不求甚解，卻從來不試圖有意識的提高自己的水平。就以C++語言為例，就我的觀點而言，一個沒有通讀過《C++ Primer》或《The C++ Programming Language》，沒有精讀過《Effective C++》的程式設計師，不會是一個合格的C++程式設計師（別誤會，我不是說這就夠了，這只是必要條件，不是充分條件）。而在實踐中，我見過不只一個程式設計師，本來當年就由於歷史的原因，只掌握了C++語法而不是C++語言，卻根本連《C++ Primer》和《The C++ Programming Language》是什麼都不知道。

 

對於這樣的程式設計師，我們怎麼能夠期待他們開發出優秀的軟體？又怎麼能夠宣稱中國的軟體開發人員水平都很高？

 

同時，由於這樣程式設計師的存在，降低了中國程式設計師的僱主們對於中國程式設計師的整體評價。在大多數時候，對於新招聘的程式設計師，管理者暫時是不能夠給予充分信任，一開始只會交給比較簡單的工作以考察其水平。對於程式設計師來說，這妨礙了僱主對於自己工作能力的認識，也因此妨礙了可能的升遷；對於管理者來說，則浪費了資源，降低了。然而，因為這樣做比選擇一開始就信任新程式設計師卻失敗付出的代價要小，所以我們當中很多優秀而勤奮的程式設計師，在進入一家新的公司的時候，都不得不在相當長時間內重複地做對自己而言太過簡單的工作。

 

因此，我想說的是，每個人都想自己的生活過得越來越好，作為一個普通的程式設計師來說，所能走的道路就只有一條：不斷提高自己的技術水平。這樣，一方面，雖然生活水平不一定能夠與技術水平一起同步提高，但是終究比混日子更有可能過上自己喜歡的生活；另一方面，所有軟體開發人員整體水平的提高有賴於我們每個人技術水平的提高，而整體技術水平的提高，雖然我不是學經濟的，但是我認為，是有助於整體工資待遇水平的提高的。因此，請努力學習，不斷提高自己的技術水平，為了你自己，也為了所有的程式設計師。

 

第二，有相當部分的程式設計師，主要以從事外包工作的開發人員為主，除了工作需要的之外，不掌握任何額外的知識，也沒有學習額外知識的願望。不過坦白地說，這到不能全怪程式設計師。一般能夠穩定的從事外包工作的程式設計師，待遇還是相當不錯的，而很多時候，外方的要求（我只做過日本軟體外包，歡迎做歐美外包的同志補充）也並非是技術上的。同樣因為外方要求的原因，就算你掌握了很新很好的技術，有了很好的想法，在實際工作中也很難得到應用。只有外方要求的時候，才會學習和實踐新的技術。因此長此以往，漸漸地就只是簡單的滿足外方的要求，雖然有些人能夠因此得以在一項技術上達到很深的境界，但是就總體來說，這樣的程式設計師們，因為並不需要，所以實際的對於開發語言，開發工具和新技術的掌握水平，往往不高。這麼說也許有點過分，但是很多我以前的同事和朋友，的確正是處在這樣的狀態之中。

 

以上所說的程式設計師們其實一定不包括CSDN上我這篇文件的讀者。常上CSDN的朋友，是不會像他們一樣沒有上進心的。但是，很遺憾，我認為，在絕大多數這樣的朋友身上，都存在著一個很大的誤區。這也是我第三點想說的。

 

第三，我們一般總是喜歡鑽研具體而實際的東西，比如掌握一種語言各種特性，得心應手的應用一種開發工具，學習一項具體的技術，等等。我們中國人勤勞而刻苦，所以在具體的鑽研過程中，是不會輸給任何民族的。因此我們經常可以見到在某一個語言，某一個工具或是某一項技術上，已經達到相當高度的高手。

 

然而，這是遠遠不夠的。有相當多的朋友，在鑽研技術的過程中，陷入了只見樹木，不見森林的窘境：在對於具體語言和工具的應用當中，遊刃有餘，卻缺乏對於軟體開發科學整體的瞭解。

 

舉幾個例子。

 

不記得那一期《程式設計師》雜誌上了，提到一次測試當中，被一個大學生發現的，傳送軟體，如果不寫發件人地址就點選傳送，會導致當機。我個人在實際工作當中，也見過類似的例子。導致這樣的bug，絕對不會是因為開發者對於語言或者開發工具不夠熟練導致的，而是不掌握軟體開發的科學。任何一個軟體，都應該能夠保證其內部的自我完整性，必須是自成體系的。即必須保證整個軟體執行過程中的資訊和資料的流動，都是完備的，得到處理和相應的。像本例中的bug，很明顯，軟體在開發過程中忽略了某個資料的處理，不能夠滿足內部自我完整的要求。而這種對於內部自我完整性的意識，不是透過鑽研語言、工具或是技術能夠得來的，並透過有意識的學習和時間才能夠得到。

 

再比如，一個我實際工作中的例子，一個軟體，負責從中取出資料輸出給，使用者要求輸出時對原始資料進行一定的格式轉換，如數字轉換成文字。此時正確的做法應當是，從資料庫中原封不動的取出原始資料，自行根據要求進行格式轉換，然後輸出。然而，負責的程式設計師卻選擇了將資料轉換交給資料庫來做，不管原始資料是什麼格式，要求資料庫將資料按指定格式輸出，然後直接輸出給使用者。先不說兩種做法在維護上的好壞（得到原始資料之後可以適應各種需要，否則的話如果需要的不是格式轉換了，程式要重寫了），從根本上講，作為一個從資料庫中取出資料的程式，保證資料的純潔性是自然而然的要求，有了原始資料之後在怎麼做都是在掌握之中的，而你根本無法確定資料庫究竟會如何對資料進行轉換。同樣，如果沒有有意識的學習和實踐，就算C++語言掌握的再好，資料庫學的再精，也不能算是一個好的程式設計師。

 

就是類似這樣一個一個的問題，在實際工作當中，很難得見到真正除了語言，開發工具之外，還能從整體上考慮和把握軟體的整體架構和完整性的程式設計師。

 

因此，我認為，在實際工作和學習中，不但要注重深度，還要注重廣度和對於整體架構的把握和感覺。對於這方面，我自己也沒有什麼好的，歡迎大家補充。

 

第四，三條腿的蛤蟆好找，虛心的程式設計師可比沒bug的程式難找。這一點相信大家都和我一樣深有體會。每次開會都吵的天昏地暗，程式設計師特別難以在技術分歧上達成一致。並且，我相信我們每個人都會有過這樣的經驗：明明對方程式中存在著一個很不合理的地方，對方卻怎麼都不肯聽取自己的意見；或者自己的程式明明寫得好好的，卻偏偏有人無中生有，非說什麼地方有問題。

 

就我所見到的程式設計師們，絕大多數都相當自負，很難聽從別人的意見，並且從剛畢業不足一年的小菜鳥到若干年資格的前輩，莫不如是。因此，在實際工作中，發生種種的矛盾衝突也就是自然而然的了。我認為，我們很多人，都缺乏對於他人的尊重以及妥協的意識。

 

先說尊重。很難讓一個程式設計師真心實意的承認自己比某個別的程式設計師水平低，在此基礎上，自然也就很難聽從一個水平不如自己的人的意見。而實際上，計算機技術發展一日千里，我們每個人都可能至少在某些方面落後。不論對方是資歷和經驗都比你豐富的老手（你往往覺得他們觀念落後），還是剛入行沒多久的小鳥（他們的技術水平比較低），都是和你一樣的專業人士。他們基於自身的技術和經驗所做出的判斷，和你自己的一樣，都可能包含著錯誤和正確的東西，並無高下之分。因此，認真、虛心的聽取他人的意見，仔細的思考其是否正確，不但有益於你的工作，而且對你自身水平的提高更是有著極大的好處。孔子曰，三人行，必有我師。

 

再說妥協。當你聽到別人的觀點的時候，你先考慮的是什麼？是對方觀點中正確的地方在哪裡，是否可以接受？還是先找其中錯誤的，不能實現的地方？我想說的事，就算你自己的意見比較正確，別人的意見中也未必沒有合理的，能夠對你進行補充的地方。因此，聽到別人的觀點，首先應當先考慮對方合理和正確的地方在哪裡，而不是先抱著排斥的心理挑毛病。就算別人的觀點最終不能夠接受，其理由也應當是對方觀點中的優點不夠你的多，不夠你的好，而不是由於對方的錯誤。

 

第五，嚴重缺乏團隊協作精神。關於這一點，我認為最突出的表現就是隻有極少數的程式設計師，會關心別人，自己的同事，團隊夥伴，是否真正理解了自己的觀點/文件/程式碼/其他。我在上一篇文章中已經提到過這個問題。我們絕大多數的程式設計師，都缺乏將一件事講清楚的意識，甚至很多時候，也缺乏真正將別人的意思搞清楚的慾望。資訊在溝通和交流當中，損耗和失真極其嚴重。就我自身的經驗而言，我在開發組內部的技術會議上，往往會充當一個翻譯的角色，即不但要將我自身的，特別是組內其他人的意見，以大家都能聽懂的語言和方式描述出來，不然，我不止一次的見到過雙方進行極其激烈的討論，到最後卻發現大家說的完全是不同的東西。

 

當然，正如我上一篇文章中所說的，不經過有意識的訓練和實踐，人是很難有把事情說清楚地意識的。因此，我們在實際工作中，就更要注意在表達自己的意見，撰寫文件和程式碼等的時候，能夠從別人的角度出發，思考一個對自己的工作不太瞭解的人，是否能夠聽懂，看懂自己的所說和所寫，哪怕羅嗦和拖沓一點，也一定要把事情說清楚。而不能只從自己的角度出發，覺得寫清楚了，說清楚了就算了。

 

第六，缺少一種白領工作的技巧和意識。先別覺得我故弄玄虛，我知道一般都認為，我自己也同意，程式設計師不過是坐辦公室的藍領而已。我這裡所說的白領工作的技巧和意識，指的是從事類似的腦力勞動，主要與各種各樣的文件和打交道的時候，所需要的工作的技巧、方法和意識。

 

我們在實際工作中一定要涉及到文件、程式碼等資訊的交流，各個公司可能透過檔案、電子郵件等不同的方式來進行。我看到過很多這樣的情景，採用檔案伺服器的，連檔案伺服器的地址都不知道，採用電子郵件的，所有的亂糟糟的堆在一起，什麼都找不到。當在工作當中需要一份文件或別的什麼的時候，明明早就已經收到過，卻怎麼都找不到，也不想找，直接要求該文件的負責人再次傳送，甚至有時候他自己負責的東西都會找不到，要別人來為他提供。或者有的時候能找到，卻往往是錯誤的版本。

 

這不僅浪費了自己的時間，更重要的事，還會浪費別人的時間，有的時候，會極大的降低整個專案組的效率。

 

其實要避免這些非常簡單，只要能夠每天花上一點時間，對自己收到的mail和文件進行分類，將自己的工作成果到檔案伺服器就行了。可是我卻很少見到有人能夠有這樣的意識。當然，處理和分類文件也需要一定的技巧，但是這些並無一定之規，可以在實際工作中自行總結，一切以提升工作效率為目的，並沒有什麼困難的地方。

 

以上總結了六點，是我對於程式設計師這個角色所做出的反思。我認為，其中大多數問題其實都是意識問題，沒有意識到這樣做是不好的或是不對的，只要意識到了，要糾正非常容易。

 

然後讓我們來討論開發當中，最重要的角色：Project Manager和Group Leader。

 

如今我自己是一名具有Group Leader資歷和經驗的程式設計師，在過去幾年的職業生涯當中，也有過曾經在數名Leader的領導下工作。就我所見，目前，我們的Project Manager和Group Leader們，最大的問題，就是不會也不知道該如何領導別人。

 

我這裡所說的領導別人，指的不是開發過程中，種種具體問題的解決，比如如何組織和架構一個小組，如何制訂工作流程，如何分配工作等等。關於這些問題，要麼已經有先賢們的書籍可作參考，要麼已經有成熟的制度和方式可供參考。

 

我所說的不知道該如何領導別人，指的是：第一，不知道在基層Leader這個角色上該如何與別人進行交流；第二，沒有清楚的意識到自己真正的職責和應當做的事情。

 

基於目前中國軟體行業的現實，我們當中絕大多數的基層Leader在被提拔為Leader的時候，鮮有人是經過了專門的培訓了的。很多時候，就只是上級一個簡單的任命，一個普通的程式設計師就變成了一個Leader。

 

作為一名Leader，權力，薪酬，責任，都是如同這個職位一樣，可以簡單的隨著上級的任命得到。然而，作為一名Leader所需要的能力，意識，威信和技巧都是不可能這樣簡單得到的。因此，我們可以看到，有相當多的基層Leader們，在剛剛成為Leader的時候，並不知道該如何對待上級和下級，不知道該如何想上級正確的反映實際情況，也不知道該如何領導自己的下屬。並且，因為在實踐當中如果沒有人能提供優秀的指導和範例，所能獲得的經驗和技巧相當有限，所以甚至很多人在已經做了很長時間基層Leader之後，仍然不能夠正確的完成自己的職責。

 

關於如何與上級進行交流，我本人的經驗並不足以教導別人（歡迎各位朋友補充），因此，讓我們只談如何與下屬進行交流。

 

先問一個問題，請問你認為，當你作為一名Leader的時候，你認為你和你的下屬的關係是什麼？是領導和被領導的關係？還是合作的關係？

 

我認為，是合作的關係。當你成為一名Leader的時候，絕不意味著你就此高人一等，下屬都應當無條件服從你。在這裡，我認為應當認為Leader作為團隊的一員，與普通開發人員的區別，應當只是分工不同而已。不錯，Leader是有權力的，但是這種權力應當只能用於工作，而不能用於其他的地方。

 

我並不是說合作的關係正確，領導和被領導的關係錯誤，這取決於每個人的觀念和意識，沒有對錯之分。我只是認為，以合作的意識來處理日常工作中的種種矛盾，會比以領導的身份來處理，對於工作更有好處。

 

當一個人成為Leader，自然而然也就得到了相當的權力。但是權力可以簡單的由上級給予，威信卻不可能這麼簡單的得到。我們都知道，如果要真正成功的領導一個團隊，威信和權力是必不可少的，甚至很多時候，威信的作用還要遠遠的超過權力。特別在軟體開發這種對於團隊成員的主觀能動性有著極大要求的領域裡，威信就更為重要。別忘了，軟體公司並不是軍隊，Leader是有權力，但是並沒有大到可以完全凌駕於他人的意志之上。

 

我就親身體會過一個自視過高的Group Leader，凡事都要拿著架子，總是趾高氣揚，居高凌下的指揮下屬做這個做那個，自己卻從來不做任何實際的工作。在開始的時候，還能唬住大家，一年過去，如今，在他的專案組裡，已經沒有任何人服他，很多時候，即使他提出的意見是正確的，都會遭到大家的抵制和反對。專案組裡人人都想離開，工作中一旦出了問題就只會互相推卸責任，整個專案組分崩離析。

 

因此，從合作的角度來看待自己與下屬的關係，是非常必要的。

 

以此為前提，究竟該如何具體的與下屬進行交流呢？

 

在這方面，我自己確實也有些小小的體會，然而，在人際關係、成功學領域裡，早就已經有若干先賢的著述可供學習，在這裡，我真心誠意的推薦美國著名心靈導師——戴爾卡耐基（Dale Carnegie）的作品。特別是他的《人性的弱點》全集，相信我，如果你沒有看過的話，那麼在如何處理你的人際關係上，它會給你一個全新的世界。我自己在初中時，十年前，就讀過此書，一直受惠至今。這本書並不是專門討論上級和下級的，而是涵蓋了整個人際交往的方方面面，因此，讀過之後，不僅會有助於你做Leader，還會有助於你的整個人際關係。

 

我是程式設計師，不是書販子，因此，請相信我，我是真心的推薦——戴爾卡耐基。需要說明的是，目前市面上的戴爾卡耐基書籍良莠不齊，很多是中國的編者自行刪剪過的，我在這裡推薦兩個版本的，一是中國發展出版社的《人性的弱點全集》，黃色封皮，25元，一是中國檔案出版社的《卡耐基成功勵志全書》，綠色封皮，上下兩冊包含卡耐基全部著作，48元。卡耐基的書其實很多小書店裡就有，相信不難找到。

 

說完交流問題，我們再來看職責問題。

 

Project Manager的職責是什麼？Group Leader的職責又是什麼？我相信每個人都會有自己的理解，同時，也有很多專案管理的書籍，對此有著詳細而明確的定義。在這裡，我只想談談我在實際工作中觀察到的，相當多的Leader身上都存在的誤區。

 

我認為，首先要明確的一點是，身為一名Leader，在開發過程中，也許不會負責任何文件、程式碼等實際的工作，但是，你必須建立起這樣的意識，所有的工作仍然都是你完成的，你必須為你的小組所產生的所有工作成果負責。

 

我知道很多人都不會贊同我的觀點。的確，這看起來不太可能，我們怎麼可能知道每個下屬心裡想什麼，以什麼樣的態度和心情在工作，我們不可能控制的了一件工作到底是如何完成的。別人的怠工，別人的不認真，別人的水平低，不可能輕易的隨著我們的意志而改變，那麼，憑什麼要我們為每一件具體的工作負責？

 

沒錯，我們不可能隨時的每一個下屬，他們也不會完全按照我們的意志和希望去工作，但是，這不是你可以對於具體工作的質量和成果不必承擔責任的理由。其實作為一名Leader，我們每個人當然都希望自己的專案組所產生的每一件工作成果都能夠高效率、高質量的完成，但是，你究竟為此做出了什麼樣的努力呢？

 

我見過不只一個Leader，在他們成為Leader之後，每天所做的工作就只是將工作分成一塊一塊，分發出去，再將成果彙總，向上級報告。如果有了錯誤，就指責該任務的具體負責者；遇到了困難，就強制大家加班，問題解決了才能下班。

 

不錯，這些都是一個Leader應該做的，但是，如果一個Leader的職責就只有這些的話，那麼，你憑什麼拿你高於普通開發人員的薪水？這些工作，一個職業高中或者中專文秘專業畢業的學生足可勝任有餘，而且肯定比你做的還好，為什麼要付那麼多的薪水來讓你做這些事？

 

我認為，管理管理，核心在於管人，而不是管事。事情要管，所有剛才我列舉的工作都是必不可少的，但作為一名Leader，真正重要的是管理你的下屬。

 

我認為，身為一名Leader，必須對於整個專案的狀況，都有全面的掌控。當你分配一項工作給別人的時候，你應當清楚，他大概會如何完成工作，或者說，你必須知道，如果是你自己來負責這項工作，應當如何來做，再或者，也許你自己不知道該如何做，但是你必須確定下屬是知道該如何做的，並且，當下屬在工作中遇到問題和困難的時候，你必須確定他是能夠得到及時的幫助的，不論提供幫助的是你，其他人還是網際網路。總之，你必須對這項工作心中有數。絕對不可以簡簡單單的說，某某，你來做這個，之後就再也不管，直到工作完成或是出現問題的時候你再去關心。

 

同時，你必須確認，每一個下屬在工作中遇到了任何他自己難以解決或解決不好的問題，你都能夠得到及時的反饋，並且馬上想辦法解決問題。

 

也就是說，作為一個Leader，你必須對整個專案進行過程中每一項工作的完成狀況心中有數，你可以不瞭解具體的細節，具體怎樣完成，但是對於這項工作的種種指標，比如工作承擔者是否勝任，工作成果的大概質量，按時完成是否可能，如何提供幫助等等，都要有清楚的瞭解和預見。

 

並且，你必須對於整個專案進行中的重點和難點以及進度保持極度的敏感。每一個下屬所反映的困難和問題，進度的延後，你都必須當作是自己的困難和問題，進度拖延一樣，立即做出反應，馬上和下屬想辦法，把問題解決掉。因為從下屬的角度出發，問題反映給你就代表他自己解決不了或者解決不好，而你作為Leader，指導和幫助下屬解決困難是你的責任。因此，當下屬想你反映問題之後，就會認為他的責任已經盡到了，剩下的要看你怎麼安排，怎麼說了。接下來，對於工作積極性高的程式設計師來說，可能會繼續自己努力去解決問題，但是前面說過，會向上反映的都是自己很難解決的問題，因此自行獲得突破的可能性很小；而對於那些工作積極性不高的程式設計師來說，很可能就會將問題擱置，一直等待你的安排。

 

因此，如果此時你掉以輕心，沒有對下屬反映的問題及時做出反應，那麼問題和困難就會一直擱置，直到有一天你突然發現，馬上就是Deadline，竟然還有一個模組沒完成！於是，我們就又有機會看日出了。所有人員疲憊不堪，整個專案組士氣低落，怨聲載道，而這所有的一切，都是因為你，一個沒有盡到自己責任的Leader的錯誤。

 

這也是為什麼我們經常可以在實際中看到，一個專案開發的前期，往往不那麼緊張，大家都能保持正常的工作作息時間，可是到了後期，卻恨不得一天真的有25個小時。實際上，如果早一點發現問題，解決問題，就能夠把解決問題的時間分攤到整個專案週期中。那麼我們可能只需要每天多工作很短時間，甚至根本不必額外加班，就能夠成功的，甚至更高質量的完成目標。

 

這裡舉一個反面的例子。我曾經參與一個專案，本來一直都覺得進行得很好，程式碼寫完之後沒什麼事，每天悠哉遊哉。可是直到Deadline之前兩天，我才知道，我們需要將若干個使用我們程式碼的守護程式執行起來，而那些守護程式基本上還都無法執行呢！於是一下子變得緊張起來，連續兩個通宵，也沒能讓所有的程式正確的執行，不得不延期出品。並且，因為延期帶來的壓力極大，要求在最短時間內彌補過來，所以所有人繼續超負荷工作，苦不堪言。這毫無疑問是Leader的失職。其中，必須除錯執行若干個程式，Group Leader是知道的，然而他只是簡單的自己除錯了一下，通不過，就把這件事向上反映給了Project Manager，因為Project Manager沒有反應，因此他就將此時擱置，既沒有把這件事告訴下屬，也沒有持續努力去解決問題。而Project Manager作為專案的負責人，卻沒有我前面所說的負責的意識，聽到Group Leader的報告沒有及時做出反應，直到最後發現無法按期交付才開始著急，和開發人員一起去解決具體的技術問題，卻已經晚了。因此，由於這兩級Leader的失誤，導致了專案無法按期完成，受到了客戶嚴厲的批評。同時，大量的超時工作導致開發人員士氣極度低落，有兩名開發人員因此離開了團隊。

 

讓我們想象一下，在這個例子中，如果Group Leader在意識到問題的同時，能夠意識到問題的重要性，不但反映給上級，同時也馬上提醒所有的下屬，組織大家一起來想辦法，解決問題；如果Project Manager在接到報告的時候立刻做出反應，要求必須解決這個問題，並提供各種技術支援手段...這兩層Leader中有任何一個盡到了自己的責任，就能夠把解決問題的時間分攤到一個很長的時段，既可以保證按期交付，又能夠避免大量的超時工作。

 

我想再強調一遍，我認為，那些只是簡單的分發任務，收回工作成果，完成一些事務性的工作比如填表格，開會，出了問題就只會追究實際承擔工作者的責任，自身對於具體的工作，重點和難點，既不瞭解也不想了解的Leader，一箇中等專業學校文秘專業畢業的學生會比他乾的出色的多。一個這樣的Leader，根本就對不起他的那超出普通開發人員的工資，甚至，他應該拿的，還應該遠遠少於普通開發人員才對。

 

最後要說的就是，在實際工作中，我還發現很多Leader都有一種等級意識，認為自己高普通開發人員一等。這種等級意識往往表現為毫無必要的對很多應該公開或分享的資訊保密。在實際工作中，老是搞的神神秘秘的，覺得知道一些普通開發人員不知道的情況就很有優越感。

 

我並不是說每件事情都應該公開，但是，我認為，至少，對於具體負責某項工作的下屬，如果沒有特別要求的話，你應當確保對於這項工作，負責的下屬知道的至少和你一樣多。你必須確保，負責實際工作的開發人員，對於他所負責的工作，完全清楚其重要性，並且確實知道他應該做哪些事情。在這方面保持神秘沒有任何好處。不然，最終工作完成的速度，質量以及內容，就很可能跟你期望的，理解的有著極大偏差。

 

以上，就是我對於基層Leader這個位置所進行的觀察和做出的反思。

 

最後，讓我們再來看看比較高的位置，部門經理，以及更高層的管理者。

 

當然，我自己沒有做過這些位置，因此，我所提供的，只是作為一個普通開發人員所看到的，想到的意見。未在其位，未謀過其政，很多地方看起來可能比較像，還請多多批評指正。

 

第一，企業應當有意識的培養和招募人才。

 

這句話聽起來是廢話，但是在這裡，我的意思與一般所認為的稍有不同。

 

我所說的人才，指的不僅僅是處於管理和技術金字塔頂峰的少數大牛。有意識的培養和招募人才，指的也不是我們經常可以在報章上看到的某某公司招募了某某大牛做總裁，或者某某少帥執掌某某公司。

 

我所說的人才，指的是構成整個軟體產業大廈的一塊塊普通磚頭，一條條普通鋼筋。或者說，我指的是軟體產業這張網上的絡。離開了絡，網就只是一堆繩子，同樣，離開了一個個的專案經理，技術高手，也就沒有了軟體產業。

 

前面說了那麼多專案經理的壞話，實際上，很大程度上，那並不是專案經理們自己的責任。我們都知道，如果沒有外來的，先進的，理論上的指導，沒有一個好的環境，只靠一個人在實踐中摸索，其成長和進步是極其有限的。因此作為高層管理者，必須有意識的培養有經驗有能力的中層管理人員。

 

當然，我完全明白我的這種願望在現實中實行起來有多麼的困難，軟體公司的人員流動率足以打消任何老闆在員工身上投資的願望。但是，我認為，困難並不是我們不做某件好事的理由，只要我們有足夠的誠意和努力，我們所收穫的一定遠遠超出我們所付出的。

 

第二，在實際工作中，要注意，不要讓歪嘴和尚念壞了好經。

 

軟體開發公司可以說是目前中國學習熱情最高，實際行動也最高的群體，因此，在實際的工作中，我們其實已經有了很多好的管理，技術等方面的好的原則，方法和技巧。但是，我在實踐中經常發現，明明有很多好經，卻被歪嘴和尚們出於種種的目的念壞了。

 

這裡僅舉一例。我們都知道當工作中出現問題和失誤的時候，應當進行總結和檢討。這個時候，每個人都應當提出自己的意見和見解，進行批評和自我批評，並且，應當以自我批評開始，先找自身的失誤，再批評別人。這個原則是正確的，沒有問題的，我們確實應當如此。

 

但是，在現實中，我們經常可以看到，即使主要是管理者們的失誤導致工作中的問題，但是在檢討中，往往大大小小的管理者都會讓最基層的開發人員開始檢討，還要求他們主要先找自己的問題。OK，這樣好了，每個基層開發人員明明責任很小，卻不得不違心的把自己的種種小錯誤放大，自己自己，不得不承擔失誤的主要責任。而任何對於真正的失誤和責任的討論，都會遭到管理者的斥責，被認為是不虛心，沒有誠意。然後，基層開發人員檢討完了，管理者再敷衍兩句，因為基層開發人員都已經不得已的攬下了大部份責任，管理者不但不必再檢討自身，反而可以大肆批評基層開發人員。於是，我們不但無法發現工作中真正的失誤在哪裡，還會極其嚴重的打擊開發人員計程車氣。

 

批評和自我批評這個我黨自我建設的法寶，就這樣生生的被扭轉到了反面。在實際工作中，還有很多類似這樣的好經，不僅包括管理經驗和方法，還包括很多品質管理辦法，過程改進方法，都被生生的唱歪。因此，我認為，身為高層管理者，必須要注意，本部門，本公司所實行的種種規則，是否是真的在起到它應有的作用，還是已經走向了它的反面。

 

最後，我想說的一點就是，不勞無獲。很多管理者，在推行好的措施，方法和規則的時候，往往容易就只是開個會，提出目標，要求大家努力，然後就等待收穫了。可是，既然你都沒有為達成這個目標付出過任何專門的努力，那麼你又怎麼希望最終這個目標成功達成呢？

 

再舉一例，公司的最高領導者提出要求，要求BUG率達到若干個/千行，然而卻沒有具體的針對這個目標提出什麼措施，只是簡單的要求中層管理者，中層管理者再去要求基層管理者，基層管理者只好和開發人員一起自己瞎鼓搗。這樣如何能保證最終達到目標？如果高層施加的壓力很大，基層就會偽造資料來達到要求。

 

我認為，管理者必須務實，提出目標，還必須根據目標來具體的制定計劃，拿出辦法，一步步的引導著人們達成目標。還是那句話，沒有努力就不要指望有收穫。

 

對高層管理者的意見就到此結束。

 

本篇對於開發過程中的各個位置都提出了意見和看法。在下一篇當中，將會討論目前中國軟體產業的前景以及程式設計師的職業生涯，來作為本文的終章，多謝關注。