《程式員度量：改善軟體團隊的分析學》一軟體團隊是成功還是失敗

在體育運動中，每個團隊都為勝利而戰，而成功的定義也很清晰、精确。軟體開發與此不同，我們缺乏對成功的恰當測度。我所發現的最佳政策是軟體開發團隊的成功三角形，它基于三方面的因素：客戶響應、品質名額和效率。這些都能按釋出版、特性來測量，并且可以相對于先前的水準、團隊目标群組織目标加以評估。

開始時，你可以考慮以三個月為周期測量使用者對新釋出版的采用率是否達到了20%。你能夠同設定的目标相比較。為客戶響應、品質名額和效率進行這種檢測，為團隊提供了一種客觀及全面的方式來分析團隊成功。從曆史上看，産品經理負責收集這樣的資料，事實上你也确實可以從産品管理團隊獲得部分或全部資料。但我相信，這一資料更應被軟體開發團隊自己定期和仔細地研究。無論你是否有産品經理的協助，你都應該努力收集這些資料。建立一種測量進步和成功的方法，是能夠識别軟體團隊成功的模式和有利因素的基礎。

測量成功或失敗的第一部分是測量響應。當客戶嘗試或測試産品或特性時，他們的響應明顯地呈現了關注度。它包括采用（當客戶對産品進行注冊時），或選擇購買或積極地使用産品或特性。測量消極響應也很重要，例如當客戶選擇停止使用某個産品或特性時，或者當客戶測試了産品或特性，但後來決定不使用它的時候。顯然，客戶的某些選擇不能直接反映軟體開發團隊的情況，例如，客戶之是以選擇不買産品是因為價格或産品本身以外的其他一些因素。但是，由于缺乏更精确的方法來測量産品的成功，客戶關注與否、采用與否，是我們大多數人所擁有的最佳名額。客戶可能是付費使用者，也可能是非付費使用者。當為自己公司内部提供工具或開發項目時，也可能是内部使用者。

很多人把産品的成功和收入相關聯。目前以及估計的産品收入對于建立預算和産品規劃顯然是重要的，并且在一定程度上，程式員關心收入和預測也是健康的，這樣他們可以了解業務決策和産品規劃的緣由。但是顯然，在某些情況下，收入并不合适，因為某些産品或特性可能不收取費用。而且，即使在收入存在的情況下，我認為最好也是關注使用者數量和使用量。我感到當人們檢視收入的時候，傾向于将重點放在現金上（這可能導緻他們過分關注與收入相關的名額，而不是其他同樣或更重要的名額）。同時，人們更易于對大額的收入留下深刻印象而對少量的收入漫不經心，雖然他們可能都不是關于成敗的準确名額。例如，如果一個産品掙了1000萬美元，這令人印象深刻，軟體開發團隊的感覺良好以至于會無視讨論的其他方面。但如果客戶采用率存在10%的下降，并且距離組織目标有33%的差距，團隊也許有些問題。單純對收入數字的關注可能會導緻程式員不能完全明白實際結果是如此糟糕。或者，考慮産品僅僅掙了5000美元的情況。無論在其他方面如何，團隊會對自己以及結果都感覺不太好。但如果其實客戶采用率在快速增長（或許這是一個隻是售價2美元的手機應用），那麼這可能是一個了不起的結果。關注使用者數而不是收入，你能夠消除或者至少降低一些主觀方面的副作用。在許多場合讨論收入可能是有價值的，但作為一個軟體團隊經常審視的度量名額，我認為會分散他們的注意力。

盡管我不建議使用産品的收入進行比較，但我極力推薦你弄清楚産品與競争對手相比如何。這是另一種評估你的産品在顧客關注度和響應方面做得如何的方法。為了能擷取這些資料，你可能會在産品特性或使用者采用方面與競争對手進行排名。也可能有可供使用的第三方的競争力分析。當然，排名情況并不僅僅歸因于程式員和軟體開發團隊。市場營銷、銷售以及其他許多外部因素，包括企業規模和經營時間都可能會影響你的産品的競争地位。是以競争力的排名并非你成功的唯一測量标準，而是為你評定相對成功水準提供了一個額外的輸入。

軟體品質的測量是成功測量的另一個方面。通常，在這方面有一個很好的測量，就是生産過程中發現的bug數量。客戶支援問題的數量和頻率也是産品品質的一個間接測量，同樣也包括客戶的感受。成功或失敗取決于對品質測度的趨勢的研究，以及和目标進行的比較。随着時間的推移，品質測度的趨勢不僅僅揭示了每個後續釋出版的成功，而且揭示了成功的軟體架構和設計。

決定軟體開發團隊的成功的最後一個測量的因素是效率，也就是說軟體團隊在預算限制内、在某一特定時間内能夠提供多少功能。團隊的工作效率和傳遞速度可以相對于過去的業績、團隊的目标來測量，進而決定成功的程度。非常低效的團隊即使取得了良好的品質和正面的使用者響應，可能也不能看做是成功的。同樣，一個軟體團隊雖然準時地釋出新版本，但顧客的響應不佳或品質糟糕也不是成功。這是為什麼我建議檢視所有的三個領域：響應、品質和效率。