這一篇中的章節討論軟體專案經理如何管理手下的程式設計師。
絕大多數軟體經理有一種特別不好的習慣：總是把人當作模組元件來管理。這種習慣的起源可能是軟體經理在作為技術人員期間接受了很好的「模組化」的薰陶，因此當他們成為管理人員之後，這種「模組化」的思維也慣性地成為了他們的管理方式。
不幸的是：這種方法並不有效。我們將在本篇中討論管理程式設計師的「非模組化」方法。
絕大多數以失敗告終的軟體專案，其失敗的原因不是技術水平不夠，那麼這些專案的失敗原因又是什麼呢？
本質上，軟體經理工作中的主要問題，不是技術問題，而是社會學（
sociology
）問題。基於這樣的觀察，軟體經理最應該花時間關注的是「人」的方面的問題，而不是「技術」方面的問題。軟體經理把精力錯誤地集中於技術方面，而不是人際關係方面的主要原因，不是因為技術方面更重要，而是因為它更容易做。人際關係是很複雜的，並且就其效果而言也並不明晰清楚，但是它卻是軟體經理工作中最重要的方面。
軟體經理只有把關注點放在「人員」方面，而不是「技術」方面，才是在工作中真正走上了正道。
軟體業和傳統製造業有根本的不同，因此管理軟體工程師的方式與管理產業工作的方式也有天壤之別，兩者甚至是截然相反。下面的**表明了兩種管理方式的巨大差異。
傳統製造業的經理這麼做
（優秀的）軟體業的經理則這麼做
不允許員工犯錯，因為任何形式的錯誤都會導致整個組織運營效率的下降。
營造允許員工犯錯的氛圍。對於腦力勞動者而言，偶爾犯乙個錯誤是自然的，也是他們工作的乙個健康組成部分。沒人犯錯只能說明沒人敢於嘗試。出現問題，不要責備，而是弄清原因。
採取強硬手段迫使員工工作，而不是偷懶耍滑。
很少需要嚴厲的措施來迫使員工工作。軟體工程師大多是熱愛工作並且自我激勵的。軟體經理甚至需要採取措施讓員工少做些工作，從而做更有意義的工作。
漠視個體員工的個性，把所有員工視為可拆換的機器零件一樣看待。
理解每位員工都是乙個不可複製和替換的獨特個體，充分尊重每位員工培養其獨特性的舉動，而不會視其為對自己權威的挑戰和威脅。
力爭讓生產系統處於穩定狀態。
軟體專案沒有「穩定狀態」這個概念，否則就只是死水一潭。軟體專案需要的是參與人員全都融入專案和團隊，給團隊帶來活力，讓專案持續推進。軟體經理的職責就是尋找到恰當的凝聚劑和催化劑，讓團隊成員凝聚在專案周圍，充滿樂趣地工作。
消滅思考。員工不需要考慮任何與工作有關的事情，只要照指令行事把任務完成就行。
鼓勵員工多花點時間來思考工作本身，而不要只埋頭苦幹。必要時，通過做些頭腦風暴、培訓、閱讀活動、知識分享等來幫助員工開啟思路和視野。
強迫手下的程式設計師在沒有工資的情況下加班加點地工作，這是軟體經理容易犯的乙個錯誤。軟體經理對此最愛用的藉口就是專案進度異常緊張，而按時交付又異常重要。
有許多理由可以證明這種「脅迫員工更努力、更長時間工作」的做法是完全錯誤的：
l員工可以加班，但是其後果是那總伴隨著乙個相等時段的補償性「減班」，比如員工會打**、閒談、甚至乾脆就是請假休息。
l要求員工加班加點完成工作，這本身並不是在提高生產力，而只是一種剝削和榨取。一旦員工明白過來，他就會離開團隊，這才是團隊最大的損失。
l用乙個本就不可能按時完成的進度表來給員工施壓，這樣的結果不是讓員工工作得更好，只是讓他們工作得更快。
人都有一種強烈的傾向，就是把我們的自尊同我們生產的產品的「質量」聯絡在一起。因此，產品的生產者傾向於強調他們自己的質量標準，而對於產品的購買者，由於產品質量並不同其自尊心掛鉤，因此購買者的質量標準往往會低於生產者的質量標準。
把這種現象投射到軟體業上，軟體工程師對軟體產品的品質要求往往會高於市場標準。那麼，軟體經理應該站在哪一邊呢？是鼓勵員工追求卓越品質，還是向較低的市場標準妥協？
有若干理由表明軟體經理應該站在員工一邊：
l對高品質的追求將帶來更高的生產力水平，而這種更高的生產力水平將使公司長久受益。
l如果於外部壓力（如乙個本就無法完成的進度表）而要求員工犧牲品質，這實際上是在傷害員工的自尊，這會導致員工產生直接反對你的情緒，進而引起人才流失。
因此，明智的軟體經理會這樣做：
l在團隊內部，樹立質量意識，鼓勵員工追求卓越的產品品質並交付令他們自身滿意的產品。對本身具有較強品質意識的程式設計師加以獎勵和宣傳，從而讓團隊中的所有成員知道團隊最看重的是「質量」而不是「速度」。
l對外，頂住進度表等外界壓力，讓團隊成員與這些壓力盡量隔離。
帕金森定律認為：無論給予乙個專案多少時間，參與專案的人員總是會拖拖拉拉地將時間耗完，直到最後一刻才完工。帕金森定律帶給管理者的啟示是：給專案制定乙個盡最大可能短的交付時間，然後在這期間催促專案人員拼命趕工。
對於軟體行業而言，帕金森定律幾乎總是不適用的。為什麼？因為程式設計師大都熱愛工作，大都不需要外界的驅使和命令就會努力工作。因此，如果軟體經理不分青紅皂白就給專案制定乙個緊張的進度表，然後拼命催促程式設計師完成任務，那麼專案的進展很可能不會太順利。
讓我們用新南威爾斯大學的研究資料來說明問題。
制定專案進度表的方式
專案的生產力
由軟體經理單獨制定
6.6
由軟體經理和程式設計師共同制定
7.8
由程式設計師單獨制定
8.0
由系統分析師制定
9.5
由這張**，我們看出：軟體經理不參與專案進度表的制定，而把專案進度制定交給程式設計師或系統分析師，這樣的專案的生產力水平會比較高。這就說明：如果程式設計師試圖實現由他們自己所制定的目標，那他們就會更加努力地工作。
這份研究的最令人驚訝的部分是**的最後一行：
制定專案進度表的方式
專案的生產力
由軟體經理單獨制定
6.6
由軟體經理和程式設計師共同制定
7.8
由程式設計師單獨制定
8.0
由系統分析師制定
9.5
不制定專案進度表
12.0
換句話說：軟體經理不給專案施加任何進度上的壓力，這樣的專案反而具有最高的生產力。這就告訴我們：軟體經理如果能夠對外頂住進度上的壓力，為團隊營造出不趕進度的氛圍，那麼這樣的團隊反而能創造出很高的生產力。
軟體經理為了提高團隊的生產力可謂是殫精竭慮。但是，軟體經理必須把握住根本方向：處理好團隊中的「人」的方面的問題，讓員工願意工作，而不是強迫員工工作，這才是管理的精髓。
此外，也有一些技術方面的手段可以提高團隊的生產力。比如啟用一套更合適的開發流程，換用一種更強大的開發環境和開發工具，使用新的程式語言。但是，這些技術方面的手段不應該是軟體經理的主要考慮方面，只有團隊中的「人」，才是軟體經理最應該關注的。
人件讀書筆記之一
想象 下 乙個沒有真正技術創新的專案正在滑向失敗的深應收賬款程式不過是乙個 重 明的輪子 經驗老到的開發人員面對這樣的專案總能駕輕就熟 即使如此，有時在專案中付出的努力卻南輾北轍，最終將專案推向失敗 假設其中乙個走向崩潰的專案結束，並邀請你前往會診 當然，這事兒永遠不會發生，我們這個行業自有一條金科...
Shell學習筆記之一
1.先看乙個常用的命令 這個命令組合了幾個不同的shell命令，shell命令是有這種特性在裡面的。就是統一性，簡單性。可以通過管道命令組合多個shell命令。如上面的命令，分別是 顯示當前執行的程序，sort是對程序進行排序，uniq是去除重複的情況，grep v sh 是去掉，不展示sh這個程序...
SQLite學習筆記之一
2010年sqlite學習筆記之一 官方站點 從 的download頁面獲取 download.html sqlite amalgamation 3 6 22.zip是sqlite的windows下原始碼檔案 sqlite 3 6 22.zip sqlitedll 3 6 22.zip 在sqlit...