將平臺開發(fā)從項目轉(zhuǎn)向產(chǎn)品

作者 ｜ Ben Linders

譯者 ｜ 平川

在 KubeCon & CloudNativeCon 歐洲大會 上，Eugenia Bergman 和 Hagen Tonnies 分享了他們?nèi)绾卧谄脚_規(guī)模超出單個團隊使用的范圍后，從項目思維轉(zhuǎn)向產(chǎn)品思維。他們認為，平臺存在的局限性包括一次性交付、缺乏產(chǎn)品愿景以及反饋循環(huán)薄弱。如今，他們已經(jīng)轉(zhuǎn)向一種 API 驅(qū)動的自助式多租戶基礎(chǔ)設(shè)施。該架構(gòu)擁有更清晰的責(zé)任歸屬和更完善的抽象層。

Bergman 提到，他們平臺的開發(fā)周期是圍繞年度項目規(guī)劃來組織的。工作通常從前期范圍界定、預(yù)算分配和明確交付里程碑開始。每個項目都被視為一個具有明確起止時間的獨立項目，其成功與否取決于是否在范圍、時間和里程碑方面都達到了預(yù)期目標(biāo)：

當(dāng)平臺僅支持向提供游戲流媒體產(chǎn)品的組織提供單一服務(wù)時，這種模式運轉(zhuǎn)良好。但隨著時間的推移，我們的平臺需要逐漸演變，從而支持多個具有不同需求的內(nèi)部團隊。這從根本上改變了系統(tǒng)的性質(zhì)。

Bergman 提到了他們認為該平臺存在的幾個局限性：

-每次改進都被視為一次性交付 - 這會導(dǎo)致積累的功能在優(yōu)先級上與下一輪交付產(chǎn)生沖突 - 該平臺沒有明確的產(chǎn)品定義

Bergman 表示，雖然他們是持續(xù)交付，但并未能始終如一地改善整個平臺的易用性或一致性。反饋循環(huán)主要在內(nèi)部進行，圍繞沖刺表現(xiàn)（速度、完成率、質(zhì)量）展開，幾乎沒有來自平臺實際用戶的驗證。系統(tǒng)優(yōu)化針對的是任務(wù)完成率，而非長期價值。

Tonnies 解釋說，在外部影響與內(nèi)部反思的雙重啟發(fā)下，他們從項目導(dǎo)向轉(zhuǎn)變?yōu)楫a(chǎn)品導(dǎo)向：

我們有些早期的同行就已經(jīng)開始引入系統(tǒng)思維和產(chǎn)品思維，借鑒 Prometheus 和 Grafana 等開源生態(tài)系統(tǒng)的實踐。而在內(nèi)部，我們也開始研讀《從項目到產(chǎn)品》和《鳳凰計劃》等著作，從中認清了我們自身面臨的許多痛點。

Tonnies 表示，這促使架構(gòu)師和高級工程師之間形成了一個小型實踐社區(qū)，他們在其中就這些想法展開討論，并探索當(dāng)前模型的替代方案。

Tonnies 解釋道，隨著時間的推移，他們的開發(fā)平臺發(fā)生了顯著的演變。它從來都不是一個統(tǒng)一的平臺，而是一套圍繞 Kubernetes 和 GitOps 實踐有機發(fā)展起來的能力集：

早期，該平臺以基于 Helm 的部署、命名空間級資源管控、GitLab 驅(qū)動的工作流為核心，團隊通過內(nèi)部 IDP 模式加入，并主要在共享集群中運行。在標(biāo)準(zhǔn)化應(yīng)用程序交付方面，這種模式效果良好，但主要是針對單服務(wù)團隊進行優(yōu)化，未能完全滿足更廣泛的多租戶需求或更復(fù)雜的基礎(chǔ)設(shè)施需求。

隨著其生態(tài)系統(tǒng)的擴展，尤其是隨著 AWS 等公有云服務(wù)的推出，他們觀察到，用戶期望自然而然地發(fā)生了轉(zhuǎn)變：團隊逐漸習(xí)慣了自助式基礎(chǔ)設(shè)施和更清晰的所有權(quán)模式。Tonnies 解釋道，這凸顯了他們改善內(nèi)部平臺體驗的機遇，特別是在抽象化、文檔編寫以及實現(xiàn)平臺與用戶職責(zé)之間更明確的關(guān)注點分離方面：

我們一直在向更關(guān)注產(chǎn)品的平臺模式演進。該模式具有更清晰的租戶邊界、更強大的自助服務(wù)能力，以及更明確的基礎(chǔ)設(shè)施配置和管理接口。

Tonnies 總結(jié)道，如今，他們正在投資于更高層次的抽象概念，例如環(huán)境和項目構(gòu)造，以及更貼合云服務(wù)提供商范式的 API 驅(qū)動型工作流。這是一個持續(xù)進行的過程，但方向很明確：朝著更具可擴展性、以用戶為中心的松耦合平臺邁進。該平臺既能賦能團隊，又能在整個組織內(nèi)保持一致性和有效的治理。

InfoQ 就其平臺向產(chǎn)品化模式轉(zhuǎn)型一事，對Eugenia Bergman和Hagen Tonnies進行了專訪。

InfoQ：是什么促使你們從項目導(dǎo)向轉(zhuǎn)變?yōu)楫a(chǎn)品導(dǎo)向？

Eugenia Bergman：這一轉(zhuǎn)變并非源于某一項單獨的決策，而是由一系列我們無法再忽視的信號所驅(qū)動。我們觀察到：

• 盡管采用了持續(xù)交付，待辦事項卻仍然在不斷增加

• 其他團隊會繞過平臺開展工作，而非利用它

• 我們無法明確回答：我們構(gòu)建的東西是否真的被使用了

• 我們并不總是能明確地回答：我們是否支持某些功能，甚至這些功能是否屬于我們平臺提供服務(wù)的范圍

與此同時，我們意識到，自己不再僅僅是交付基礎(chǔ)設(shè)施，而是向內(nèi)部客戶提供能力。這需要采取不同的方法：

• 從交付功能 → 到解決用戶問題

• 從固定范圍 → 到假設(shè)驅(qū)動的路線圖

• 從輸出指標(biāo) → 到采用率和可用性信號

從這個意義上說，轉(zhuǎn)向產(chǎn)品化方法與其說是一次轉(zhuǎn)型舉措，不如說是對規(guī)模擴張的必要適應(yīng)。

Hagen Tonnies：這種轉(zhuǎn)變也源于長期以來對 Scrum 的懷疑態(tài)度。雖然我認可它的框架，但它往往無法真正地體現(xiàn)實際成果，也無法為團隊營造合適的環(huán)境。產(chǎn)品思維似乎是一條能夠更好地協(xié)調(diào)工程工作、用戶價值和團隊體驗的途徑。

InfoQ：你們的開發(fā)平臺什么樣？

Bergman：從宏觀層面來看，我們的開發(fā)平臺就像一個內(nèi)部云服務(wù)提供商。

它提供了諸如 Kubernetes 集群、存儲、網(wǎng)絡(luò)以及支撐平臺服務(wù)等基礎(chǔ)設(shè)施能力。這些能力通過自助服務(wù)接口提供，主要采用 Kubernetes 原生模式，例如 API 和自定義資源。

從開發(fā)者的角度來看，目標(biāo)是：

• 以代碼形式配置基礎(chǔ)設(shè)施

• 將平臺能力直接集成到工作流中

• 避免手動協(xié)調(diào)或基于工單的流程

在內(nèi)部，該平臺的架構(gòu)圍繞服務(wù)層、控制層和管理層之間的關(guān)注點分離展開，采用可組合的構(gòu)建模塊來抽象底層基礎(chǔ)設(shè)施，并通過契約來定義各層之間穩(wěn)定的接口。

https://www.infoq.com/news/2026/07/platform-projects-products/

聲明：本文由 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。