敏捷轉(zhuǎn)型涉及到流程建設(shè)、人員培訓(xùn)、平臺建設(shè)、軟件架構(gòu)優(yōu)化等，一家公司要想成功地完成敏捷轉(zhuǎn)型并非易事。

一件事情，干了36個月，想想還真是蠻長的。作為一家傳統(tǒng)公司（消費類電子）在進行智能硬件產(chǎn)品研發(fā)時進行敏捷轉(zhuǎn)型，當前的結(jié)果還是比較令人滿意。

公司沒有專門的人做這個事情，都是業(yè)務(wù)部門的人兼職做，所以不要給自己設(shè)定邊界，認為是一件對的事情，就持續(xù)堅持吧！

一、敏捷轉(zhuǎn)型的目標與關(guān)鍵成果

目標

敏捷開發(fā)達到業(yè)界優(yōu)秀水平，更快速的響應(yīng)市場需求。

關(guān)鍵成果

1. 可以任意指定用戶群進行特性發(fā)布。
2. 每周都可以對外進行特性發(fā)布。
3. 各軟件專業(yè)發(fā)布互不依賴，獨立規(guī)劃、獨立發(fā)布。
4. 版本規(guī)劃、需求、資源、阻塞問題可以高度透明，及時同步。

二、敏捷轉(zhuǎn)型的困難

敏捷轉(zhuǎn)型是一項系統(tǒng)性工程，涉及到流程建設(shè)、人員培訓(xùn)、平臺建設(shè)、軟件架構(gòu)優(yōu)化，所以一家公司要成功的完成敏捷轉(zhuǎn)型，往往比較困難，極其容易在轉(zhuǎn)型初期形成敏捷無法有效提升研發(fā)效率的錯覺，變得消極，難以突破。而且大家在談?wù)撁艚輹r，往往更多的談及敏捷在流程上的改造，卻容易忽略其他方面的重要性。

流程建設(shè)

流程建設(shè)在初期必然會和已有的流程產(chǎn)生一些沖突，如果一上來就全面替換現(xiàn)有的所有流程，必然引起強烈的不適。

更何況，在敏捷轉(zhuǎn)型初期，我們對敏捷的理解往往還不到位，制定出來的流程往往存在不少缺陷，即使全面替換，也不能保障效率的提升，甚至還會導(dǎo)致效率的下降，打擊大家轉(zhuǎn)型的積極性。而且流程制定一定要結(jié)合企業(yè)的特點，不能完全照搬標準定義，這也考驗著我們對敏捷和業(yè)務(wù)理解的深度。

當我們設(shè)定了一個合理的流程后，順利的落地執(zhí)行依舊是一項挑戰(zhàn)。

忽略人員培訓(xùn)的重要性

由于在公司轉(zhuǎn)型初期本身理解敏捷這套方法論的人就不多，往往缺乏培訓(xùn)人員，或者缺乏明確的培訓(xùn)責任劃分，導(dǎo)致難以有效培訓(xùn)。

敏捷里面有一個scrum master的角色，這個角色的工作業(yè)績?nèi)鄙偬y以量化，我想很少有公司會設(shè)立專職的scrum master，即使我們在這條路上走了三年，依舊沒有這個角色。

另外，要打破我們固有的思維模式和工作習(xí)慣是一件比較難和需要持久進行的事情，在轉(zhuǎn)型期如果沒有明顯的提升，質(zhì)疑的聲音就會迎面撲來，大家會表達出想用以前的工作方法愿望。

忽略平臺建設(shè)

這個道理很簡單，給你一輛拖拉機你永遠都開不到法拉利的速度，不管你把其他方面做得多么極致。但是，當我們進行轉(zhuǎn)型時，要順利的完成相關(guān)的平臺建設(shè)，可不是一件容易的事情。

從我們轉(zhuǎn)型過程來看，我們在第三年才投入相關(guān)資源建設(shè)相關(guān)平臺，雖然我們一直在吐槽平臺難用，效率低。這里主要涉及到以下幾個問題：

1. 業(yè)務(wù)發(fā)展還不夠明朗，不舍得投入資源進行平臺建設(shè)。
2. 業(yè)務(wù)發(fā)展過于迅猛，研發(fā)資源都投入到了業(yè)務(wù)開發(fā)上。
3. 公司組織架構(gòu)問題，多部門目標不一致。
4. 缺乏對這件事情明確負責的人，三不管地帶。

所以，如果平臺建設(shè)不在業(yè)務(wù)線范圍內(nèi)明確其重要性，這件事情基本無法搞定。

軟件架構(gòu)優(yōu)化

軟件研發(fā)本身就是一件系統(tǒng)性工作，如果軟件架構(gòu)不合理，開發(fā)周期長、bug多、依賴重，同樣很難快起來。

當前的智能硬件產(chǎn)品，往往都涉及非常多的軟件專業(yè)，包括服務(wù)器、H5、Android、iOS等等，如果系統(tǒng)足夠復(fù)雜，前面的幾大專業(yè)還會細分出更多的專業(yè)。如果每個專業(yè)的發(fā)布需要依賴其他專業(yè)，那么很難快起來。

就像大家都在高速公路上跑，路上出了事故，大家都得慢下來，等出來完事故后，大家又得重新慢慢加速。

在春運期間我們很容易遇到，你發(fā)現(xiàn)把堵車的路段開完了也沒有看到事故，可以為什么還是堵車呢，事故處處理完后堵車路段為什么不能迅速疏通呢？

另外一方面，你用H5開發(fā)一個功能和用原生應(yīng)用開發(fā)一個功能，發(fā)布速度肯定有天壤之別。H5一天發(fā)幾十個版本都有可能做到，你用Android原生開發(fā)可能做到嗎？

三、流程建設(shè)

我們的產(chǎn)品涉及面廣，我們針對產(chǎn)品特點，分出來了多個特性小組，每個特性小組由產(chǎn)品經(jīng)理主導(dǎo)，作為特性交付的第一負責人，目前已成功運行的機制如下：

1. 特性團隊
2. 產(chǎn)品提案評審
3. 隊列填充會議
4. 晨會機制
5. 交互評審
6. 產(chǎn)品驗收
7. 版本火車發(fā)布
8. 灰度與全量發(fā)布
9. 大數(shù)據(jù)分析
10. ……

3.1.確保需求有價值

問題越早發(fā)現(xiàn)，帶來的收益就越高。

使用OKR梳理部門年度目標，基于部門年度目標，各專業(yè)梳理出自己的年度目標和季度目標，個人基于專業(yè)領(lǐng)域的年度和季度目標，梳理自己的季度目標。通過使用OKR這個工具，大家目標上下左右對齊，識別出正確的事情，避免不必要的資源和時間浪費。

產(chǎn)品團隊針對新的特性需求建立提案評審機制，保障新需求的質(zhì)量，雖然我們無法完成預(yù)見需求最終的市場表現(xiàn)，但是至少要做到邏輯上這個需求是靠譜的。特殊情況，一些需求大家很難達成一致，這個時候我們更趨向于允許這個需求進入研發(fā)，進行市場驗證。

每周五最后一小時召開固定的隊列填充會議，各領(lǐng)域負責人與產(chǎn)品經(jīng)理共同確認拉入的需求。避免產(chǎn)品經(jīng)理的單一視角，導(dǎo)致拉入一些不合理或者沒想清楚的需求。

3.2 確保需求優(yōu)先級達成一致

資源永遠是不夠的，所有優(yōu)先級在迭代過程中是必須要保障的事情，否則有可能導(dǎo)致一些重要的事情得不到足夠的資源，或者各領(lǐng)域之間互相扯皮，增加溝通成本。

特性小組要有自主性和獨立性，但是不能完全的獨立和自主，這樣他們很容易站在自己所負責的特性的狹隘視角安排迭代。另外我們要充分認識到不同產(chǎn)品經(jīng)理的能力是有所不同的，不能完全放權(quán)到產(chǎn)品經(jīng)理，否則很有可能因為產(chǎn)品經(jīng)理能力的不足，導(dǎo)致一個特性團隊處于混亂中。

建立需求準入審查機制，該機制可以在隊列填充會議上運行，產(chǎn)品經(jīng)理拉入研發(fā)的需求都需要讓各領(lǐng)域知曉，如果發(fā)現(xiàn)不合理的需求，可以在該會議上有效控制。

進入研發(fā)的需求需要通過交互評審，如果存在文檔，需要附上相關(guān)文檔內(nèi)容。該規(guī)定，也可以在隊列填充會議上有效控制。

3.3 確保進入研發(fā)的需求有相應(yīng)的研發(fā)資源

停止啟動，聚焦完成，我們迭代過程中一定要控制同時研發(fā)的需求量。否則你會發(fā)現(xiàn)每件事都在做，然而每件事情都需要很久才能做完。

控制研發(fā)看板上的需求數(shù)量，就需要控制流進和流出。所以大的原則是沒有需求做完前，不允許拉入需求。當然，如果研發(fā)看板本上的需求本來就比較少，或者說增加了研發(fā)人員，這里可以靈活控制。

隊列填充會議上給到多個特性小組互相協(xié)調(diào)資源的契機，也給到各專業(yè)負責人了解資源情況的一個契機。通過大家協(xié)調(diào)和調(diào)整資源，確保需求有對應(yīng)的資源進行研發(fā)。

3.4 確保研發(fā)過程足夠透明

信息透明是自組織的基礎(chǔ)，足夠的信息透明，才能讓討論和問題處理有完全的參考，才能高效協(xié)作和解決問題。

對于大型團隊一定是需要一個電子化工具支持研發(fā)信息的透明的，完全靠人是不合適的，這個市面上有相關(guān)產(chǎn)品，當然我們是自研的。為什么我們要自研呢？主要是為了保障產(chǎn)品敏感資料的安全性以及更好的適應(yīng)我們企業(yè)的流程。

晨會作為敏捷的一個標志性會議，是一定需要開的。我們能通過這個會議讓特性團隊的凝聚感更強，同時及時同步研發(fā)信息和問題，提升研發(fā)效率?？梢砸_好晨會也不容易，例如：

1. 存在團隊成員跨團隊的情況，導(dǎo)致你的晨會他不一定能參加。

2. 晨會人員過多，導(dǎo)致場面混亂。

3. 看板泳道設(shè)計不合理，導(dǎo)致信息可視性和可流動性差。

版本規(guī)劃要明確，我們要有一個電子平臺在里面公示版本信息，包括版本涉及領(lǐng)域、各個客戶端版本號、包含哪些需求、集成時間、發(fā)布時間等等。

四、人員培訓(xùn)

以人為本，不斷多好的流程、多好的工具，參與和使用它的人沒有掌握，都無法有效達成目標。

需要對全員培訓(xùn)敏捷的相關(guān)理論，并為他們答疑解惑，長期輔導(dǎo)。

可以針對《敏捷軟件開發(fā)實戰(zhàn)-估算與計劃》《看板方法》這兩本書里面的理論梳理培訓(xùn)大綱，同時也可以分享這兩本書給到團隊成員閱讀。

當敏捷適配到企業(yè)流程后，建立出適合企業(yè)的敏捷流程，在這個適配過程中，也需要不斷的給相關(guān)團隊成員培訓(xùn)流程建設(shè)的目的和意義。

五、平臺建設(shè)

持續(xù)集成平臺

軟件的構(gòu)建當下越來越復(fù)雜，類似于Jenkins、GitLab、各種靜態(tài)檢測、依賴管理、自動化測試都得做起來，使用以前的原始手段處理當下的軟件系統(tǒng)，效率是非常低的。

發(fā)布平臺

智能硬件的軟件發(fā)布可以分為多個層級，包括：OTA升級、應(yīng)用發(fā)布與升級、應(yīng)用內(nèi)功能開放與關(guān)閉、H5發(fā)布。為此，我們需要針對這些發(fā)布方式，構(gòu)建相關(guān)的后端發(fā)布平臺，支持相關(guān)業(yè)務(wù)人員可以簡單、高效、靈活的操作。

研發(fā)管理平臺

研發(fā)管理包括：版本管理、需求管理、任務(wù)管理、bug管理、發(fā)布管理等等，缺少這些平臺的支持，都會嚴重影響研發(fā)效率。

運營平臺

一個好的功能，還需要讓用戶知道。我們需要通過推送、彈窗等各種手段將運營信息傳達到用戶眼里。因此，也需要提供簡單、高效、靈活的運營平臺。

六、軟件架構(gòu)優(yōu)化

這是一個技術(shù)話題，大家可以關(guān)注當前比較火熱的大前端，各家公司都在想辦法如果通過軟件架構(gòu)優(yōu)化提升迭代效率。這里可以大致列舉一下業(yè)界的各種技術(shù)：

1. 小程序（微信、支付寶）
2. 快應(yīng)用（各大手機廠商）
3. ReactNative（Facebook）
4. Flutter（Google）
5. 組件化（微信）
6. 插件化（攜程）
7. Weex（淘寶）
8. ……

另外補充一下，上面談及的技術(shù)均是客戶端技術(shù)，針對服務(wù)器的快速發(fā)布和部署，業(yè)界技術(shù)也是層出不窮，例如：微服務(wù)、各種運維技術(shù)等。

當然，軟件架構(gòu)優(yōu)化也不一定要通過上新的框架這么大的動作來改善。這里重點想表達軟件架構(gòu)優(yōu)化對敏捷轉(zhuǎn)型也至關(guān)重要。例如僅僅做簡單的代碼重構(gòu)，降低業(yè)務(wù)耦合度也是有意義的。

本文由@墨一 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議