問題，這樣處理是否合適？
    項目進度推遲、項目預算超出計劃，公司領導把項目經(jīng)理叫去，嚴厲的批評了一頓，而沒有責備過任何其他項目成員。
    軟件發(fā)布出去后，發(fā)現(xiàn)嚴重的缺陷，公司領導把測試人員叫去嚴厲批評，也沒有責備過任何其他項目成員。
你們的團隊中，有沒有這樣的情況：
    只有項目經(jīng)理為項目的進度、預算勞心勞累，其他人都在“安分”地完成“本職”工作，不會主動過問其他情況。
出現(xiàn)問題時，誰是問題責任人的皮球會被踢來踢去，沒有人愿意承擔責任。
為什么有這樣的問題呢？應該如何處理呢？是責任定得不夠清晰嗎？
    團隊的每一位成員，肩負起自己所在領域的責任，團隊的每一位成員共同對最終解決方案負責，同時鼓勵小組成員對非他們直接負責的領域作出評論和貢獻。
    軟件開發(fā)團隊中，有項目管理、需求分析、設計、編碼、測試等各個領域的人才，每領域的負責人對自己的工作負責。
    另外一個方面，軟件是團隊共同勞動成果，所有人對最終的解決方案負責，最終解決方案只要有問題，就是整個團隊的責任，最終解決方案取得優(yōu)異成績，就是整個團隊的功勞。軟件開發(fā)團隊，是一個“一榮俱榮、一損俱損”的團隊，只有這樣才能把全部人的利益扭在一起。
了解了微軟的這個原理后，大家對前面提到的問題是否有了答案？
關注交付的業(yè)務價值
    客戶需要的是一把梯子，系統(tǒng)分析員了解到的是一張凳子，開發(fā)人員做出來的是一張桌子，測試人員以為是一張椅子。看上去可笑，但這樣的情況卻經(jīng)常發(fā)生在我們的身邊。關注交付的業(yè)務價值，意思就我們工作中的每一份工作產(chǎn)品，都應該是需求驅(qū)動做出來的，這樣才能保證我們最終做出的軟件就是客戶所需要的東西。這個原理有以下幾層意思：
    小組成員要對客戶的需求有一致的充分的理解;
要讓客戶積極參與到項目過程中去，隨時了解小組的理解和客戶的需要是否一致;
需求驅(qū)動地完成所有工作，保證最后的軟件產(chǎn)品符合客戶的需要。
保持靈巧，預測變化
    軟件是智力型創(chuàng)造性活動，保持靈活、適應變化是軟件開發(fā)的最高境界了，筆者認為這條原理是最難把握的一條了。
這個原理主要體現(xiàn)在以下方面：
軟件開發(fā)過程
    微軟采用的不是RUP，也不是XP，而是類似于螺旋形的階段式分版本發(fā)布。微軟會把軟件分成若干的版本發(fā)布，除了平時我們見到的Beta版、Release版，其實在Beta版之前還會有若干的內(nèi)部版本。
    每個版本都包含相對完整的功能，都能實現(xiàn)部分業(yè)務價值。每一個版本就是一個開發(fā)周期，每個周期包含遠景、計劃、開發(fā)、穩(wěn)定、部署五個階段。這樣的一種開發(fā)模型，能很好地適應需求變化，發(fā)現(xiàn)設計、編碼缺陷，優(yōu)化設計，更容易控制軟件質(zhì)量，便于隨時做出商業(yè)決策。
設計方案
     執(zhí)著于優(yōu)雅設計的人士，可能很喜歡做出完美無缺的設計，關注于業(yè)務的人士，可能更關注于盡快要拿出軟件。我們追求的是適度設計，而不是過度設計，如何做出一個簡單的而又適應變化的設計，是對軟件設計高手們的一大考驗。
質(zhì)量投資
“質(zhì)量第一”是很多軟件公司的口號，而且僅僅是口號而已，你們的項目有這樣的一些問題嗎？
代碼沒有經(jīng)過簡單的冒煙測試，甚至不進行是否通過編譯的測試，就直接提交。
為了趕時間不寫設計或者寫了不能指導編碼的設計文檔。
    開發(fā)進度推遲，測試時間被壓縮，為了保證軟件發(fā)布的時間，在不充分測試情況下交付軟件，更甚者不測試軟件，直接讓客戶測試。
開發(fā)過程中發(fā)現(xiàn)的問題，只要能不解決的就不解決，進度優(yōu)先！
測試中發(fā)現(xiàn)的易用性方面的缺陷，因不會嚴重影響使用，一律不解決！
    質(zhì)量投資要求我們有零缺陷的意識，零缺陷意識要貫穿在全部的工作中，包括：
零缺陷文檔
    計劃、需求、設計等開發(fā)過程中產(chǎn)生的文檔，要用一次寫好的決心來編寫，所有文檔都應該

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://www.vanceur.cn/pmqhd/index.html