要有。當老闆問起這個產品目前質量如何，
test lead/manager
應該負責回答。
56.
你們有單元測試麼？
單元測試要有的。不過沒有單元測試也不是不可以，我做過沒有單元測試的專案，也做成功了——可能是僥倖，可能是大家都是熟手的關係。還是那句話，軟體工程是非常實踐、非常工程、非常靈活的一套方法，某些方法在某些情況下會比另一些方法好，反之亦然。
57.
你們的程式設計師是寫完**就扔過牆的麼？
大忌。寫好一塊程式以後，即便不做單元測試，也應該自己先跑一跑。雖然有了專門的測試人員，做開發的人也不可以一點測試都不做。微軟還有
test release document
的說法，程式太爛的話，測試有權踢回去。
58.
你們的程式中所有的函式都有輸入檢查麼？
不要。雖然說做輸入檢查是
write secure code
的要點，但不要做太多的輸入檢查，有些內部函式之間的引數傳遞就不必檢查輸入了，省點功夫。同樣的道理，未必要給所有的函式都寫注釋。寫一部分主要的就夠了。
59.
產品有統一的錯誤處理機制和報錯介面麼？
要有。最好能有統一的
error message
，然後每個
error message
都帶乙個
error number
。這樣，使用者可以自己根據
error number
到user manual
裡面去看看錯誤的具體描述和可能原因，就像
sql server
的錯誤那樣。同樣，
asp.net
也要有統一的
exception
處理。可以參考有關的
。60.
你們有統一的**書寫規範麼？
要這樣。要有設計才能開發，這是必須的。設計文件，應該說清楚這個產品會怎麼執行，應該採取一些講故事的方法。設計的時候千萬別鑽細節，別鑽到資料庫、**等具體實現裡面去，那些是後面的事情，一步步來不能著急。
67.
開始開發和測試之前每個人都仔細審閱功能設計麼？
要做。function spec review
是用來統一思想的。而且，
review
過以後形成了一致意見，將來再也沒有人可以說「你看，當初我就是反對這麼設計的，現在吃苦頭了吧」
68.
所有人都始終想著
the whole image
麼？
要這樣。專案裡面每個人雖然都只是在製造一片葉子，但每個人都應該知道自己在製造的那片葉子所在的樹是怎麼樣子的。我反對軟體藍領，反對過分的把軟體製造看成流水線、車間。參見第
61條。
69. dev
工作的劃分是單純縱向或橫向的麼？
不能單純的根據功能模組分，或者單純根據表現層、中間層、資料庫層分。我推薦這麼做：首先根據功能模組分，然後每個「層」都有乙個
owner
來review
所有人的設計和**，保證
consistency
。70.
你們的程式設計師寫程式設計說明文件麼？
要。不過我聽說微軟的程式設計師
1999
年以前也不寫。所以說，寫不寫也不是絕對的，偷懶有時候也是可以的。參見第
56條。
71.
你在招人面試時讓他寫一段程式麼？
要的。我最喜歡讓人做字串和鍊錶一類的題目。這種題目有很多迴圈、判斷、指標、
遞迴等，既不偏向過於考演算法，也不偏向過於考特定的
api。
72.
你們有沒有技術交流講座？
要的。每一兩個禮拜搞一次內部的
tech talk
或者chalk talk
吧。讓組員之間分享技術心得，這筆花錢送到外面去培訓划算。
73.
你們的程式設計師都能專注於一件事情麼？
要讓程式設計師專注一件事。例如說，乙個部門有兩個專案和
10個人，一種方法是讓
10個人同時參加兩個專案，每個專案上每個人都花
50%時間；另一種方法是
5個人去專案a，
5個人去專案
b，每個人都
100%
在某乙個專案上。我一定選後面一種。這個道理很多人都懂，但很多領導實踐起來就把屬下當成可以任意拆分的資源了。
74.
你們的程式設計師會誇大完成某項工作所需要的時間麼？
會的，這是常見的，尤其會在專案後期誇大做某個
change
所需要的時間，以次來抵制
change
。解決的方法是坐下來慢慢磨，磨掉程式設計師的逆反心理，一起分析，並把估算時間的顆粒度變小。
75.
盡量不要用
virtual heads
最好不要用
virtual heads
。
virtual heads
意味著resource is not secure
，shared resource
會降低resource
的工作效率，容易增加出錯的機會，會讓一心二用的人沒有太多時間去
review spec
、review design
。乙個dedicated
的人，要強過兩個只能投入
50%時間和精力的人。我是吃過虧的：7個
part time
的tester
，發現的
bug和幹的活，加起來還不如兩個
full-time
的。參見第
73條。
73條是針對程式設計師的，75條是針對resource manager的。
專案管理75條
我現在做的專案是採用如下方法管理的 bd 基礎設計。在這個文件裡，我們把程式的介面全部畫出來 介面上的功能全部描述完整。如 乙個查詢介面的條件是什麼，查詢出來的結果如何顯示等等。fd 功能設計。在這個文件裡，對bd階段的各個頁面裡包含的資料邏輯處理做說明。如 查詢時呼叫的資料處理函式該如何設計，入口...
專案成本管理的高效建議
成本管理的現金流分析採用的資料大都來自估算和 具有一定的不確定性，可能造成專案的現金流入減少或現金流出增加。不確定性成本管理或風險成本管理已成為我國專案管理中的弱項，也是很多商業銀行貸款最關心的問題。即使是專業的諮詢公司或專案管理公司，大多只停留在簡單的量本利分析和敏感性分析。本文著重介紹概率分析 ...
關於專案管理的幾點建議
寫給未來的自己看，文件逐步更新中。當前國內企業都面臨的相同的問題，專案周期短 需求變化多，為了占領市場都要求專案能夠短 平 快，這樣給專案 管理帶來了很大的挑戰，從我經歷的幾個專案來看就是遇到了這些問題，也在這些問題上了很大的虧，今日得閒將之前 的經驗教訓進行一次總結。一 正常，按照專案計畫上線的專...