適應日益加劇的競爭環境、把握瞬息萬變的市場信息是企業得以生存和發展的基礎，某大型IT公司估計其產品推遲上市一個月將導致收入減少530萬（人民幣）、利潤減少265萬、還要付出另外的研發費用37.5萬。這就對產品研發項目提出了更高的要求：如何在有限的資源投入下以更快的速度滿足或者超越用戶的需求。

在提高研發效率方面，業界已經進行了大量有益的探索和實踐，下面是幾種較有代表性的見解：

l? 過程/流程決定一切（強調過程的重要性）；

l? 人是生產力的決定因素（強調人的重要性）；

l? 采用XXX編程工具，可以使您的開發效率提高一個數量級（強調工具的重要性）；

l? 良好的計劃是項目成功的一半（強調項目管理的重要性）；

? ? ? ? ? ? ? ……

盡管每種見解都有大量的擁躉（無論處于業務還是商務角度），但是仍然會遭到大量的挑戰而不能自圓其說，從研發項目的實踐來看也同樣反映了“瞎子摸象”的現象：好像每種見解都是對的，但是又不完全對。

根據美國項目管理協會的定義：“項目管理是在項目活動中運用知識，技能，工具和技術，以便達到項目要求”；項目管理的目標是在給定的資源、預算和時間內安全地完成符合質量要求的項目。以上定義意味著項目的資源、預算、時間和項目范圍有著內在的約束關系，在這四個因素已經被“極其樂觀”的限定的情況下，項目最終無法完成——項目經理常常會遇到非常緊張的、不可能完成的Deadline，如何應對？項目范圍的約束關系告訴我們手中的王牌包括增加人手（有時候人多反幫倒忙，可以參考《人月神話》）、投入更多資源（部分模塊外包、使用COTS、購買最好的開發/管理工具）、削減項目范圍/需求（承諾在后續版本中提供某些功能，但是用戶未必會認同）、降低質量（軟件項目交付質量的降低往往意味著客戶需求沒有完全實現，用戶也未必會認同）。

更深一個層次，多個因素影響了研發項目的開發效率，片面強調某一個因素而忽略其他的因素，都無法揭示項目實踐中遇到的問題。這里引用一個老笑話：

有個警察看到個喝醉的人在路燈下找東西，他就問：你找什么？那個醉鬼說，車鑰匙下車時掉了，我在找。警察問：你不在掉的車子附近找，怎么到路燈下找呢。醉鬼說：那里黑啊，這里亮啊，好找！

其實很多項目經理或者咨詢機構都在犯類似這個醉鬼的錯誤，不管是有意或是無意的——試圖在自己最熟悉、最容易控制的因素上尋求突破，而對自己陌生的、難以控制的因素卻置若罔聞，盡管它可以為項目帶來更大的回報。我推測很大程度上是由于“人類本能的需要心理安全感”。

那么，到底哪些因素影響了開發的效率、他們又能夠在多大程度上造成影響？下面的資料是Capers Jones在《Software Assessments, Benchmarks, and Best Practices》中使用的數據，這是目前為止最新資料（雖然量化管理是管理追求的較高層次，但是現在度量方面的專著卻幾乎絕跡，可能是商業利益使然）。

影響軟件項目生產率的積極因素（以影響程度排序）：

?

影響軟件項目生產率的消極因素（以影響程度排序）：

從上面的數據中可以有很多新的發現，當然是仁者見仁，智者見智：

l? 同一要素的不同影響：相同的項目因素，例如“管理人員經驗”，對項目生產率的正面影響為65％，也就是說管理人員具備高質量的管理經驗，最高可以使生產率提升65％；而蹩腳的管理人員卻對生產率造成最高90％的下降。65％對比－90％，并不相同，這一點在“需求蔓延”上面表現的最為突出，是9％對比－77％。這說明了相同的事情如果做的不好，帶來的負面影響遠遠大于將其做好而帶來的積極影響；

l? 產品/模塊復用：復用可以包括平臺化開發、模塊重用等，高質量產品復用所帶來的收益是驚人的，但是如果有問題的模塊被復用，就會對相關產品均造成負面影響，這種影響被批量放大，解決起來也更加困難；

l? 人的問題：我們會發現管理人員、技術人員的能力經驗對項目造成很大的影響，在這方面的努力會得到很好的回報：不少公司愿意在營銷運作、過程改進、設備引進等方面投入巨資，在引入和培訓人才方面缺乏力度，初衷是認為“人”在短期內不可改變，即便是這樣，對“人”視而不見，長期看來只能是在低水平踏步；另一個問題，項目經理往往會認為項目團隊的成員是短板，事實卻常常相反，項目失利源于經理的經驗不足，對項目喪失控制，“能力越大，責任越大（“With Great Power, Comes Great Responsibility”，Uncle Ben to Peter Parker in Spider-Man）”，不斷提升應該是管理者的必修課；

l? 需求：產品需求可以看作射擊的目標，如果目標沒有找準或是錯誤的，項目必定走向失敗。需求對于項目的重大意義無論怎么強調都是不為過的，幾乎每個項目經理都會被“需求蔓延/變更”折磨過，但是真正能夠從中吸取教訓的比例卻相當少；

l? 管理工具/編程語言：運用恰當的管理工具/編程語言會極大的提高工作效率，例如項目管理工具、配置管理工具、團隊交流工具、集成開發環境等，但是卻不能指望工具可以改變項目的命運或者產生數量級的飛躍，因為整個項目的工作不僅僅是編寫代碼，需求分析、系統設計、測試設計、評審等活動不能由工具完全代勞；此外，過分迷信工具的效果反而會削弱對其他因素的關注程度；

l? 流程：CMM/CMMI的影響已經將過程的重要性渲染得無以復加，但是令人失望的是它只有30％－40％的影響，其實在其他因素不變的情況下，哪怕只有10％的改善已經非常可觀了；過程改進方面過猶不及，不顧公司的商業收益而片面強調規范化、一味向某個所謂“業界最佳”實踐看齊，更像是一場無收效的做秀而不是真正的過程改進；

l? 進度估計與控制：現在已經有很多成熟的估算方法和工具，那些復雜的方法并不見得比相對簡易的方法擁有更好的準確度，關鍵是方法運用和熟悉的程度；適當的進度壓力可能刺激開發人員的工作積極性，但是過大的進度壓力卻可能導致追求進度而放棄產品質量，結果就是產品不穩定，開發周期拖長，直到大家都已經不耐煩了才勉強發布；

l? 團隊士氣：盡管這個因素的影響程度并不大，但是相比耗資巨大、周期漫長的過程改進活動，其投資回報是非常高的。開發團隊具備高昂士氣并且由衷的愿意為項目做貢獻，就會主動的高質量完成工作，這是任何流程規范無法比擬的。電影《勇敢的心》、《特洛依戰爭》、《魔戒》中，在英雄們率領他的部隊展開詩史般的沖鋒之前，都會發表一番激情洋溢的演說，用意就是激勵起部隊斗志，顯然這樣會比士氣低落時的勝算要大很多。但是一味的強調“精神勝利”是不夠的，古人曾總結出“一鼓作氣，再而衰，三而竭”，試圖激勵士氣并不是一件很容易的事情，不過挫傷士氣倒是輕而易舉的；

項目管理是一門尋求平衡的藝術，即憑借有限的資源最大程度的滿足項目干系人的期望；上述的表格只是眾多因素的一個子集，不同的項目在不同的階段可能會出現不同的短板，這就是我們改進的機會所在。