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

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

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

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

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

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

　　4-5個(gè)開發(fā)人員可能配置一個(gè)系統(tǒng)分析員和一名測(cè)試人員，組建一個(gè)小型團(tuán)隊(duì)。

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

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