項目的討論
精確的項目目標
作爲主管，值得你好好花時間去設定你的項目目標。目標定下來之後，你就會清楚哪些工作該做，那些工作不該做。例如你是基礎函數庫的主管，如果你確定了“只有所有模塊都使用的函數纔是要開發的函數”的原則，那麼某個模塊要求你開發的工作，就不是你的目標了。
每天花10－15分鐘想想目標，並且想些解決的小竅門。例如作者某天是這樣想的：
Diego負責該函數的開發，有可能需要一本技術手冊。
於是他馬上去買了一本。
就這樣，明確項目目標，提前把影響程序員專心工作的障礙（包括不必要的會議，email，電話等）一一去除。主管才能把項目做好。
開會與報告
有些會是不得不開的。例如：
1 當某個人必須把信息傳送給很多人時。
2 信息需要雙向或多向交流，人們必須立即反問才能瞭解信息。
3 必須親眼目睹或親身經歷，信息才能傳達給接受者，如產品示例。
4 有些事情須通過討論才能進行。
但開會中斷許多人的工作。所以在開會之前，你必須動腦筋想想，你開會的目的是什麼，有沒有更好的方法達到同樣目的。
會議時間應選擇工作效率比較低的時段，並且不會打擾程序員順序連續工作時間的時段爲宜，例如早上剛開始上班，下午剛開始上班，快下班時。特別的，如果可以選擇的話，在星期一早上或星期五下午開會。這是最沒效率的兩個時段。
如果會議確實召開了。一定要達到目的。即使是假設性的，有條件的結論。例如，如果其他小組的工作依賴於Diego的工作成果，那麼你可以問Diego：“兩個星期能完成你的工作吧？”如果他同意了，那麼以此假定作爲基礎和其他小組討論工作，例如進度安排等。
作爲主管，避免在會後讓與會者遞交一份長長的發言報告。這是雙重浪費時間。如果你覺得他們的發言值得記，那麼你自己記下來。再次強調，寫無用的報告浪費開發人員時間。如果你確實要報告，最好單獨進行，並且儘量短。
進度
微軟曾有過慘痛的教訓，以進度作爲項目完成的指導。任何進度落後都是不允許的，bug的不斷增加不算嚴重問題，但只要工作沒在排定的時間內完成，就是罪孽深重的。進度取代了項目目標和軟件質量，變成了首要任務，每一個人都在瘋狂的趕進度。
以Mac Excel項目爲例，每週的進度檢討加上報告，是微軟用來控制進度的主要手段。除了這些，開發人員害得每週和測試文件人員共同檢討原因和落後狀況。可想而知，只要進度落後，文件小組和測試人員只好暫時沒事做，所有目光和談話，都集中在你的程序進度落後上了。
每週經理們會用更新的項目進度報告來更新項目總進度表，然後分發給組員。於是你一眼就會看到本週落後了多少，整個項目因此落後了多少。心痛之餘，你翻到後頁看看還有多少未完成的工作，上週是幾百項，現在還是幾百項，拼命做事，結果似乎毫無進展。就像一個笑話：如果你每次咬一小口，多久才能啃完一隻大象？這張進度表就是一隻大象，我們一輩子也無法吃完。
實在是太過分強調進度了。以至於無論我們做了多少了不起的事情，都沒有半點成就感。我們被落後的威脅淹沒了，再怎麼努力，也看不到成功的彼岸。這不是工作本身的問題，實在是那種絕望無力的感覺所致。
更荒唐的是，進度表是基於如下原則設定的：
1 爲期兩年的項目所有該做的事情都在進度表中，沒有任何遺漏。
2 每人每週實際工作時間40小時。
3 對於每件工作的時間估計完全準確。
4 所有程序第一次出來就是完美狀態，沒有bug，不需修改。
這真是天方夜談。
教訓：不要利用進程表來驅使項目前進，這實在太傷害小組士氣了。
在這裏，作者提出了他自己的觀點：不應該deadline快到了纔開始緊張，平時就應該保持適當的緊張狀態。多想想如何聰明的工作，不要把時間浪費在沒有價值的工作上，不要浪費別人的時間，用積極的態度推動項目。總之，不應該在dealine快到來時，才動腦筋去想解決辦法。平時就應該養成良好的工作習慣。
如果你覺得時間緊迫，那麼你開會總結一定不會說：“這個問題，我們留待以後再討論……”你和組員一定無法容忍事情的拖拉，要不刪除這項工作，要不立刻把它完成。
進度的急迫多數是由於不正確的考慮，不正確的工作方式所導致。如果你定的日程表讓組員產生了落後恐懼症，爲了趕上期限而犧牲了產品質量，那麼該檢討的是這個進度表而不是組員。如果你定出的日程表是個無法完成的目標，那只不過是打擊團隊士氣。一旦組員發覺已深陷絕境，那你就永遠無法讓他們表現出最佳狀態。他們就會另某高就，找個是人做的工作。
項目控制
在完成對進度的討論之後，作者提出了他對項目控制的見解：
1 進度是基於某些因素上軟件的大致完成日期。不要迷信它。不要草率定出不可能的期限，導致組員爲了趕進度而不顧一切。
2 把長期的大項目，分成幾個完整而獨立的小項目，各小項目必須有一個主題。這樣既能營造適當的緊迫氣氛，也讓大家有完成目標的成就感。
3 制定測試和質量監控規範，這些規範可能涉及產品的速度，健壯性，安全性等，你必須考慮並定出標準。通過質量檢測規範的小項目，纔算真正完成。警惕，不要把小項目寫成hello world之類毫無意義的測試程序。該有的功能絕對要有，該達到的要求絕對要達到。
4 產品的質量遠比期限要重要。發現bug立刻清除。你不會知道一個bug到底有多嚴重，存在bug的軟件產品，會讓項目的完成比例被嚴重高估。更壞的情況下，由於bug的存在，你會不知道項目究竟什麼時候能完成。
加班
如果進度落後，那表示有個地方出錯了。在沒有找到問題並解決之前，不要粗暴的要求組員加班。這種加班是沒有用的。
如果你以進度落後爲由，強迫組員每天工作12小時。那麼他們很可能把私人活動也安排到工作時間裏，並且在可能輕鬆的時刻儘可能偷懶。因爲他知道每天必定工作12小時，不妨把私人活動如看新聞等也在上班時完成。加班，通常是浪費時間的面具。
事實上，拼命工作並不是成功的關鍵，成功的關鍵是有一個明確的目標，具體而切合實際的計劃，以及每天不斷的向這個目標邁進。
(微軟不強制員工的上班時間，所以作者如此討論。但事實上，在中國，加班一樣是最沒有效率的控制項目的方式。即使你強迫員工每天12小時坐在電腦前，他也很有可能面對屏幕發楞。疲倦的頭腦是不可能產生任何創造性活動的。)
加班的目的只是爲了趕上進度而已。爲了改善我們的工作，還有許多手段可以達到這個目的：
1 明確工作目標：程序員是不是被太多的雜務打亂了開發工作？例如不必要的email，不必要的電話、討論、會議。作爲主管，你有責任把這些障礙找到並一一清除，還程序員一個專心開發的環境。
2 合理安排工作：例如，看email應該在早上，中午，快下班時看，不要在開發過程中讓它打亂了你的思路。早上是最有效率的時候，讓頭腦完成有創意的工作，而其他時間用來編碼等等。
再一次強調，你必須牢記自己的目標：按進度完成項目並讓組員成長。只要你開動腦筋，你一定能想到更好的代替加班的方法來達到目的。加班並不是完成這個目標的唯一手段，事實上它是最差的，能不能趕上進度且不說，肯定妨礙了組員的成長。它並不是你的救命稻草，如果你依靠加班來完成你的管理工作，或者你該考慮走人了。
項目檢討
對項目進行檢討總結的意義不言而喻。但要避免大而無當的總結。檢討應該能做到：
1 指出項目的問題所在
2 根據問題，考慮防範措施和實際的解決辦法（雖然有可能只是建議）
3 總結經驗心得。將來如何利用。
以下是一個例子，給出了兩個項目檢討的對比：
第一個：
問題：某軟件包的Beta版使用者覺得他們的測試報告好像沒人注意。因爲bug在每一版都出現，這主要是因爲我們沒有建立一套系統的方法去追蹤外部的Beta測試報告。所以我們將來應更小心的追蹤外部的Beta測試報告，並加強後續處理。
第二個：
由於對β測試報告的疏忽。不僅影響了項目，也影響了關聯的其他項目。經理已經同意重新考慮三個追蹤Bug的系統，我們將在三者中擇一使用，以便追蹤項目的測試報告，我們還要把bug和清除bug的行動記錄下來。
這個報告是很有效的。他提出了清楚的解決方案，詳細的執行步驟，由誰負責，什麼時候該完成，應用在哪幾個項目。還建議了bug的查找方式。
值得一提的是，不要等項目結束了纔想什麼是值得一寫的。應該養成平時經常記錄的好習慣，積累是隨時的。
管理藝術
評估方式
年終評估是最沒用的評估。對員工的評估應該隨時的進行。員工有什麼不足應該立即指出，併爲他儘量想個改善的方法，讓他能立刻成長。不要單純在年終評估記錄員工的不足。
溝通技巧
有些員工看起來很依賴主管解決問題，其實不過是他們的溝通方式有問題。碰到這種員工，你可以要求他們：
1 清晰表達他們待解決問題是什麼
2 有什麼解決方法，包括他贊同的和否決的
3 陳述贊同和否決的理由。
這樣下來，通過和員工多次溝通，或者你會發現你的員工並不笨，他們只是不懂得溝通技巧而已。
一句話，你和員工的一起成長是你的目標之一，所以不要採用生硬粗暴的方式去對待員工。動腦筋想些更好的法子。
人員培養
態度正確
你必須讓你的組員態度正確。
1 發現bug立刻清除。越晚抓bug越難抓，並且能讓程序員總結經驗。還有，如果bug太多，那麼程序員的功力高下立現。
2 除非我已經完全測試過了，沒有bug了，否則程序不算完工。
3 以用戶的觀點來看待軟件，盡善盡美。
4 改正“這不可能”的態度。最好的方法是明確目標，然後找出正確的解決方案。
5 鼓勵提問。他可能不知道答案，但他有權提出問題。
6 未完成的功能，絕對不要給用戶。
7 善於利用別人的成果。寫好的測試過的代碼，只要符合自己要求，就應該用。重複就是浪費。
8 注意提高自己代碼的複用性。
提高技術
如果某個程序員在你的項目已經毫無進步，並且他渴望提高，那麼讓他到其他項目去吧，讓其他接他的班。短期來看你損失了一個得力干將，長期來看，你爲公司培養了兩個人才。
新兵訓練：先讓新人學會一些通用性技術，這樣他到其他項目組也能用。然後才讓他們學會項目專有的技能。訓練他們多思考。在設計階段，他們要想得很縝密，確定這樣的設計沒有紕漏，寫程序時要動腦筋，要懂得怎麼思考怎麼測試這個程序才確保沒有bug；遇到bug時，不要亂猜，要思考如何有系統的搜尋bug藏身之處，要學會判斷是否有相關bug沒有現身；不但要學習如何對付bug，還要思考如何在一開始寫程序時就避免它的發生。同時要了解這一行業新知識不斷而至，他必須不斷學習提高，才能跟上產業的步伐。
工作價值
讓組員明白，單純的工作時間是不能衡量員工價值的，程序員對項目的貢獻在於：
1 指出我們在哪裏浪費了人力？
2 有什麼地方可以引用別組的程序代碼？
3 有什麼自動測試程序的好主意？
4 想到一個符合用戶使用習慣的界面？
等等諸如此類。簡而言之，你必須開動腦筋定下規則，鼓勵員工學習新的技術，養成好的工作習慣，做事更有效率，從而加快項目的進程。而不是用單純工作時間來判斷員工價值。