效能平台建设实践

互联网时代，大多数公司在进行内部项目管理时，都会采用各类 PMIS（项目管理信息系统）或者团队协作软件来支撑和辅助项目管理活动。

工欲善其事，必先利其器。优秀的项目管理系统与协同软件对于个人，是 PM（项目经理）进行项目管理活动时披荆斩棘的“利器”，是他们创造管理价值的生产力工具；对于企业，一方面是重要的“基础设施”，企业内部人、事、物等各大要素在这些“基础设施”内数字化流动协同，持续有秩序地产生价值；另一方面它们也是坚实的“跃迁平台”，系统和软件内通过功能传递的先进理念与管理方法论，也将在潜移默化间厚积组织能力，在业务迅猛发展之机提供持续的承载与托力。在这个领域，市面上较知名的，同时也是商业化非常成功的软件有：微软的 Sharepoint、Project，Atlassian 的 JIRA、Confluence 等等，中国近年也有 Tower、Teambition 等后起之秀表现亮眼。而相比采购这些已经比较成熟的软件服务，自主研发虽然有可拓展的“自主权”，也面临着建设耗时更长、成本更高等挑战。

有赞 2017 年接受了这个挑战，开始正式自主研发“效能平台”，本文将为你介绍该系统至今两年多的建设实践，以期这些经验与理念为您带来一些启发。

一、效能平台系统演进

1.1 系统早期

效能平台最早是为了解决整个公司在日常协作时横跨多个系统，操作成本极高的问题。当时有赞的项目管理整体还是基于 JIRA 平台，辅以自研的 QA 平台与 PMO 内部工具（基于 JIRA API）。对于有赞来讲，当时的项目管理遇到了一系列的挑战：

1. 缺乏符合公司实际应用场景的功能支撑，工具并不好用。

2. 立项仍在线下“自助”完成，数据沉淀不完整，沉淀仅在研发侧。

3. 多样化的研发类型，过程管理难以统一。

效能平台前几个版本主要解决的就是这些问题，经过紧锣密鼓的策划和研发，效能平台最初几个版本相继上线，主要实现了以下目标：

1. 统一了数据模型，包括项目、任务、成员、里程碑等。

2. 项目从立项到上线的过程管理、任务跟踪等。

3. 基于“故障统计”、“团队参与项目情况”、“未来生产力评估”三个方向，构建了系统的基础平台。

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 在基于效能平台的项目管理实践中不断通过理念的宣导和过程管理，保证组织以及内部的每一个个体的前进方式是环状“滚动”的而不是“推动”或者“拖动”的。

结语——长风破浪会有时

在两年多的实践当中，效能平台从初建，到逐步发展为符合有赞需要的协作平台，如今已成为日常工作和项目管理绕不开的重要系统。过去的工作虽然不尽完美，但我们深知责任重大，我们将继续打磨产品，希望不久的将来，可以与你继续分享我们最新的理解。