1. 你們的項目組使用源代碼管理工具了么？
應該用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的選擇是VSS。
2. 你們的項目組使用缺陷管理系統了么？
應該用。ClearQuest太復雜，我的推薦是BugZilla。 
3. 你們的測試組還在用Word寫測試用例么？
不要用Word寫測試用例（Test Case）。應該用一個專門的系統，可以是Test Manager，也可以是自己開發一個ASP.NET的小網站。主要目的是Track和Browse。 
4. 你們的項目組有沒有建立一個門戶網站？
要有一個門戶網站，用來放Contact Info、Baselined Schedule、News等等。推薦Sharepoint Portal Server 2003來實現，15分鐘就搞定。買不起SPS 2003可以用WSS (Windows Sharepoint Service)。 
5. 你們的項目組用了你能買到最好的工具么？
應該用盡量好的工具來工作。比如，應該用VS.NET而不是Notepad來寫C#。用Notepad寫程序多半只是一種炫耀。但也要考慮到經費，所以說是“你能買到最好的”。 
6. 你們的程序員工作在安靜的環境里么？
需要安靜環境。這點極端重要，而且要保證每個人的空間大于一定面積。 
7. 你們的員工每個人都有一部電話么？需要每人一部電話。而且電話最好是帶留言功能的。當然，上這么一套帶留言電話系統開銷不小。不過至少每人一部電話要有，千萬別搞得經常有人站起來喊：“某某某電話”。《人件》里面就強烈譴責這種做法。 
8. 你們每個人都知道出了問題應該找誰么？
應該知道。任何一個Feature至少都應該有一個Owner，當然，Owner可以繼續Dispatch給其他人。
9. 你遇到過有人說“我以為…”么？
要消滅“我以為”。Never assume anything。 
10. 你們的項目組中所有的人都坐在一起么？
需要。我反對Virtual Team，也反對Dev在美國、Test在中國這種開發方式。能坐在一起就最好坐在一起，好處多得不得了。 
11. 你們的進度表是否反映最新開發進展情況？ 
應該反映。但是，應該用Baseline的方法來管理進度表：維護一份穩定的Schedule，再維護一份最新更改。Baseline的方法也應該用于其它的Spec。Baseline是變更管理里面的一個重要手段。
12. 你們的工作量是先由每個人自己估算的么？
應該讓每個人自己估算。要從下而上估算工作量，而不是從上往下分派。除非有其他原因，比如政治任務工期固定等。 
13. 你們的開發人員從項目一開始就加班么？
不要這樣。不要一開始就搞疲勞戰。從項目一開始就加班，只能說明項目進度不合理。當然，一些對日軟件外包必須天天加班，那屬于剝削的范疇。 
14. 你們的項目計劃中Buffer Time是加在每個小任務后面的么？
不要。Buffer Time加在每個小任務后面，很容易輕易的就被消耗掉。Buffer Time要整段的加在一個Milestone或者checkpoint前面。 
15. 值得再多花一些時間，從95%做到100%好值得，非常值得。
尤其當項目后期人困馬乏的時候，要堅持。這會給產品帶來質的區別。 
16. 登記新缺陷時，是否寫清了重現步驟？
要。這屬于Dev和Test之間的溝通手段。面對面溝通需要，詳細填寫Repro Steps也需要。 
17. 寫新代碼前會把已知缺陷解決么？要。每個人的缺陷不能超過10個或15個，否則必須先解決老的bug才能繼續寫新代碼。 
18. 你們對缺陷的輕重緩急有事先的約定么？
必須有定義。Severity要分1、2、3，約定好：藍屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但這種約定可以根據產品質量現狀適當進行調整。
19. 你們對意見不一的缺陷有三國會議么？必須要有。要有一個明確的決策過程。這類似于CCB (Change Control Board)的概念。 
20. 所有的缺陷都是由登記的人最后關閉的么？ 
Bug應該由Opener關閉。Dev不能私自關閉Bug。 
21. 你們的程序員厭惡修改老