壓力管理告訴我們什么？就是一個(gè)人如果一直在一種輕松和不緊張的情況下工作，就很難持續的進(jìn)行學(xué)習和創(chuàng )新，當遇到緊急情況和問(wèn)題的時(shí)候也就很難在緊張起來(lái)，我們的經(jīng)驗和技能水平不但會(huì )停滯不前，有可能還會(huì )不斷的下降。從這個(gè)層面來(lái)講，壓力管理就是要使我們有一種危機意思。

　　當工作了一段時(shí)間后，我們每個(gè)人都會(huì )進(jìn)入到一種狀態(tài)，就是因循守舊，不愿意在接受新的事物和挑戰。我們喜歡接受我們已經(jīng)能夠熟練完成的工作，我們認為我們的經(jīng)驗已經(jīng)足夠應付相應的任務(wù)。但是IT技術(shù)日新月異，如果我們不能夠迎接挑戰，主動(dòng)承擔困難和責任，我們很難再上升到一個(gè)新高度。

　　我們有評審和測試這些過(guò)程，并不是代表允許錯誤和不負責任，評審的目的不是用來(lái)幫你發(fā)現低級錯誤和不認真。由于我們每個(gè)人愿意花在評審上的時(shí)間是一定的，如果評審的輸入物質(zhì)量低，我們就去發(fā)現這些大毛病和低級錯誤；相反，如果評審輸入物質(zhì)量高，我們追求的就是深入的錯誤，這樣出來(lái)的產(chǎn)出物自然是精雕細鑿。

　　當一個(gè)軟件項目團隊，各個(gè)崗位和角色的人員已經(jīng)到位和比例固定的時(shí)候，我們采用的軟件生命周期模型一定考慮的是如何讓每個(gè)成員都能夠在每個(gè)階段都能夠較飽滿(mǎn)的工作。成員的投入往往很難達到分階段來(lái)投入，因此我們會(huì )更多考慮迭代模型和敏捷方法。項目里面的事情就那么多，始終都是需要做完的，不受到強制前置依賴(lài)的事情要盡量提前做；如果沒(méi)有就要考慮把任務(wù)粒度細分，去創(chuàng )造任務(wù)能夠提前并行開(kāi)始的機會(huì )。我們并不是去破壞瀑布模型，每次迭代都是瀑布。

　　對于軟件項目中，開(kāi)發(fā)周期和測試周期要保持一種平衡，平衡的目標就是要保證盡可能少的返工和最短的交付時(shí)間。我們有時(shí)候對于進(jìn)度壓力造成的壓力過(guò)多的壓縮開(kāi)發(fā)時(shí)間顯然是不合理的，造成的后果就是往往再加上兩倍的測試周期，最終的版本仍然遲遲不能交付客戶(hù)使用。我們的時(shí)間都花在了過(guò)多的返工，開(kāi)發(fā)和測試的溝通中。

　　編碼人員如何檢驗和測試自己開(kāi)發(fā)的功能模塊是否已經(jīng)完成？如果沒(méi)有詳細設計文檔，我們的要求就是首先編碼過(guò)程是否符合編碼規范和界面規范，其次就是整個(gè)編碼是否完全實(shí)現了需求文檔中的各種業(yè)務(wù)流和業(yè)務(wù)規則，包括各種完整性和邊界的校驗。

　　4-5個(gè)開(kāi)發(fā)人員可能配置一個(gè)系統分析員和一名測試人員，組建一個(gè)小型團隊。

　　對于軟件項目團隊，我們必須要考慮團隊的整個(gè)績(jì)效，而整個(gè)績(jì)效的核算正是通過(guò)我們團隊整體的人力資源和其它成本的投入創(chuàng )造了多少價(jià)值。而對于返工量，編碼生產(chǎn)率，缺陷密度等都必須要圍繞這個(gè)整體績(jì)效服務(wù)。簡(jiǎn)單講，如果我們返工量少，過(guò)程做的很仔細和規范，當進(jìn)度延誤了2個(gè)月，在這種情況下我們是無(wú)法滿(mǎn)足客戶(hù)需求的。軟件滿(mǎn)足客戶(hù)需求，創(chuàng )造了價(jià)值，就是績(jì)效的衡量。

　　如果你不做項目計劃，就始終無(wú)法知道你預測的準確度，也就無(wú)從談得上跟蹤和持續改進(jìn)。