CODING 敏捷實戰系列加餐課：CODING 作敏捷這一年 - 理解一站式 DevOps 產品思想

在數字化協同的大背景下，過去一年 CODING 以老牌代碼託管工具爲基礎，華麗轉型爲一站式 DevOps 研發管理工具。本次課程《CODING 作敏捷這一年：理解一站式 DevOps 產品思想》由 CODING 運營及項目協同產品總監張路宇進行分享，主要分析數字化協同的工具對於敏捷的做用，並現場互動討論觀衆喜歡的工具、團隊如何實踐敏捷，作工具產品的挑戰等等問題。

Part 1. 數字化協同在敏捷導入中的價值

你們可能會問這樣一類問題：
工具在敏捷導入中扮演了什麼角色？
電子看板是否更具優點？
CODING 和 TAPD/JIRA 等等有什麼區別？
......

這一切都反映了無論是選工具、選方法仍是選理論，企業的根本關切在於他們可否提高效率。回顧傳統的管理學研究，美國管理學家泰勒的經典著做《科學管理原理》被德魯克譽爲「20 世紀最偉大的發明」。這本書闡述了 20 世紀這段時間工業革命以及管理學、組織學上進步的根本緣由在於分工，由於分工產生了流水線，由於流水線纔有了工業化，由於工業化纔有了以機器取代人力的工業革命。把福特推上機器時代奠定人地位，並創造了「福特之工業奇蹟」的，就是泰勒科學管理原理在工業化流水線上的成功運用。

亞當·斯密的《國富論》時間出現的更早，這本書裏舉了一個例子，亞當·斯密發現工廠製造大頭針須要完成不少的工序，抽鐵絲、拉直、切截、削尖鐵絲的一端、打磨鐵絲的另外一端（以方便裝針頭）等等。經過分工，十八道工序能夠分別由十八個專門的工人負責完成，實現效率上的提高。本來一我的須要完成十幾個步驟，培訓成本、上手成本以及切換工做的成本都很是高，經過工具的分解，這十八個工人就能實現效率上的根本提高。這種現象在國內的傳統制造業中也能看到，都是基於提升單體勞動者的勞動效率來提高工做效率。這種管理理念被稱爲管理 1.0，也就是對管理有一個基礎的認知。然而現在來看標普 500，也就是全球 500 強公司的成分股變化，在管理上有了顛覆性的改變。下圖展現了從 1988 年到 2000 年，再到 2008 年排名前十的公司數據。

1988 年居於前列的有 IBM、通用電氣、福特這樣的企業，他們的競爭優點在於有必定的技術優點或者資本優點。例如石油行業有資本優點，或者相似 IBM、福特這種公司經過大規模的生產和標準化實現公司市值的大幅提高。到了 2018 年，格局有了很大的改變，排在前列的公司如蘋果、谷歌、亞馬遜、微軟，都被稱做爲技術驅動的平臺型企業，或者說價值網絡構建者的企業。好比蘋果有 iOS 生態，騰訊有微信生態，這些企業都是生態的構建者。在這短短的幾十年裏，前十名的公司從傳統的規模化資本驅動、流水線驅動的企業逐漸轉換爲數字化平臺構建的價值網絡驅動企業，企業市值也翻了十幾倍。

經過以上這些現象，能夠發現今天企業面對的挑戰和二三十年前企業所面對的挑戰大相徑庭，核心競爭力的構建主要來自於企業強調創新，以及業務自己有價值網絡性質這種指數的上升。組織面臨的內部管理挑戰也會隨着時代的變化而改變：

• 強個體的價值崛起

在傳統的分工模式下，強調的是 100 個員工把一件事分紅了 100 個 1%，所以你們的上限實際上是有限的。然而能爲公司創造最大價值的人一般只佔據公司人數的 5% 或者 10%，這些人的個體價值能夠達到無限。這就是當今數字化企業核心競爭力的一個來源。

• 影響組織績效的因素由內部轉向外部

在當今時代，作一個產品去投入市場時，成敗的緣由每每在外部，好比資源整合是否良好、和外部生態的接入程度高不高。比方說一個電商企業，是否有和阿里巴巴等平臺實現最大化的合做，好比利用直播等多方渠道。然而過去對於製造業企業或者一個傳統的公司來講，影響績效的核心因素每每是內部阻塞過多，內部事項不夠順暢，內部管理不良。

• 駕馭不肯定性成爲組織的核心挑戰

不肯定性是全部組織面臨的一個核心挑戰，通過二十多年的時代變遷，今天的企業所面臨的挑戰幾乎發生了徹底性的改變。企業裏個體成員的價值是有限仍是無限，這筆賬是能夠計算清楚的。過去分工沒法應對的挑戰，在實際管理和員工執行中很是明顯：作的事情與戰略割裂，與資源脫鉤，與用戶脫節。這些其實也是敏捷須要解決的難題——敏捷不是用來增長單體效率，而是幫助團隊最快地發現須要解決的問題。小團隊或者敏捷的團隊在比較大型的公司裏，須要全面審視公司可以提供的各類資源以及頂層意識的傳達，咱們稱之爲敏捷和傳統模式的平衡。若是過分敏捷，就會出現以上種種問題；若是過分集權，可能不會犯與戰略割裂的錯誤，可是與用戶脫節的風險又提升了。這裏能夠引用德魯克的話：「動盪時代最大的危險不是動盪自己，而是仍然用過去的邏輯作事。」

分工的管理原理，傳統上你們認爲是一個很是科學的方式，可是今天無論是在製造業企業仍是傳統軟件公司其實都有這種能力，在中國已經不具有相對優點。這裏舉一個很是典型的例子：微信紅包。2013 年微信紅包誕生，今天微信支付和支付寶在移動支付領域都各佔一片江山。可是早在五年前，微信支付在移動支付這個市場徹底不具有優點，被支付寶碾壓式的統治。騰訊千方百計但願能把支付業務推出去，然而最後成功的是一羣年輕人。他們利用業餘時間在小團隊裏作了一個內部小項目，完成微信紅包小程序的設計，一晚上之間發生裂變，後來的事情你們都知道了。自組織誕生的微信紅包根本性地改變了移動支付戰局，這樣的成果須要對用戶情景很是敏感，很是有創意，很是有創新力，很是有勇氣的團隊成員去發掘出來，這是一個很是好的組織內自下而上的例子。今天在談論效率時，咱們關注的僅僅只是分工，但分工只是一個基礎，好比團隊中的成員可能分前端後端，在這個基礎上，更須要重視的是協同。效率來源於協同而並不是分工，引用索尼成立之初創始人的話：「要充分發揮技術人員的技能，創建一個自由、豁達、輕鬆愉快的理想工廠。「所以如今作一個工具，至少要實現三點才能知足團隊在軟件工程上的需求：

1.注重協同效應，1+1>2
2.超越流程，基於卓越工程實踐
3.一致性、沉浸式的融合體驗

團隊在使用工具實現協同時要實現 1+1>2 的價值，而且要超越流程。僅僅有項目管理的流程或者理念只能幫助團隊有一個好的開始，真正成功的項目依舊是基於卓越的工程實踐的。此外，團隊應該有一致沉浸式的融合體驗，而並不是是割裂的。若是員工在實際工做中，天天都要在不一樣的軟件之間切換甚至換帳號，那麼他的狀態會很是容易被打破。所以基於對產品理念的理解，咱們引進了一個四層模型：

信息能夠分爲四個流程：知識、需求、代碼、製品。這些信息能夠在一個系統的信息面上有必定程度的打通，在同一個團隊作到適度聚焦開放透明。好比有一個員工，可能在他專一工做的時候，代碼在日常的信息面裏能夠高效地找到，但若是要啓動發散性思惟、思考當前目標是否正確時，就應該可以在平臺中跨職能獲取其餘幾個層面的信息。那麼這就須要憑藉技術的力量穿透其內外部資源流動和分享，把硬性邊界變成柔性邊界。

Part 2: CODING 如何【敏捷地】作敏捷

以前分享了對於數字化協同的理解，接下來咱們來看看 CODING 是怎樣去作敏捷的。CODING 在 18 年時從自身的代碼託管服務轉型爲 DevOps 基礎設施——一站式研發管理平臺。在此以前，CODING 作了接近三到四年的代碼託管，當時的想法是作中國的 Github 或者作出 APP 這樣一個形式。服務開始轉型時，當時 CODING 有 100 多萬我的開發者用戶，但實際上對於企業嚴肅的管理需求和團隊協同需求是一無所知的。那麼這時咱們就在思考 CODING 的產品定位是什麼。

上圖有四個象限，展示了幾個不一樣的協同工具。好比比較傳統的 Jira，能夠理解爲一種單體的組件式協同工具，可是在國內團隊比較須要的中心化管理方面能力就不好，或者說它很是欠缺從代碼到製品，再到持續集成 TDD 這樣的一套流程，須要另外組合開源工具鏈才能知足基本須要。華爲的 DevCloud 做爲一個一站式產品，具有一個研發團隊的一切所需，同時又是高度集權中心化管理，所以是一個很是適合傳統企業自上而下去推動的平臺。然而實際上推到下面團隊時，對於工程師而言倒是一個壓迫感很強的監管工具，而不是協同工具，團隊文化容易受到破壞。CODING 並不想作 Github 這種很是輕量、管理需求基本能夠忽略的平臺，也不想作 DevCloud 這種集權管理的工具。CODING 給本身的定位是一站式研發管理工具，可以解決大部分問題，而且在中心化和自組織之間可以找到一塊重疊的區域。

CODING 在 18 年末時決定面向企業和團隊提供全面的管理服務，而且但願能從簡單的代碼託管服務擴展到包括持續集成、製品庫等功能的一站式服務。CODING 的優點在於有百萬開發者用戶基礎，而且有原生的 Git 倉庫技術和必定的數據分析能力，而挑戰是新的服務須要面向徹底不一樣的角色——企業和團隊領袖，不少開發者對於敏捷、DevOps 理念的瞭解比較匱乏。另外若是團隊須要進行管理變革，特別是牽涉到敏捷等領域，須要知足康威定律，也就是對組織結構和人員架構進行從新審視。最後還須要公司和團隊樹立變革目標而且找到領頭人，這些都是 CODING 做爲工具沒法觸達的。

四階段產品路線圖

CODING 的產品路線能夠分紅四個階段，第一個階段用時兩個月，對缺陷進行跟蹤；第二個階段用時不到一個月，對需求進行拆分；第三個階段開始引入迭代週期，經過 Backlog 池等模塊引入週期概念。目前 CODING 還未實現第四階段，也就是信息流融合，打通代碼流、製品流以及信息流。下圖爲 CODING 產品的整個開發流水線。

CODING 目前的產品水平和發展速度在業界已經能夠被確定。下圖能夠看到 CODING 和其餘競品功能的對比。許多不一樣的協做產品的本質區別一般在於利益相關人的區別。好比說 TAPD 首先服務的是騰訊內部的部門，可能就不會優先照顧外部團隊；Gitlab 和 Jira 等工具，他們自己的基因決定偏向工程化，對於團隊複雜目標、大型項目規劃管理以及中國團隊所需的本地化統計功能是沒法處理的。所以左右產品表現的一般是背後的理念或者說是利益相關人的差別。

Part 3. OKR 與敏捷的結合實踐

用戶須要瞭解到 OKR 實踐的誤區。一般用戶對於需求有兩種場景，一種是相似於績效的團隊目標管理，也就是一個季度或者一個月每一個人須要達到某些目標，這是一個典型 OKR；另一種場景是跨項目的項目管理，好比要作移動端商城這樣一個產品，這個產品有不一樣的版本週期，分佈在不一樣的項目組中，項目經理可能想對它們進行集中化的跟蹤。在權衡不一樣的需求以後，計劃上線的某一個版本就是團隊目標。OKR 三層結構包括目標、結果和執行，所以團隊 PM 或者有權限的人能夠建立一個團隊，在特定週期去完成一個有挑戰性的目標，而後爲這些目標設立一些關鍵結果。有些項目沒法用量化結果來權衡，CODING 的自動跟蹤模式的創新之處就在於關鍵結果和執行之間能夠作一層關聯，分佈在不一樣項目之間的任務能夠關聯在一塊兒，這些任務若是都完成了，會自動達成 OKR 量化的目的。

這種思路是由於 CODING 但願 OKR 推動過程應該既知足上層需求，又不干預團隊內部，尤爲是敏捷團隊很是須要擁有個性化的工做模式和任務分解力度。若是從 CEO 或者更高層面來公佈一些任務，就違背了 OKR 的初衷，會把團隊原來已經搭建好的敏捷工做流和工做節奏徹底打破。

另外 OKR 實踐有一些廣泛存在的認知誤區。首先，OKR 不是自上而下，而是自下而上的，主動權應該下發給團隊來發揮創造性。對於關鍵目標，團隊須要有很是深入的理解。團隊同時須要作到透明，也就是說全部人都應可以看到全部成員的 OKR 目標，而不是隻能看到本身的。最重要的一點是 OKR 應該有必定程度的挑戰和容錯，不少公司和團隊在實踐 OKR 過程當中，設定這個月必須達到 80 分、90 分，徹底違背了 OKR 的設計理念。OKR 是爲了給團隊提供一種動能，去設定一些挑戰的任務，有挑戰必然就有風險，即便失敗了，你們也應當持有包容和成長性的思惟，而不是爲了達成目標去設定一些輕鬆能完成的任務。以上就是本次分享的所有內容，謝謝！

點擊觀看完整錄播視頻