前言

技術人員轉型產品經理（Product Manager）併成功的有很多例子。牛逼的業界大佬有Pony馬、雷布斯、張小龍、周鴻禕等；不算牛逼但也做出不俗成果的有你身邊的 XXX、YYY、ZZZ 等。

現在網際網路業界大多數to B （即對企業級，區別於to C）的 IaaS 或者 PaaS，如各種雲端計算服務、儲存服務、安全服務、資料服務、監控服務、日誌分析服務、DevOps服務等產品，顯然是一群既精通技術又懂產品設計的人所創造出來的。所以，技術和產品這兩項能力並非相互對立的，而是根據工作所遇的實際業務情況來選擇所需的思維能力，取長補短。

在知乎上看了大多數關於怎麼入門產品經理的回答，基本上各有各說法，沒有一個絕對權威的培養模式。不像程式設計師的養成方法，基本遵循「資料結構 + 程式語言 + 常見演算法 + 常見框架 + 設計模式 + 大量編碼」這樣的業界主流套路，產品經理沒有所謂的科班出身，大部分 to C 業務招聘 PM 也不限制專業，而且大多都是放養式的培養方法，一旦跟對了好導師或者好專案，成長飛快，否則……呵呵。不然也不會存在那麼多碼農想砍 PM 的段子。

為避免離題，本文預設前提就是定位於技術型的產品經理，而非對各種to C的五花八門業務形態。另外，雖然 title 有經理二字，但這並非一個管理職能，而是一個專業職能，可以理解為產品規劃師或者產品設計師。然後，我們再把議題聚焦到運維團隊設計與開發自動化平臺這一個具體的實踐過程，以及運維工程師們應該怎樣理解和應用產品經理能力。

什麼是產品經理能力

作為技術人員看到這個指標首先會感覺很虛，因為我們通常都是習慣了「Talk is cheap，show me code」的思維模式，但產品經理偏偏是一個以 Talk 為主的職能角色，這個核心思維模式的差異就決定了 PM 和碼農之間必然存在著某種代溝。

然而，一個好的 PM 能透過各種繁雜的技術細節找到問題的核心本質，也能製作出一份邏輯清晰、細緻、合理、能創造價值的 Talk，能最大程度地避免無意義的需求變更和回爐。另外，好的 PM 也是 Dev 的良師益友，特別是技術型的 PM 會著重於邏輯、落地、可行性、價值變現等細節，而非三天兩頭突然給你來個拍腦袋的所謂創意。

總的來說，優秀的產品經理至少需要具備以下能力：完備的邏輯能力、對業務細節的把控能力、對團隊資源的統籌規劃能力、時間和目標管理能力、ownership、自驅力等等。顯然，這些能力對於優秀的技術人員也是適用的，正如前文所說技術和產品能力並非對立而是可以互補。

產品經理能力在運維工作中的應用

回到正題，談談運維平臺的設計和研發過程中該怎麼應用 PM 能力。

一個產品的生命週期主要階段有：市場調研、競品分析、產品規劃、產品設計、需求分析、需求評審、編碼實現、產品驗收、持續迭代等等，但我們真正做運維內部平臺時肯定用不著每個步驟都刻意去走一遍流程，比如前期的競品分析之類的權重可以弱化。

產品規劃階段包含比較多的子步驟，對於運維平臺建設，我們至少要理清這些問題：

• 平臺面向的使用者有哪些，使用者角色怎麼劃分許可權，例如運維、專案研發、產品/策劃、QA、運營等；
•  每週、每月預計有多少的使用頻率，預計能為運維團隊節約多少人力資源；有無開源或者商業解決方案，和自研對比有何優缺點；
• 開發週期預計時長，研發人力成本預估，第一個版本需要達到怎樣的效果；

可以看出，這些過程中已經包含了「市場調研」、「競品分析」等子步驟，因為對於面向公司內部的系統，這兩個子步驟的執行復雜度和權重都是比較低的，可以直接歸併到「產品規劃」中。

然而前面所述的都是一些具體問題細節，屬於戰術層面，產品經理真正要做的是以更高的戰略層面思考整個運維團隊所需要規劃的內容。

對於運維團隊來說，產品規劃是團隊工作方向的綱領性指導思想，為了統一團隊目標以及提高團隊凝聚力，直白來說就是讓整個運維團隊都能圍繞在一個核心目標來開展工作，形成團隊合力。舉個例子，比如當前我們面臨的情況是監控不到位，故障發生時運維團隊卻後知後覺，所以季度規劃就是建設一套精細化、層次化、模組化的監控體系。其他旁枝末節的事務在不影響線上環境穩定執行的前提下暫時擱置，整合整個團隊力量來完成季度目標，業務結果導向。

戰略面要思考的核心分別是運維團隊面臨的「問題」、我們所擁有的「資源」以及為了解決這些問題要達到怎樣的「目標」，思維導圖如下：

以上是一個比較全面的問題集合，但我們還要在其中找到核心重點，按優先順序逐個擊破，不能為了追求面面俱到而分散精力。

那麼問題來了，要怎麼知道當前面臨的問題是什麼以及該達到怎樣的目標？

這種時候，能否分析出問題和得到解決方案就是運維團隊價值的體現了，只能取決於決策者的能力和經驗。

需求分析階段算是整個開發週期最核心的部分，說其決定了專案成敗也不為過。

• 平臺由哪些功能模組組成；
• 眾多模組的實現的優先順序排序；
• 功能模組之間的相互依賴關係；
• 每個功能模組預計完成時間；

這一步需要和團隊的資深運維和運維開發同事反覆進行，特別是針對一些實現難度或者複雜度較高的環節。

這個步驟的目的也是為了完善上面的需求分析，Step 3 和 Step 2 可能需要反覆執行幾次，直到把需求完善到整個團隊都能一致通過為止。

在這個過程中，也需要幫助運維開發理解業務情況，通過反覆的會議討論加深他們對運維業務的理解，因為運維開發未必都真正操作過一線的運維工作，如何能讓他們更快、更好地正確理解運維工作也是本階段的重點。

在這裡開始需要和開發同事有更多的互動，包含且不限於：

• 協助開發同事正確理解運維業務和功能需求；
• 將大的任務分解成可分配的獨立小任務，統籌分配開發人力資源；
• 對需求迭代進行質量與進度的把控，推進功能上線，如有遇到方向跑偏則及時修正；
• 共同解決某些疑難運維技術問題；

在這個階段為了更好地和開發同事溝通協作，運維產品經理要具備必須的面向物件思維，如：

•  面向物件：類、物件、介面、封裝、繼承、多型
• 設計原則：低耦合高內聚、單一職責、開閉原則、介面隔離
• 設計模式：單例、工廠、原型、反射、介面卡、裝飾器
• 軟體開發過程：需求模型、領域模型、設計模型、實現模型
• 圖例：UML、用例圖、類圖、結構圖、系統順序圖

運維同事雖然編碼能力遠遠比不上研發同事，但在某些巨集觀概念上的理解也要和他們達成一致共識，所以我們需要學習這些編碼理論指導方法論。當運維深入理解這些理論之後，對於需求設計也是具有指導意義的。你會潛移默化地把一些功能模組化封裝、分層、複用，儘管未必參與實際的編碼過程，但對於整個軟體架構體系的理解也是可以做到的。

另外，對於開發實踐過程也可以做更加合理地引導，如核心基礎元件API化，向上提供業務層的服務能力，具體例子如修改XX功能，你會馬上知道只需要稍微改一下底層的YY模組，不需要動ZZ模組。

作為技術型產品經理，需要理清所謂的技術邊界，即什麼事情在技術層面能否實現？是否容易實現？業務也必然存在約束與限制，成本與收益是否平衡需要在產品經理這一個環節就要確定，絕不能讓開發花費了大量工作時間才後知後覺發現事情收益太小不值得做。技術層面的約束和限制在運維平臺的設計中起著重要的作用，它可以作為是架構設計的原點環節，也可以是功能迭代的驅動元素。

在這個過程中，運維產品經理需要做到：

• 深刻理解系統的每個層次模組的定位和向上向下的意義延伸；
• 能結合運維業務理解和技術理解的雙緯度協助開發同事對系統架構的優化和調整；
• 用最少的研發人力獲得最大的邊際收益，即簡單問題簡單解決，複雜問題則創造條件來簡單解決；
• 能使得系統架構以及功能規劃儘量得適用於後期的業務需求發展；
• 利用自身的運維技術背景來預見未來可能面臨的問題，考慮長遠並避免無意義的重構；

總的來說，就是在效率、效能、成本、可靠性、擴充套件性、時間進度、人力資源等眾多因素中綜合考量得出一個相對較優的方案。

這個過程通常是很艱辛的，因為這幾個因素相互制約：要想快速出成果就要多加人力資源趕進度；想做到高可用高效能就要考慮複雜的架構方案，這可能會延緩進度和提高成本；想快速交付就不能太多考慮擴充套件性等等。

又要馬兒跑，又要馬兒不吃草幾乎是不可能的。

如果沒有什麼特殊考量的話，以小目標來驅動快速交付永遠是正確的，因為老闆、領導、業務側不可能等一年半載的時間來完成一個大project，更多時候需要的是快速落地見成果。

因此，最佳策略是既能滿足需求，又稍微超越使用者的期望，讓使用者對我們的下一次迭代更新有更高的期待。所以我們不要奢望做一個完美主義者，網際網路的工作模式是快速迭代、快速調整。

建設一個完整的運維平臺是個大工程，需要注意產品驗收需要先針對每一項獨立的小功能，再上升到完整的產品層面。切忌不分主次、貪多求全，必須以小目標驅動整個系統研發的過程。

打造一個好的系統是不可能一蹴而就的，需要經歷反覆打磨、推翻、重構等一系列的過程才能完善起來。（太雞湯的內容就不多寫了……）

業務價值挖掘

這一部分主要是需要產品經理以更高緯度提煉以及量化我們所做產品的價值。

先舉一些其它業務形態的例子：某某業務功能同比增加了多少活躍使用者、提高了多少付費率，為公司創造了多少GDP等。

畢竟我們做運維平臺的意義就是：對內價值用降低了多少故障率、提升了多少工作效率、節約了多少人力資源等來體現；最好是不僅將其定位為一個內部輔助系統，需要將其和業務側的牆打破，介入業務發展的生命週期，這樣做才能將運維價值最大化地變現。

運維平臺中和業務運營相關密切的功能模組一般有資料分析、彈性伸縮、成本核算、使用者體驗優化等等，如何才能包裝好運維平臺和為其講一個好故事，也是運維產品經理的職責所在。讓不瞭解運維業務的領導們或者外部門的同事們都能理解、認可運維價值，意義是非常重大的。

講故事的核心一般是圍繞四要素：「質量」、「效率」、「安全」、「成本」，每年的業績、KPI、成果彙報不外乎都是落在這四個緯度。

怎麼體現整個運維團隊的價值體現，簡單粗暴就是資料說話，因為老闆們才不管運維團隊具體用了什麼黑科技。

比如：

• 核心業務全年可用時間達 99.999%，全年故障次數低於 3 次；
• 人均維護機器數 10000 以上，人均維護業務叢集數 5 個以上；
• 日持續釋出頻率達到 30 以上，故障率低於 0.1%，釋出時長低於 60 秒；
• 大資料平臺數據量 1000T 以上，全國 CDN 流量 10000G 以上；
• 硬體成本降低50%，每年為公司節省10個億；

備註：以上資料純屬虛構。

總結

所謂的產品思維在不同的業務形態中可以演化出不同的能力，而運維也是一種特殊的業務形態，我們可以利用產品思維來更好地解決工作中遇到的問題。

把運維服務當作一種產品，我們可以將這個產品平臺化、精細化、實體化，通過實踐DevOps 理念，打破業務側、研發側以及運維側之間無形的牆， 然後用一種類似 PaaS 的方式來為業務團隊提供高質量、高效能、高可用、低成本、快速的運維體系服務。基於產品思維來驅動運維團隊，也許能讓運維工作更有意思。

作者：

溫崢峰，百田資訊運維技術專家，DevOps Team Leader，超過8年網際網路運維經驗，曾就職於網易遊戲，經受過各類海量規模網際網路業務模式的歷練，專注於運維自動化、DevOps實踐、運維服務體系建設與SRE時代下的運維價值挖掘。

知乎專欄：https://zhuanlan.zhihu.com/hiphone-devops

原文來自微信公眾號：DBAplus社群