作者結合自己的實際工作經驗，分享了對“平臺功能宏”的一些看法，希望能夠給你帶來一點幫助。

前一段時間在工作時，推動了“平臺功能宏”的搭建和需求評估流程，實現了二者的落地，今天著重寫一寫“平臺功能宏”，雖然是一個微小的點，但是運用得當的話，對于需求管控、研發成本都會有一個比較大的提高。

1.什么是”平臺功能宏“？

先來說說什么是宏？所謂的宏其實就是用于批量處理的一種規則，而功能宏就是批量處理某種需求或功能的規則，平臺功能宏就是全平臺開發公用的、用于批量處理跨平臺（或項目）功能的規則（大多情況下為開關），涉及到的項目和平臺較多，一般也會將開發好的”平臺功能宏“分類存儲和維護。

2.“平臺功能宏”的使用場景？

滿足以下幾個條件就能使用“平臺功能宏”了：

1. 不同軟件項目基于相同平臺或（主分支）；
2. 不同的軟件項目有針對同一個功能差異化的需求。

解釋下2，項目A可能要帶上某個功能，但是項目B不希望帶上這個功能，還有其他項目也有這一差異化的需求，如果出現了這樣的情況就可以使用”平臺功能宏“了。

3.怎么使用“平臺功能宏”？

在開發一個共性的平臺需求或者客戶需求時，研發人員開發功能宏開關或者全平臺修改代碼，產品經理們收集記錄宏開關和log記錄，不斷維護”平臺功能宏“。

舉個簡單的例子，項目A、項目B、項目C都是基于android L平臺的，在做項目時，發現A和B兩個項目都想帶上功能1，項目C不想帶上功能1，那么就可以在android L平臺增加關于功能1的“平臺功能宏”了，就是直接在平臺上修改代碼，通過關鍵字來控制功能，項目A、項目B、項目C自己通過配置文件關鍵字的值適配就可以了。

在記錄時有個基本表格可參考：

• 序號：編號，不在贅述
• 模塊：平臺或客戶需求涉及的大模塊
• 細分名稱：需求的名稱(比如：增加商品歌曲評論功能)
• 需求描述：需求具體描述(在xxx地方增加xxx，實現xxx功能等具體的描述)
• 優先級：一般都會給需求分優先級
• 客戶：某某odm客戶或者平臺需求
• 補充說明：功能宏的開關或者bug管理系統的記錄(比如：cr號)
• 相關平臺宏或客戶宏：記錄是客戶宏還是全平臺開的宏
• 已完成的平臺or項目參考：記錄之前已經完成過的代碼流、分支、項目等

上述是最基本項目的說明，其實在實際操作中可以針對性增加或刪除。

4.“平臺功能宏”的意義？

“平臺功能宏”有什么意義？當“平臺功能宏”逐漸豐滿的時候，首先是優化了需求池，更好地梳理需求，其次可以針對不同模塊、項目、平臺在實現相同功能的差異化需求時，通過控制平臺或主分支代碼，盡量避免開發人員多次寫重復的代碼，從而大大降低了開發和溝通的成本。此外，甚至可以對于不同國家的軟件版本和項目都能得到有效的控制，為未來的軟件國際一體化打下良好的基礎，但是同時也會增加平臺、主分支的負擔，最明顯的就是代碼會增加，因此也要斟酌運用。

本文由 @虛偽的溫柔 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議