要花點時間了解早期的項目為什么失敗，并要計劃避免犯同樣的錯誤。對于軟件開發(fā)，每位經(jīng)理花時間處理每種可能要發(fā)生的錯誤是非常困難的，學(xué)習(xí)過去的成功和失敗就是個成功的開始。
可以從過去你們小組承擔(dān)的一個沒有經(jīng)過檢查評估的項目著手，不要管其成功還是失敗，實施項目后的回顧（有時稱作事后調(diào)查分析）。你的目標不是判定責(zé)任，而是為了在將來項目中作得更好。借此，可以了解什么已經(jīng)作得很好，什么應(yīng)該作得更好。在當前每個項目的主要里程碑時，通過集體討論或公平的組織者，用同樣的方式，領(lǐng)導(dǎo)小組用頭腦風(fēng)暴的方式對其展開分析。
另外，要了解領(lǐng)悟已有的軟件工業(yè)的最佳準則。一個好的起點是SteveMcConnell的JoltAward獲獎作品：快速開發(fā)（RapidDevelopment，MicrosoftPress，1996）的第三部分，敘述了27個最佳準則。也要避免McConnell敘述的36個常見的軟件開發(fā)錯誤。你的組員也許反對新的工作方式，但是你的角色是作為一名領(lǐng)導(dǎo)，要確保團隊一致連續(xù)地使用最佳可用的方法、過程和工具。積極促進組員之間的信息共享，這樣局部單個最好的實踐經(jīng)驗就能成為每個開發(fā)人員的工具箱的一部分。
建立改進目標
一旦你對過去的項目建立起了回顧，確立了質(zhì)量對小組的意義，你就要建立短期以及長期改進的一些目標。目標要盡可能量化，所以你要劃分幾個簡單的階段，標明你是否采取了適當?shù)倪^程朝著目標前進。
例如，如果你認定由于需求的不穩(wěn)定導(dǎo)致項目經(jīng)常延期，你可以建立一個改進需求穩(wěn)定的目標，在6個月內(nèi)提高50%。這樣一個目標需要你確切知道每周或每月需求的變化數(shù)，清楚他們的出處，采取行動控制那些變更。這可能要求你要改變與那些提交需求改變的人的交流方式。
你的目標和階段是軟件過程改進程序的組成部分，你要使之有序。作為缺乏創(chuàng)造力的官僚主義的最后避難所，輕視“過程”很流行。雖然事實上，每個小組都能找到改進其工作的方式。當然，如果你總是用已有的工作方式工作，你也就不要期望你會得到比以前更好的結(jié)果。
有兩個強烈的原因要求改進過程：校正問題，防止問題。確保你的改進努力要圍繞著已知的或可預(yù)知的可能威脅項目成功的問題。領(lǐng)導(dǎo)你的小組找出當前正在使用的方法的長處和短處，以及項目面臨的風(fēng)險。
我的小組召開了一次“兩段式頭腦風(fēng)暴”練習(xí)，來確定改進軟件生產(chǎn)力和質(zhì)量過程的絆腳石。
在第一次會議中，參會者在便條上寫出他們關(guān)于會議主題的想法，一個便條一個想法。組織者將他們寫在便條上的想法收集上來并分組。最后，我們就會得到一打主要的分類，并將其記錄到活動掛圖上。
第二次會議，相同的參會者在便箋上寫出解決這些障礙的思路，并貼在掛圖的合適位置。進一步細化，歸納出一些詳細的活動，就可以成為我們努力的一部分，清除障礙，幫助組員實現(xiàn)軟件的質(zhì)量和生產(chǎn)力的目標。
建立可度量和可達到的目標，便于你集中精力實現(xiàn)改進。要使目標具有明顯的優(yōu)先級，并可周期性地監(jiān)視過程。記住你的目的是，提高你的項目和公司完成的技術(shù)和業(yè)務(wù)上成功，不要滿足于一些過程改進書籍里提到的期望細節(jié)。要把改進的工作視為迷你項目，具有可分發(fā)、資源、計劃和有責(zé)任的小項目。否則，過程改進活動將總處于比誘人的技術(shù)工作低的優(yōu)先級上。
緩慢的開始
這篇文章提供了許多建議，幫助你，一位軟件經(jīng)理新人，帶領(lǐng)你的小組走向偉大的成功。在日復(fù)一日新的工作壓力面前，要努力保持你的頭腦清醒。在長時間的塑造軟件開發(fā)小組的文化和習(xí)慣上，你還是個非常重要的角色。你不必一次性都作完，可以選擇跟環(huán)境最相關(guān)的的幾個開始。
作為軟件經(jīng)理，除了項目要按時按照預(yù)算完成外，你要擔(dān)負的責(zé)任還很多。你還要：領(lǐng)導(dǎo)技術(shù)人員，將他們形成一個具有凝聚力的團隊；建立協(xié)同團隊工作的環(huán)境；鼓勵和獎賞高級軟件工程師的實踐應(yīng)用；平衡來自客戶、公司，組員和你自己的需求。
這是項重大的任務(wù)，祝你好運。