大家好，這里是 TCC 翻譯情報局，我是張聿彤。當我們研發一個產品時，從愿景出發，制定目標，再到項目落地，根據項目體量和企業規模的不同，項目的實施流程跨度可以從一年（小公司項目）到100年（亞馬遜蔚藍計劃）不等。這時為了從宏觀角度清晰的對項目整體有一個清晰的認知，盡可能規避風險，最高效的利用現有資源，就需要制定產品線路圖。產品線路圖將產品生命周期數據化可視化，從研發，市場，合作伙伴等不同背景的部門分析產品進度和狀況。本篇文章詳細分析了如何制定產品線路圖，對于那些還在創業階段的創始人，在推進項目的項目經理會有一定啟發和幫助。

建立產品路線圖有利于管理產品生命周期。然而，我們需要系統的解決這一問題：如何正確的繪制路線圖，是非常必要的。雖然根據愿景來建立路線圖是非常必要的，但是我們要避免將路線圖與愿景混淆。

本文中，我們將重點介紹一些數字系統，這些數字系統可以幫助您了解現在要構建的內容、要跳過的內容以及以后要保留的內容。路線圖的規模和局限，如何從愿景中提出解決方案/功能，軟件產品線路圖的舉例，如何為產品集資，如何對它們進行整理和優先排序如何計算特征的權重值，以及公式和計算示例。

這看起來是一個篇幅較長的文章，但我認為，保留文章的主要思想在閱讀過程中會是一個加分項。

聯合國的座右銘是“放眼全球，立足當地”。

有趣的是，當這句話放在給一個好的軟件產品創建線路圖時也同樣奏效。為了完成這一任務，你需要有一個全球視野，這樣期望與計劃就不會在開頭就很快落空。作為愿景的一部分，確立的目標應該是全面整體的，并且應當由線路圖推動落實。當你由線路圖引領前進時，項目立項就是這一階段的 里程碑和行動的重要階段，開發產品的具體步驟的體現。

01 企劃的時間限制是什么？

這對于每個人來講是不同的，對于初始者來講，最好把企劃限制在六個月以內。如果你確切知道產品將如何落實，那么時間甚至可能在 3-5 年。所以沒有具體的界限。

例如，亞馬遜的創始人 Jeff Bezos 最近發布了一項名為 蔚藍起源 的項目，而這項目的計劃展望期則在 50 年-100 年之間。

也就是說，一個人創建了一家公司，在他有生之年的大部分時間里都在工作。這怎么可能？

在這種情況下，我們討論的是一種 全球愿景 —— 蔚藍起源計劃要為頻繁的太空飛行給予可能性。Bezos 聲稱亞馬遜一直依靠其現有的郵遞和快送框架。沒有這些，亞馬遜不能如此成功。而今天，蔚藍起源項目計劃創造未來太空旅行的框架、火箭、太空站、人造衛星、軌道站等等。而蔚藍起源在 2025 年的全球計劃就是制造太空飛船。

理解全球計劃有助于繪制線路圖，我們在其中展示具體的步驟，制定一個真正的計劃，以便在短期內實現我們的目標。而蔚藍起源，對亞馬遜公司來講是一個雄心勃勃的企劃，企圖實現他的任務，整合一個全球性的組織為客戶提供能夠承擔的起的服務和貨物。

02 由上至下，從天到地

我們來思考一下貼近生活的真實案例。如果一家建筑公司要進行高質量發展，那么他們要做的工作可能看起來是這樣的：

• 愿景：在基輔北部建造最好的住宅區。
• 目標：5000 個公寓，現代建筑，舒適、便利的布局，無車庭院。
• 線路圖：施工和景觀美化
• 計劃：具體完工的建筑物、道路、公園（準備階段可能劃分）
• 特點：計劃中的一部分：例如，操場、植被、有蓋停車場、坡道。

好了，現在我們來看我們更熟悉的商業板塊。

03 那么，如何為軟件產品制定路線圖呢？

軟件路線圖包括多個版本，每個版本都必須包含某些功能?？紤]到可用的機會和資源（稍后詳述），按日期繪制路線圖 非常重要。例如，這是一個社交應用程序的路線圖。

請記住，線路圖的繪制需要同時考慮到所有部門。如果一家公司規模很大，而銷售經理手中也掌握著這份圖紙，那么你需要將圖紙和發展部門建立聯系。不然，當來到時間節點時，例如，要在亞洲市場對一個產品進行營銷的時候，你也許會發現你們沒有做好本土化，沒有中文支持。現在你看到了一個公司的垂直分布有多重要。而路線圖就是愿景和使命的反映。

04 產品代辦事項制定

關于產品中應該有哪些內容的需求來自于不同的群體。我們在之前的一節中已經討論過這個問題。這些需求需要被細致的管理和計劃。重要的是要明白一點，準備好的和已將發行的第一個版本可能行不通，因為實際上沒有足夠的資源來落實所有的想法（ 如果你沒有發生這種情況，那么說明你想的還不夠多 ）。

通過正確的途徑，線路圖可以將產品的開發分成不同的階段并根據優先級和重要性在迭代中推進功能性。

我們來看另一款管理軟件開發的產品的 開發框架 ：

根據此開發框架管理進度的公司的業務熟練程度評估在下表中有所顯示。未來我將列舉一個 產品成熟度矩陣，在那之前你可以在這里參考閱讀。

當公司細致的根據產品路線圖度過準備階段，那么他們就進入了業務成熟的第二個階段：

05 產品成熟度矩陣圖

對于我們自己來說，我們能承載的僅僅是在軟件開發中正常的開發步驟，當建立這些過程的時候，公司本身還要通過傳遞更好的產品來完善公司的文化。而產品線路圖正是文化中的一部分。同時還要記住，線路圖并不只是一份承諾文書，它還是調整利益相關者的 溝通工具。

當我們從多方收集到不同需求時，他們需要被系統的規劃起來。例如，Acronis（瑞士一家科技公司）使用的 Jira，一種非常強大的工具。但是對于初學者來講，我們可以從更簡單的入手，包括一些免費的軟件，例如 Redmine 或者 Asana。

最主要的是，需要記錄下所有的點子，因為沒有想法是糟糕的。如果一個想法還沒有成熟到可以執行，那么它的優先級就是靠后的，因而，每一個提議都有必要被納入系統，即便它們不具備該如何施行的細節。

只有用這樣的方式你才能做出受歡迎的功能 —— 即制作真實的線路圖。所有的想法都會變成所謂的“輸入積壓”，他們既可以是完整的也可以是完全沒有被加工的，不需要有所謂的評估或理解哪些用戶需要這些功能。當需求清晰明了并添加適當的細節，有些想法也許會直接進入到上線階段，而剩余的可能會被送回“儲備端”并存留相當長一段時間。

06 項目舉措

敏捷或 Scrum 法包含著一個詞“Epic”。如果我們盡可能簡單的解釋它的本質，那么我們就要講到一些大的特點，需要所有人都參與才能推動落實 —— 開發者、測試者、界面設計師、技術寫作人員等等。

通常情況下，當創作一個長期項目時，從商業角度上看其重要性是被評估好的，人力開支，以及是否在近期上線或者放到后備儲蓄中也是提前決策好的。

系統中已經被評估過的項目可以定為最佳優先級。例如，在 Jira 中，你可以評定“高級”、“中級”、“低級”三個優先級。但是，在 Acronis 中，我們在后續儲備庫中有成百上千個功能。這時，簡單的優先級就無法滿足我們的需求了。

07 功能打分制

功能打分是一個復雜的分數評定機制。這一想法的理念是 將所有影響開發的因素都放在一個獨立的評估系統中。后續可以根據常規化的評分標準來決策是否應該將功能添加到即將上線的版本中，還是放棄繼續完善。因而，正向的評分機制添加功能點，而負向的則相反（具有更高價值和更少的功能點）。

正向評分點包括：

1. 緊急性
2. 需求群體（用戶）的體量
3. 通過新增用戶群體 拓寬市場
4. 現有用戶群體的 潛在收益與損失
5. 戰略成就（引導我們實現愿景的目標）

負向評分點：

1. 人力消耗
2. 潛在風險

功能打分制的結果必須是數值。這并不是定性評估，而是一種等級評分，其計分的方法必須統一，且在某一產品的研發過程中被證實是重要的組成步驟。

得分是根據常規化價值，公司的市場目標，以及其他參數確定的。功能評分制中第一個要考慮的就是客戶因素。所謂的消費者因素跟消費者群體大小和產品的緊急程度有直接關系。你可以參考下圖的計算方式。

08 消費者因素方程式

市場滲透的定義為，吸引新消費群體的可能性，以及你的規劃如何拓寬基礎消費群體。例如，對于無法吸引新消費者的功能，那么這一參數的評分可以設定為 0，而可以給你帶來 500 個用戶的功能，我們可以給 20 分。

下一個問題就是策略布局。首先，評估戰略，你需要檢驗該功能是否有助于戰略方向的發展。覆蓋的領域越廣，那么對應的分值也就越高。

收入就是一個可以落地的功能，可以提供的潛在利潤。這一參數的預估范圍取決于公司規模的大小、產品的功能，以及你的預估收入。下表是該指標的評分示例。

現在我們來討論一下反響影響的因素，那些有著更少功能點但是更有競爭力的案例。例如，開發成本也可以固定在特定的范圍之內，這完全取決于你在特定的功能上投入多少預算。

風險—— 這就是另一個角度了。你在評估中對項目的信心越少，風險就越高，那么功能評分中的標準價值就越低。

將所有上文提到的因素全部考慮在內，那么功能評分公示大概像以下這樣：

09 功能評分公式

在具體情況下，如果所有的預判都是客觀的，那這是非常理想的。但是如果你才進入市場，并一定要使用功能評分機制。那么就算是主觀的判斷也比什么都沒有強。

如果我們要給這個產品的一下功能進行排列，

那么任務優先級表格大致是這樣的：

在具體情況下，如果所有的預判都是客觀的，那這是非常理想的。但是如果你才進入市場，并一定要使用功能評分機制。那么就算是主觀的判斷也比什么都沒有強。

如果我們要給這個產品的以下功能進行排列：

那么任務優先級表格大致是這樣的：

讓我們來思考下“在預定時間內預定出租車”這個功能。如果將所有參數加起來，我們會得到一個數字“56”。這個是什么意思？

啥意思也沒有！

這是一個相對評級，我們需要把所有 9 個功能全部算進去，并根據相同的規則和等級打分。而結果就是一份優先級清單。在我們的應用中，我們需要在安卓系統中開發一款移動應用程序。而第二個行動就是“初級+”關稅。

一個系統的處理方式能夠讓你在商業層面避免做一些無用功，并且在執行的過程中避免選擇一些無用隨意的功能。而這種循序漸進，分段式的工作方式會給你更高的回饋。而在每一個項目的開發過程中都有很多約束和限制：時間、成本、價值等等，這些因素結合起來會決定你最終成品的質量。因而這非常重要。

并不僅僅是優先級?。?！當計劃即將上線時，必須要考慮到開發團隊的能力。有些產品可能包含以下幾個命令。例如，開發一個出租車預定的服務系統，至少應該有后端、QA、Android、iOS 命令。

但是除了優先級以外，我們必須要計算開發者在下一個功能上能夠貢獻多少時間。為此，你需要大幅增加團隊中的人數以及為其分配的時間。還要了解可以用于下一個階段能用到的人力，以此避免資源浪費。

不同團隊能力與上線之間的關系圖：

10 Scrum 團隊的樣本容量規劃

如果你仔細研究下方圖表，你就能清晰的了解一個 ios 移動端的應用需要耗費多少資源，而這不僅僅限于 ios 開發團隊，還有后端和 QA 專家。這就是為什么管理層決定在第一個版本中不包含適用于 iOS 的移動應用程序是合理的，因為團隊并沒有時間完成這一任務，而是搞定“在預定時間訂購出租車”。

因而，如果按照優先級分化順序來搞定功能，那么一個預定出租車功能的開發線路圖看起來是這樣的：

每個更新版本都將包含下一個優先級功能，這些功能也在開發團隊的能力范圍之內。

11 線路圖—產品開發哲學

有一點我們必須要銘記的就是，線路圖并不是一個保證，但是更像是預判。我建議將路線圖視為當前計劃。一個月后，一個新客戶可能會來要求一個新功能。而當我們把它添加到后續儲備庫時，它可能比之前我們所有的規劃享有更高的優先級。大致的規則就是，當開發一個產品的時候，全程使用線路圖是非常必要的，但是你不能讓它一成不變，因為今天你需要適應不斷變化的市場。

對于那些有線路圖的提案項目（根據基本規則給上線功能排序優先級），內部文化是有必要的。所有的利益相關者必須按規定遵循相同的打分標準，因而第一步就是商討計分公式并遵循規則。當然，在理解了如何完善優先級的條件下我們可以接受變動，但那樣的話就必須重新計算整個后備系統中內容的優先級。

對于大型產品來講，需要根據能力給不同的團隊分配任務，而不是直接根據功能的開發來決定團隊任務，是非常有必要的。例如，開發團隊的領頭人可能會告訴你，我們需要移植到新的 python 上，不然我們會花費更多的時間（財力）在現有的生態系統，舊版本上。為了解決這樣的問題，例如，你可以將團隊 25% 的精力放在能夠吸引新用戶的功能上，45% 的經歷來維護現階段用戶，20% 則用來解決技術難題和架構重組上，剩下的 10% 則作為緩沖，為產品開發中的其他事項留出空間（部署新的構建系統，實施 CICD，等等）。你可以閱讀更多有關技術赤字的內容。

12 總結

要成功的規劃產品開發并適當調整線路圖，你需要定期核查后續儲備庫并隨時為你要卡發并計劃上線的功能重新計算功能打分。但如果下一個上線日期已經規劃好，那么就有必要在管理者和開發者之間建立聯系。

在未來即將發布的文章中，我會搜集更多有關基于 KR 的產品線路圖，多種優先級排序的方法，以及成功線路圖的指標。當然，我們也會涉及到以下話題—如何把握功能評分制的反饋和變化，以及若不能為功能給出相關評分我們該如何繼續。

此處引用一句話進行結尾：

“人們認為專注意味著對你必須專注的事情說是。但這根本不是它的意思。這意味著對其他一百個好主意說不。你必須仔細挑選。我為我們沒有做過的事情和我做過的事情一樣感到自豪。創新是對 1000 件事情說不?！?/p>

——史蒂夫·喬布斯