問：我們現在可以開始編碼了，這是我們最擅長的事情，那麼在這個環節我們該注意些什麼呢？
答：在《業務開發小組》一節中我就講到，業務組長在設計功能時就要思考這個功能是不是一個其他小組也要用的功能。
這樣思考帶來的好處就是：
1大家在協同。大家的心在往一塊想，這會產生很奇妙的團隊反應
2大家不用重新每個小組都寫一塊，工作進度加快了
3由於都交給了技術大牛領導的公共功能開發組，而這個組又都是技術非常好的人，所以寫代碼快，寫代碼的質量也高。這就意味着通用功能越多，我們的質量越穩定，性能越好，開發進度越快。
而且在開發過程中，必須在下午5：30下班前把源代碼上傳到服務器上。
這不僅僅表明，這些是你的工作結果，這也表明，這是公司的財產，而不是你個人的。
我們知道，開發過程是長達1-2月甚至更長，有時候我們在寫一些內部功能，而老闆非常擔心他的錢是否被你們拿去打了水漂，他找不到有效的監控辦法，那麼他肯定會派來一個他信任的人天天監督你們，而你們也覺得受到了不信任，因此裂痕從此產生。
爲了避免出現這樣的結果，爲了雙方都有一個好的合作環境，那麼開發部也必須天天把代碼上傳到服務器上。
即使老闆不明白代碼，也看不到功能界面，至少他每天看到BUG管理系統中的工作進度，工作質量，任務分配，超期任務，每天的BUG，他就放心一半。你再把服務器上的代碼量給他看，他更高興，因爲實實在在他看到了你在工作，你的工作成果在服務器上，而不是控制在某個人的手裏。
依照我講的這種開發過程模式，測試是不可能像微軟那樣做到每日編譯代碼每日測試。因爲，在你們這樣十來個人七八條槍的的公司，不可能做到這個規格。我們要看清我們的現實，所以我們也找到了我們合適的方法，雖然有缺憾，但是我們至少能做到我們所能做到的最好。
我們能達到的測試就是1周後測試。因爲在1周內，代碼會不斷變化，代碼也可能寫了一半功能，代碼可能沒有界面，這樣測試人員無法測試。1周後，基本一個功能也出來了，也就能測試了。不過具體多長時間要由每個具體的功能複雜度來決定。不用盯死在1周的基準。這是方法，不是基準。
由於不斷能測試，不斷有新成果新界面出來，老闆放心，開心，所以老闆也越來越支持你們。萬金油也需要不斷把老闆的支持態度和新功能展示給其他部門，得到更多人的支持和關注。