效能平臺建設實踐

點擊關注“ 有贊coder ”

獲取更多技術乾貨哦～

作者：辰路

團隊：效能改進

互聯網時代，大多數公司在進行內部項目管理時，都會採用各類 PMIS（項目管理信息系統）或者團隊協作軟件來支撐和輔助項目管理活動。

工欲善其事，必先利其器。優秀的項目管理系統與協同軟件對於個人，是 PM（項目經理）進行項目管理活動時披荊斬棘的“利器”，是他們創造管理價值的生產力工具；對於企業，一方面是重要的“基礎設施”，企業內部人、事、物等各大要素在這些“基礎設施”內數字化流動協同，持續有秩序地產生價值；另一方面它們也是堅實的“躍遷平臺”，系統和軟件內通過功能傳遞的先進理念與管理方法論，也將在潛移默化間厚積組織能力，在業務迅猛發展之機提供持續的承載與託力。

在這個領域，市面上較知名的，同時也是商業化非常成功的軟件有：微軟的Sharepoint、Project，Atlassian的JIRA、Confluence 等等，中國近年也有Tower、Teambition等後起之秀表現亮眼。而相比採購這些已經比較成熟的軟件服務，自主研發雖然有可拓展的“自主權”，也面臨着建設耗時更長、成本更高等挑戰。

有贊2017年接受了這個挑戰，開始正式自主研發“效能平臺”，本文將爲你介紹該系統至今兩年多的建設實踐，以期這些經驗與理念爲您帶來一些啓發。

一、效能平臺系統演進

1.1 系統早期

效能平臺最早是爲了解決整個公司在日常協作時橫跨多個系統，操作成本極高的問題。當時有讚的項目管理整體還是基於JIRA平臺，輔以自研的QA平臺與PMO 內部工具（基於JIRA API）。對於有贊來講，當時的項目管理遇到了一系列的挑戰：

缺乏符合公司實際應用場景的功能支撐，工具並不好用。
立項仍在線下“自助”完成，數據沉澱不完整，沉澱僅在研發側。
多樣化的研發類型，過程管理難以統一。

效能平臺前幾個版本主要解決的就是這些問題，經過緊鑼密鼓的策劃和研發，效能平臺最初幾個版本相繼上線，主要實現了以下目標：

統一了數據模型，包括項目、任務、成員、里程碑等。
項目從立項到上線的過程管理、任務跟蹤等。
基於“故障統計”、“團隊參與項目情況”、“未來生產力評估”三個方向，構建了系統的基礎平臺。

1.2 功能補足期

在最初幾個版本的系統框架搭建完成，並確定效能平臺“承擔着公司信息同步、協作，最終提高公司運作效率”的長期目標之後，我們深知當前版本的系統還不足以支撐公司全方位的協作，當前最重要的任務是根據實際需要補足各類“基礎設施建設”。添磚加瓦的基建就這麼開始了：

（1）需求生命週期與工作流的功能搭建：我們搭建了適宜有贊需要的需求管理模型和工作流，產品經理在效能平臺上創建需求並進行需求管理，需求歷經預排期計劃、立項與需求評審流轉至研發側，同時我們在項目之外，搭建了“小快靈”的“日常需求”這一需求類型，研發側5人日及以下的小型任務走日常需求快速上線。

（2）敏捷實踐的工具支撐：我們研發了迭代研發模型（Scrum 模型），爲公司內部某些適宜場景下的敏捷實踐提供了工具與功能上的支撐。

（3）效能數據的沉澱與展示：在有讚的項目管理推進中，我們沉澱了大量的過程數據，這些數據經過處理與整合，在專門的數據模塊呈現可視化的圖表或報表，作爲各業務線客觀的效能度量儀表盤。

（4）標準化的過程管理工具 ：在各大業務線的項目管理實踐中，我們總結歸納了很多過程管理的經驗，將這些經驗數字化、產品化後，我們標準化了很多過程管理的工具，例如：月度規劃、智能排期工具等。

（5）公司內部系統打通對接 ：完善效能平臺本身基礎能力的同時，我們對接了公司現有的其他自研系統： CI系統、測試系統、運維繫統等，實現了公司內“一站式”的產品研發側管理。

另外，我們還打通了企業微信，用戶可以通過“快速拉羣”一鍵拉羣，高效溝通，讓效能平臺內的信息通過“推送”“羣應用”“機器人”等像水一樣自然滲入頻繁日常工作交流的縫隙中。

1.3 創新拓展期

功能基本補齊之後，公司已經基本可以依託“效能平臺”這一“基礎設施”進行有序的運轉。有了“小米加步槍”，我們深知，仍然需要通過更多的功能創新與實踐拓展來實現更大的價值——我們還需要飛機、坦克甚至核武器。

在此介紹我們在近段時間的幾項“研究”：

1.3.1 商家需求處理與SLA

有贊是一家to B的公司，商家是我們的直接使用者和客戶，有贊極其重視商家的體驗和真實訴求，要求產品與研發側及時受理並響應來自商家的需求，並要求商家需求在整體產品需求裏佔據一定的比例。

我們在效能平臺內部針對“商家需求處理”設計了一整套從提出到上線的全流程的處理機制與SLA，並針對各階段的流轉沉澱整合數據輸出關於“商家需求”的度量報表，助力過程改進。（更多落地細節在《客戶反饋需求管理實踐》一文中有詳細闡述。）

1.3.2 需求分級

每家企業都希望公司的資源持續投入到“有價值”的事情上，持續做有價值的事，首先要在要做的“一大堆事”中，識別真正重要緊急的工作並確保資源投入獲得預期產出。爲了解決這個問題，我們在19年下半年根據有贊項目管理特點設計出一套“需求分級”流程，通過識別出每月高優需求並鎖定資源確保需求的開發與上線。（更多細節在《大規模產品代辦列表處理策略—需求分級》一文中有詳細闡述）

1.3.3 價值閉環

需求分級仍不能保證我們所做的工作都是百分之百有價值的，因爲需求呈現價值是在上線後，如果我們只關注到需求上線，卻不跟蹤上線後的結果，就好比一個廚師把菜炒完端上飯桌就把廚房門一關，不管顧客的感受了，這樣的飯店開不長久。

我們設計的“價值閉環”在效能平臺內第一次引入了需求“後流程”——即需求上線後怎麼樣。這在流程上要求我們的產品經理（廚師），在需求（菜品）上線30天內都要對需求進行至少一次的價值回顧並形成結論與沉澱，而這些結論將在下一次的業務規劃會中，作爲重要輔助資料來幫助提高決策的“正確性”。（更多細節在《端到端需求全生命週期管理》一文中有詳細闡述。）

二、效能平臺的定位——三大“自我修養”

長期以來，爲了達成未來效能平臺既是“基礎設施”又是“躍遷平臺”的目標，我們對效能平臺總結了三大“自我修養”，也就是定位的三大關鍵詞：

2.1 效能

效能的定義爲 “效能=效率+效果” 。這種定位旨在提示設計者和參與者，我們不僅僅關心效率高低，也關心效果如何。

彼得德魯克在《卓有成效的管理者》中開篇就提到“效率”與“效能”的不同，效率是“把事情做對”（to do things right）的能力，效能是做對的事情（to get the right things done）的能力。誠然，現代企業，尤其是互聯網公司，已經不能再倚重於勞動密集型或者資源密集型的管理與度量方式了。

有贊採用OKR的方式進行組織管理，我們將O（目標）分解爲KR（關鍵成果），繼而再拆分爲一系列的AC（動作）去達成這些成果，多快好省地執行AC就是“效率”；而這些AC能否順利促成KR、KR能否促成O則是“效果”。所以效能（效率+效果）是促成組織OKR實現的度量標準和正確視角，而能否實現OKR也是促使大家去關注效能的內在動力，兩者可謂相輔相成。

2.2 協同

“協同”是在人類社會產生之後就在不斷探索與演進的理念。而在公司這個營利性組織內部，“協同”也是在商場立足的基本功和核心戰鬥力。如果一個組織不能夠發揮個體與個體間合作的優勢，它無法在競爭激烈的市場環境中立足；而組織如果不能更好地發展“協同”能力，無法創造更大的協作價值，也將在日復一日間的內部損耗中逐漸喪失競爭力。

在效能平臺的實踐中，我們認爲協同的核心是“打破壁壘”：

打破人與人的壁壘：

人與人的壁壘指的是因爲物理距離和工作場景造成的內耗和效率低下。當然系統沒有辦法解決物理距離的問題，我們主要解決的是工作場景的問題。

效能平臺可以基於工作場景，設計出足夠合適的工作方式或者流程，幫助人與人在規則中自組織的高速協作與對接。

打破人與信息的壁壘：

人在工作中如果總是無法觸及到足夠的信息，會導致決策的方向錯誤與執行效率的低下，不免南轅北轍。

效能平臺是人與信息的橋樑，擊穿人與信息壁壘的同時，收集、篩選並分發有效信息，打破因不透明帶來的效率損失與浪費。

打破信息與信息之間的壁壘：

信息與信息的壁壘，其實是信息與系統的融合，沒有人希望自己做一件事會用到10個系統或者20個口徑不一的數據，統一的門戶入口和信息口徑，用標準確保理解一致，將有效降低溝通成本與學習成本。

2.3 閉環

“閉環”作爲一個控制學中的概念，在互聯網時代被頻繁的引用到各類流程設計、商業模式分析與公司治理當中。其實不光是互聯網世界，“閉環”其實代表的是一種世界觀和方法論，是一種通過循環不斷改進的泛用性理念。而肩負着有贊效能改進的工具性使命的效能平臺，必須“閉環”。

除了我們的所有功能必須在工具性質上完成“閉環”，同時我們也要求每一個PM在基於效能平臺的項目管理實踐中不斷通過理念的宣導和過程管理，保證組織以及內部的每一個個體的前進方式是環狀“滾動”的而不是“推動”或者“拖動”的。

結語—— 長風破浪會有時

在兩年多的實踐當中，效能平臺從初建，到逐步發展爲符合有贊需要的協作平臺，如今已成爲日常工作和項目管理繞不開的重要系統。過去的工作雖然不盡完美，但我們深知責任重大，我們將繼續打磨產品，希望不久的將來，可以與你繼續分享我們最新的理解。

拓展閱讀

Vol.262

如果讀者對效能改進也有興趣，歡迎加入有贊效能改進團隊，請將簡歷投遞至：[email protected]，我們共同探討和實踐。

效能平臺建設實踐