都問研發(fā)管理如何管，我想談一談研發(fā)管理如何理

Worktile

+ 關(guān)注

2022-01-17 10:15

744次閱讀

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

01“我想改一個(gè)字”

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

1、直接走到開發(fā)的面前讓他改了，因?yàn)檫@是“順手”的事。

2、告知需求方需求變更的成本（改需求文檔、配置文件、測試用例、用戶手冊等）和風(fēng)險(xiǎn)（因?yàn)楣ぷ髁康淖兓绊懡桓稌r(shí)間），讓需求方知難而退或者轉(zhuǎn)化為自己的談判籌碼。

3、放入需求池，設(shè)置優(yōu)先級，盡量安排到下個(gè)迭代。

第一種方法的破壞性極大，看似我們在個(gè)例上非常“敏捷”，也貌似可以省去很多“不必要”的工作，但是它破壞了流程，破壞了團(tuán)隊(duì)的工作流。研發(fā)的流程不是為了限制創(chuàng)造力，而是為了保護(hù)創(chuàng)造力。

如果缺少流程的保護(hù)，那么產(chǎn)研體系的員工就會在各類突發(fā)性工作中東奔西走，導(dǎo)致團(tuán)隊(duì)無法制定有效的工作計(jì)劃，也無法準(zhǔn)確的預(yù)估結(jié)果，更沒有一種穩(wěn)定的交付能力。

第二種方法因?yàn)橛袊?yán)格的風(fēng)險(xiǎn)把控和時(shí)間節(jié)點(diǎn)要求，因此往往能夠履行交付承諾。但是它對于變化的響應(yīng)能力太差，往往變更都要經(jīng)歷復(fù)雜的流程，而且經(jīng)常性的牽一發(fā)而動全身。對于需要根據(jù)市場反應(yīng)及時(shí)調(diào)整策略的互聯(lián)網(wǎng)產(chǎn)品來說，這樣的開發(fā)方式實(shí)在是跟不上節(jié)奏。

第三種方法有較強(qiáng)的節(jié)奏感，周期性的完成一個(gè)產(chǎn)品增量，它比第二種方式靈活，也不會像第一種那么冒進(jìn)。不過這樣就夠了嗎？

02 工作流管道

設(shè)想我們有這樣一個(gè)管道，當(dāng)新的需求來的時(shí)候，可以將它們引入管道中，它們像水一樣流動到生產(chǎn)環(huán)境，在這個(gè)過程中流動是快速的、單向的、穩(wěn)定的、持續(xù)的、高質(zhì)量的，最終它們在用戶無感知的情況下生效。我們可以擴(kuò)大管道的直徑從而實(shí)現(xiàn)量化，也可以分割產(chǎn)品建立多條相似的工作流管道。

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

用一句話形容就是：用戶每一次體驗(yàn)到的都是更好的服務(wù)。這句話有點(diǎn)太夸張了，不過這樣的工作流是存在的，并且早已應(yīng)用于領(lǐng)先的互聯(lián)網(wǎng)公司中。

03 研發(fā)管理如何理

搭建和優(yōu)化工作流的過程其實(shí)就是“理”的過程，這里我總結(jié)有五點(diǎn)核心原則：

讓無形的工作顯現(xiàn)出來

經(jīng)常接觸開發(fā)工程師的人都知道，如果不借助外部工具，真實(shí)的進(jìn)度只有寫代碼的那個(gè)人才知道。對于管理者來說，通過流程和工具將無形的工作顯示出來非常重要，因?yàn)楣ぷ髁鞯目梢暬腔A(chǔ)，當(dāng)一切暴露在陽光下，管理者才知道如何“管”。

我的研發(fā)團(tuán)隊(duì)使用的管理工具是PingCode，我會要求所有的工作必須有一個(gè)工作項(xiàng)卡片進(jìn)行跟蹤，而所有人都需要及時(shí)的領(lǐng)取任務(wù)、拖拽卡片、更改狀態(tài)、拆分子任務(wù)、關(guān)聯(lián)代碼、關(guān)聯(lián)構(gòu)建、提供驗(yàn)收說明等等，通過這些“習(xí)慣性動作”讓工作進(jìn)度顯現(xiàn)出來。

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

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

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

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

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

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

Being agile，適應(yīng)變化，不斷優(yōu)化工作流

敏捷開發(fā)最重要的還是價(jià)值觀，是內(nèi)功。而無論是Scrum還是Kanban，歸根到底是通過行為約束讓使用者在不知道法門的情況下也能成為高手。我認(rèn)為無論是團(tuán)隊(duì)級別實(shí)施敏捷，開始企業(yè)級轉(zhuǎn)型敏捷，更關(guān)注的應(yīng)該是發(fā)展，一種面對變化能夠從心態(tài)和行動都及時(shí)進(jìn)行調(diào)整的能力。

真正落實(shí)到日常工作中，就是讓所有人主動領(lǐng)取和負(fù)責(zé)工作，當(dāng)目標(biāo)沒有完成時(shí)是全部人的責(zé)任，而不是部分人的責(zé)任。讓所有人參與到工作流的改進(jìn)中，在一個(gè)周期內(nèi)加入20%的非功能性需求，盡情的去優(yōu)化自動化，去調(diào)整系統(tǒng)結(jié)構(gòu)，去創(chuàng)造去發(fā)展。

建立包容的文化，讓問題暴露出來，促進(jìn)企業(yè)進(jìn)化

很多人一看到文化，第一反應(yīng)是這個(gè)有點(diǎn)虛，但是職位越高，越能真切的體會到文化的重要性，人少的時(shí)候很多事當(dāng)面說就好了，但是人多的時(shí)候，我們需要通過文化作為載體傳達(dá)我們的行事原則。

因?yàn)槠膯栴}，今天我不想分享的太大，我只說兩個(gè)在團(tuán)隊(duì)級別就能落實(shí)并且十分有效的方法：周期性全員回顧和月度1v1。

周期性回顧其實(shí)就是Scrum里的Sprint Retrorespective，所有人在一起提出我們流程上的問題，我們一起制定改進(jìn)計(jì)劃，并在未來的回顧中驗(yàn)證計(jì)劃是否奏效。回顧是團(tuán)隊(duì)自我改進(jìn)最有效的方式，也是讓團(tuán)隊(duì)成員把“怨念”釋放出來的機(jī)會，一個(gè)能夠自我優(yōu)化的團(tuán)隊(duì)一定少不了類似的會議。

月度1v1是我在外企學(xué)來的經(jīng)驗(yàn)，那時(shí)候我通過1v1向我的老板表達(dá)我的想法，后來我也一直通過它管理我的團(tuán)隊(duì)。我在1v1上討論近期的工作、討論工作流程、討論成長方向，我有時(shí)扮演導(dǎo)師、有時(shí)扮演傾聽者、有時(shí)扮演鼓勵(lì)師，我通過1v1了解我的團(tuán)隊(duì)，也將他們真切的想法反饋給我的老板。