[b]為你的專案加入乙個階段--技術研究[/b]
--專案管理的一種「最佳實踐」
摘要：以乙個明確的「技術研究階段」來提高開發效率、規避開發風險、提高專案管理的可控性，是乙個簡便易行的「敏捷」專案管理手段。
1、什麼是「技術研究階段」
這是我在專案管理實踐中總結出的行之有效的一種「最佳實踐」，技術研究這個詞很自然就能理解了，「技術研究階段」通過本文的描述也很容易理解。關鍵是「實踐」。
2、明確乙個「技術研究階段」的動力
* 規避技術風險
* 提高開發效率
* 提高專案管理可控性
這是在專案管理中實行「技術研究階段」最原始的動力。
3、「技術研究階段」的適用情況
有幾種比較典型的情況非常適合加入「技術研究階段」：
* 專案中引入新技術、框架
* 專案開發團隊「以老帶新」
* 錘煉、優化已有的相關技術積累，以應用到當前專案
這幾種情況是我驗證並收到良好效果的，並且我認為可以適用但不限於以上情況。
4、怎樣開展「技術研究階段」
4.1 什麼時候實行「技術研究階段」
專案的開發團隊一組建，或者主要全職開發人員一到位，就可以開展「技術研究階段」。可以和需求分析並行，最好開發環境、平台等已經選定。
4.2 「技術研究階段」實行原則
一定要明確這個階段，參與者有明確的目標和任務，可以動用「卑鄙」的考核手段（主要是提高重視程度，而不是考核）。
目標和任務由專案經理、teamleader、資深開發人員等共同討論決定。以老帶新的情況下，「老人」為主要責任人，同時也負責指導「新人」。至於指導手段，什麼結對程式設計等等都可以。
目標任務要明確下來，你寫在公示的白板上可以，用郵件發任務書也可以，總之要讓每個人明確自己的研究任務、時限。
4.3 「技術研究任務書」
上面提到，用來明確目標任務。載體可以靈活，格式要簡單明瞭，任務、時限、責任人是核心內容。不要放太多東西。
4.4 研究目標實現手段和提交物
一定要結合眼下專案的具體業務場景。
業務場景由專案經理、核心開發人員等（團隊不是很大的話最好是全體人員參加）選定典型、難點場景，不要很完整，針對估計的技術實現難點最好。
所有型別的技術研究，提交物都是乙個現實開發、執行環境下的demo，不關心介面友好等等一切修飾性東西，最關心的是實現該場景的技術難點，它不必是bug free的。
4.5 「技術研究階段」的「研究結果宣講」
這是非常重要的乙個環節，每個人，或者每個研究任務都要有乙個代表，講解自己的「研究成果」，專案組開發團隊都要參加。
這種最佳實踐行之有效，你也可以在此基礎上衍生自己的相關手段 :)
乙個技術階段的總結和另乙個階段的開始
從事技術行業這個工作已經兩年多了。最開始的時候，覺得自己的技術進步得特別快，但是現在覺得自己的水平停在這個階段已經很久了，可以說是學習到了乙個階段，結束了乙個階段，需要開始另外乙個階段。第乙個階段的學習，其實主要還是學習如何去快速使用一些技術，怎麼樣讓自己更快的上手，能將某一樣技術投入到實際的專案開...
為你的程式建立乙個控制台
經常看到一些程式在執行的時候有乙個windows控制台，感覺非常cool。實際上有的時候幫助你監視系統執行是很方便的，那麼怎麼樣建立乙個控制台呢？實際上windows為你提供了一系列的api來完成這個功能，例如 readconsole,writeconsole等，具體參見msdn。下面我們用一段 來...
為你的ASP程式作乙個負載測試
為了更好的測試你的asp程式，你首先需要決定你的程式將來需要面對多大的壓力。簡單的說，壓力或負載可以分解成以下數字 最低使用者數量。這個程式的使用者的最低數量是多少？通常這個數值可以是每日或沒周或每月的點選量 當然你也可以分解成乙個更可控的數值 每小時訪問量，併發使用者的總量.在最高峰時的糟糕狀況是...