史蒂文‧辛諾夫斯基(Steven Sinofsky)，微軟Windows事業部前主管。
微軟Windows業務前總裁史蒂芬‧辛諾夫斯基(Steve Sinofsky)本周在個人博客中刊文，闡述了在項目管理中如何確定項目範圍。他認為，確定項目範圍是項目開發最重要的第一步。原文較長，精簡版請點擊：Windows前主管：如何進行產品開發決策。
開發一款產品，無論是新產品還是產品升級，都意味著需要決定產品中需要及不需要哪些內容。在執行中，主要的限制因素是你願意向產品投入多少時間，或者說多少開發人員。在計劃中，你需要確定合適的工作量，合理調整產品計劃。確保項目有著合適的規模，同時仍能很好地實現目標，這就是核心的產品開發技能。
對產品開發的討論大多處於細粒度的水平，包括某項特定功能，投資結構，以及如何溝通工作。不過，仍有一些宏觀因素會對產品開發產生較大影響。項目最重要的第一步就是確定“範圍”。確定項目範圍需要各個利益相關方的積極對話。
在軟件和服務項目中，項目等同於軟件和服務。這種項目的範圍決定了一系列選擇，甚至你闡述項目範圍的方式都會帶來或摒除一些選擇。一開始，你需要確認當前的基礎：
全新的產品。對於新產品，你有機會設計一個最小功能集或最小需求集的產品。換句話說，你可以有意識地選擇最少的功能和投資，來實現你的應用場景和目標。這通常被稱作“最小競爭力產品”。“新產品”的另一個方面在於，這樣的產品對公司或者對整個行業來說是否是全新的。對公司而言的新產品和對行業而言的新產品通常有著不同的範圍。對創業公司而言，最小競爭力產品很有意義，因為它們並不知道“最小”為何物。而對成熟公司來說，這將存在挑戰，全球化、可訪問性、安全性，以及與現有基礎設施的整合都是需要考慮的問題。成熟公司可以為“最小”設立更高的標准。
對現有產品的改進。大部分軟件都是對現有產品的改進。在改進現有產品時，需要確認的範圍主要在於這些改進是否與當前產品兼容，這包括用戶體驗(按鍵點擊、信息流)、數據(文件格式、此前存檔的文件和設置)、功能(產品能幹什麼)和平台(API、插件)。在為現有產品制定計劃時，預先確定所有方面將會使你付出代價。但對外部人士和管理層而言，這難以理解。回歸測試、設計限制，甚至是你選擇對現有功能做什麼樣的調整，這些都會影響新版本所需工作的範圍。有時，盡管只是對現有產品的改進，但一款產品對某家公司來說仍將是全新的。在這種情況下，從市場競爭角度而言，以上的限制因素也會存在。
徹底改造現有產品。任何項目在一段時間內都可以接受增量式改進，但最終仍需要大幅度調整，具體原因包括應用場景發生變化、規模受限，以及用戶體驗老化等。在項目最初，如果你已經意識到需要徹底改造一款產品，那麼你將面臨不同的項目範圍挑戰。首先也是最重要的是，你需要明確項目的哪一部分需要改造。例如，你是考慮重新實現現有產品，還是希望對產品的某些部分，例如用戶界面、API和功能，進行架構的重新設計。有些時候，產品對你的公司來說是全新的，但將對一款競爭對手產品造成很大影響，這意味著需要從不同角度去看待產品面臨的限制。
並行的產品。考慮項目範圍的一種方式在於，預先確定你的項目將與另一款產品共存，幫助你的客戶或公司解決一個類似的問題。這種方式在企業內部IT系統中非常典型。在這類場合中，新系統在搭建之後將與老系統並存，並經歷一段轉換過渡期。對消費類產品而言，並行產品可以被簡單地描述為“繼續以你的方式去做，但同時也可以試試我們的系統”。這樣的方式在項目開發早期可用於你瞄准的客戶。
這樣的分類方式更好地覆蓋，或更加貼近我們很多人從事的軟件項目。通常，我們看待一個項目的方式只是“新產品”或“升級”，但卻過度簡化了項目範圍。
如果團隊不太清楚項目範圍，那麼項目在起步初期將遭遇困難。確定項目範圍是一個工程選擇，而不僅僅是在介紹產品時對產品進行定位的一種方式。例如，你開發的一款產品可能是對當前產品的改進，但卻沒有確保一些基本功能的實現。試圖將產品定位為“全新”或“並行”也可能帶來麻煩，因為代碼中的許多選擇並不符合這樣的定位。人為的縫隙對客戶和評測者來說可能非常明顯。由於在產品開發中可能有許多挑戰，你可以回顧項目歷史，包括成功的歷史和失敗的歷史，以發現常見的挑戰。
確定項目範圍並就此達成一致是重要的第一步。在這一過程中，團隊不同成員可能會對此提出異議。
如果你在開發一款企業級產品，並提出了將打破兼容性的一些元素，那麼你需要做好項目範圍的確定，因為你將立刻面臨企業銷售團隊的“要求”，即在計劃中恢複兼容性。
而涉及筆記和寫作的消費類產品毫無疑問需要提供基本的文字和圖像處理功能。人們可以預計，評測者會將這樣的產品與現有的熱門、成熟產品進行對比。我們已經很熟悉，一些產品的最初版本盡管帶來了顛覆，但仍遭到了尖銳的批評，因為其缺少某些“必需的核心功能”，例如複制粘貼。
在確定項目範圍時，大部分情況下最初的理念誤區在於，被擱置的分歧，或者說不同觀點，未來能夠很容易地解決。在人們的觀念中，一種應對方法是，產品的創新性對各方來說都顯而易見，因此一旦人們看見產品之後，所有“超出範圍”的問題都將從分歧走向共同的理解。但根據我的經驗，這樣的方式並不一定有效。
當你確定一個項目的範圍時，最困難的挑戰是，你認為“顯而易見”的東西，在用戶沒有看見產品的情況下，對用戶來說很容易被忽略。你可能知道，你能增加一些市場上現有的功能，可以打破兼容性，可能需要與其他產品並行，或者還沒有准備好添加複雜字符集，但如果產品沒有被展示給同事、管理層和評測者，甚至說團隊沒有看見整個產品，那麼你總有可能遭遇許多麻煩。如果曾經有過這種經歷，那麼你肯定不會對這種情況感到陌生，你將准備好繼續推動項目進行，同時不斷闡述你如何以及為何做出這樣的選擇。
即使做好了這樣的准備，在項目從規劃到執行的過程中，合理調整項目規模仍會出現一些常見的陷阱。這些陷阱可能會在產品集合到一起時出現，也有可能在首個客戶看到產品時出現。這也可以成為一款產品無法最終推出的原因。
- 設定不同的項目範圍。對任何項目，最嚴重的失敗在於你認為可以在項目進展過程中重新評估項目範圍，同時仍可以按時交付。如果你決定打破一款現有產品的兼容性，並開發全新的功能，那麼你將需要為新功能重新設計架構，對現有產品進行刪減，或是採取巧妙的折中做法。退一步說，你真正要做的是重新評估對整個產品的做法。盡管這是可能的，但你不可能憑借已有的資源，按進度完成工作。
- 項目範圍過大。我們大部分人在確定項目範圍時，都會嘗試去做憑現有時間和資源難以完成的工作量。如果你對項目範圍非常清楚，那麼一個健壯的產品計劃將擁有相當大的靈活性來解決這方面問題。換句話說，過長的功能列表很容易被縮減。這與嘗試調整項目範圍完全不同，因為調整範圍可能意味著對一款產品的徹底改造將變成增量式改進。如果你面對太多的功能，但產品發布意圖仍符合這一很長的列表，那麼我可以肯定其中一些功能可以被刪除。
- 項目範圍過小。在當前的環境下，最小競爭力產品是一種開發創新產品的好方式，但採取這種做法時，你很可能會使項目範圍變得過小。在開發新產品時，這意味著你還沒有真正瞄准創新，或者產品的附加值。類似地，對任何涉及數據中心(或其他資源)部署，以及存在合作夥伴承諾的項目，應該更多地考慮總投資，而不是總投資回報。而在對現有產品進行改進時，採用這種方式的產品發布可能會被認為過於保守。這也可能導致你失去關注重點，在許多方面都僅僅完成了很少的工作。
- 錯誤的事情。在確定項目範圍時，一個常常被忽視的陷阱是，你可能會選擇解決錯誤的問題。換句話說，計劃可能是切實、可實現的，但對項目範圍的錯誤定義導致你從事了錯誤的工作。簡單地說，這就是選擇去做錯誤的事情。這一陷阱通常出現在你做這些事的過程中，例如增加更多工作量，在途中重新確定項目範圍，或是徹底改變項目範圍等。在改進現有產品時，從事了錯誤的工作是一個常見陷阱，這通常是由於在確定項目範圍時缺乏對工作優先級前後一致的看法。
- 針對本地市場或全球市場的優化。確定項目範圍本質上是為了優化。對改進現有產品來說，你可以選擇某一特定方面，並在下一版產品中對其進行重新優化。對新產品開發來說，最小競爭力產品就是尋找價值鏈的某一環進行優化。撇開項目範圍，問題在於，在項目進行過程中進行的調整是在優化一個正確的計劃，還是一個錯誤的計劃？你可以進行多版本測試，或是重新定位產品，但如果你所關注的價值曲線的某一部分並不具有太大價值，那麼這無法帶來幫助。你所進行的優化是針對一個最理想的產品，或者只是改進你自己的那一部分，並不足以給整個產品帶來改變？
當然，項目出現錯誤的方式多種多樣，一些問題嚴重，另一些問題則不大。實際上，項目開發的一部分就是處理這些不可避免的問題。不會有什麼項目一帆風順。正如“阿波羅13號”，當第一個小故障出現時，你可以告訴自己“先生們，我們似乎出現了故障”，也可以警示自己將有更多故障出現。這是複雜產品開發過程中的正常現象。
提前對項目進行合理調整將同時帶來約束和靈活性。
合理調整意味著提前弄清項目的邊界。如果你對項目的條件限制和戰略限制很清楚，那麼你就實現了使一切保持正軌的第一步，能夠確保你對團隊、客戶和管理層有關產品開發的承諾。考慮這些限制的一種方式是關注項目範圍的關鍵變量。通過提前確定這些變量的值，你將可以對項目進行合理調整。
從項目管理角度來看，條件限制是項目的支柱。你可以將這些視作預算或基礎，或者起始點。
- 人員。有多少人將會工作於這個項目？這是一個最簡單的問題，也是最容易在一開始就解決的問題。一個好的原則是，項目計劃的制定應當基於你從第一天開始有多少人員。盡管許多項目將隨時間而加人，但如果依靠這些人去做關鍵工作(尤其如果這一項目不會持續很多年)，那麼你很可能會失望。由於人員的自然流動，大部分項目在進行過程中都會出現人員調整，因此最好的做法是假定補充的人員只能填補離開的人。
- 時間。另一個簡單的項目範圍變量是，你的項目將持續多長時間。無論是按周還是按年，你都需要提前確定。持續集成模式的使用者還需要弄清，在某一特定代碼以某種方式發布給客戶之前，代碼的計劃和編寫需要多長時間。如果有多個團隊同時需要發布代碼，那麼確定這一時間並不是一個孤立工作。對於團隊成員，你可以增加工作時間，但不要期待工作成果的相應增加。眾所周知，一旦項目啟動，如果試圖減少工作，那麼結果往往難以達到預期。許多利益相關方都會對項目應當持續的時間有自己的看法，但這不能獨立於你所能完成的工作去看。
- 准則和工具。對任何從現有產品基礎上開始的項目而言，項目經理需要慎重考慮，什麼樣的代碼需要繼續開發，什麼代碼需要被替代或調整架構。從一款現有產品開始意味著許多其他因素也遭到限制，例如工具、編程語言，以及雲計算基礎設施。對於新產品，提前確定這些將是合理調整項目範圍的重要一部分，而在項目進行過程中這些選擇不可能改變，因為這不僅僅影響項目進度，還將影響功能的實現(例如原生應用和HTML5應用，以及採用什麼樣的身份驗証基礎設施)。提前確定的准則將影響與兼容性有關的項目範圍。
這些條件因素與產品策略有關，但不會決定產品策略。一般情況下，產品發布節奏是一種策略，但也反映了項目的種種條件因素。戰略限制是項目的圍牆，構建在條件限制之上。你的戰略就是你如何選擇項目去做什麼，不做什麼。一些戰略限制需要提前考慮。
- 大賭注。每一個項目都會下幾個，甚至一個大賭注。對現有產品來說，賭注可能是新的用戶界面或新的業務模式。對新產品來說，這可能是關鍵的知識產權和全新的應用場景。這樣的大賭注是團隊中所有人的戰鬥口號，也是所有人願意為之付出的動力。
- 用戶。所有項目在開始之初都需要知道，誰將會使用產品。毫無疑問，這聽起來很容易，但在確定項目範圍時，這意味著項目瞄准的所有潛在客戶，其需求都不可能100%的被滿足。了解如何給相關客戶帶來價值是合理調整項目範圍的關鍵一部分。如果你在現有產品基礎上開發，或是打破現有產品，或是開發新產品，那麼毫無疑問一些人會認為，新產品無法滿足他們的需求。但這並不是說，你永遠無法滿足他們的需求，也不是說，所有客戶都會這樣認為。
- 長期前景。在合理調整項目範圍時，你會希望知道，你將向何處發展。有很多方式去了解，包括複雜的方式和簡單的方式。以往的業務決定了你將向當前工作投入多少資源。如果你能知道未來的發展方向，而不僅僅只是當前一個版本，那麼你可以走過更長的路。對長期前景的討論並不等同於長期規劃。長期規劃是一種複雜的方式，你可能會做出一些無法實現的承諾。我們都知道，團隊、市場和業務的所有方面都會發生變化。但對長期前景的討論將使所有人都感覺到“思考”正在進行。對待這種工具的方式之一在於，確保對話關於團隊正在思考什麼，而不是團隊正在做什麼，因此對長期前景的討論不會變成列舉長期承諾。
總而言之，建立產品計劃的第一步是對產品範圍的合理調整。在這一步中，常見的問題是極端化，例如過小或過大。在實際情況下，業務開展狀況將決定什麼樣的合理調整才具有競爭力。你可以使用一些工具，主動確定項目的規模，而不是等待項目自然的發展。以長期眼光去合理調整當前項目將使項目保持合適的規模，同時仍能實現目標。與產品開發的其他方面類似，做好准備，並預見未來的挑戰將是最好的應對方式。
.[數碼新聞]Windows前主管談產品開發：確定範圍為第一步
http://digital1010.blogspot.com/2013/03/windows_1.html
