都問研發管理如何管，我想談一談研發管理如何理

Worktile

+ 關注

2022-01-17 10:15

793次閱讀

這兩個月一直全身心的投入到公司的產品研發中，始終沒有安靜下來寫點東西，前幾天應邀在線上進行了一場研發管理主題的分享，效果還不錯，收到很多朋友的消息。我覺得這個話題可以更深入一些，索性寫一篇文章吧。

01“我想改一個字”

我們先從一個需求變更說起，如果客戶想改一個字，那么你的應對方法是怎樣的呢？

1、直接走到開發的面前讓他改了，因為這是“順手”的事。

2、告知需求方需求變更的成本（改需求文檔、配置文件、測試用例、用戶手冊等）和風險（因為工作量的變化影響交付時間），讓需求方知難而退或者轉化為自己的談判籌碼。

3、放入需求池，設置優先級，盡量安排到下個迭代。

第一種方法的破壞性極大，看似我們在個例上非常“敏捷”，也貌似可以省去很多“不必要”的工作，但是它破壞了流程，破壞了團隊的工作流。研發的流程不是為了限制創造力，而是為了保護創造力。

如果缺少流程的保護，那么產研體系的員工就會在各類突發性工作中東奔西走，導致團隊無法制定有效的工作計劃，也無法準確的預估結果，更沒有一種穩定的交付能力。

第二種方法因為有嚴格的風險把控和時間節點要求，因此往往能夠履行交付承諾。但是它對于變化的響應能力太差，往往變更都要經歷復雜的流程，而且經常性的牽一發而動全身。對于需要根據市場反應及時調整策略的互聯網產品來說，這樣的開發方式實在是跟不上節奏。

第三種方法有較強的節奏感，周期性的完成一個產品增量，它比第二種方式靈活，也不會像第一種那么冒進。不過這樣就夠了嗎？

02 工作流管道

設想我們有這樣一個管道，當新的需求來的時候，可以將它們引入管道中，它們像水一樣流動到生產環境，在這個過程中流動是快速的、單向的、穩定的、持續的、高質量的，最終它們在用戶無感知的情況下生效。我們可以擴大管道的直徑從而實現量化，也可以分割產品建立多條相似的工作流管道。

有了這樣的工作流管道，我們的產品它要么是正在部署，要么就是準備部署。那么我們的產品對外提供的服務是什么樣的呢？

用一句話形容就是：用戶每一次體驗到的都是更好的服務。這句話有點太夸張了，不過這樣的工作流是存在的，并且早已應用于領先的互聯網公司中。

03 研發管理如何理

搭建和優化工作流的過程其實就是“理”的過程，這里我總結有五點核心原則：

讓無形的工作顯現出來

經常接觸開發工程師的人都知道，如果不借助外部工具，真實的進度只有寫代碼的那個人才知道。對于管理者來說，通過流程和工具將無形的工作顯示出來非常重要，因為工作流的可視化是基礎，當一切暴露在陽光下，管理者才知道如何“管”。

我的研發團隊使用的管理工具是PingCode，我會要求所有的工作必須有一個工作項卡片進行跟蹤，而所有人都需要及時的領取任務、拖拽卡片、更改狀態、拆分子任務、關聯代碼、關聯構建、提供驗收說明等等，通過這些“習慣性動作”讓工作進度顯現出來。

定義完成的定義，配合拉動策略，讓工作“流動”起來

根據DevOps的第一工作法，我們要建立一個從左到右的工作流，這個工作流的每個階段都要有清晰的輸入和輸出，然后通過標準化的輸入和輸出，將它們組裝成一個順暢的工作流管道。工作流梳理完成后，我們通過拉動策略讓工作進行“流動”。

例如：當我完成一件工作時（一定要符合我和下游約定的完成的定義），我的下游可以將這個工作拉過去繼續做，而我則可以在我的上游拉另一件工作繼續做。對于“我”個人而言，只要“我”現在空閑，同時看到上游有一件工作標記為完成，那么“我”就拉過來繼續做，然后將它標記為完成，每個階段的“我”使用同樣的工作策略，這些“我”讓工作持續的流動。

引入自動化，讓速度和質量并存，摸索適合自己的持續交付方案

當我們開始運轉工作流的時候就會發現，有些高度重復化的工作非常的占用人力資源，比如工程師修改了代碼之后有可能影響任何一個功能，那么回歸測試就有其必要性，但是每次變更都需要人工來回歸嗎？

要知道回歸一次的時間是非常長的，但是不測試又無法保障質量（積累多次變更后統一回歸，并不符合我們建立上述工作流的初衷）。這時引入自動化是最好的選擇，我相信朋友們對于CI/CD、流水線這些詞匯并不陌生，但是很多人并沒有創建和維護好自己的自動化腳本，這個我打算下一期專門講一講如何讓研發和測試這兩個角色合二為一，有效的落地一套面向研發過程的測試方案。