前言
指标，是认识世界的一种方式，而且是快速认识世界的一种有效方式。指标与项目息息相关，在项目中通常有各种指标，来描述对应的对象。在项目推进过程中，指标的定量数据描述，比定性的描述，更加具有说服力。管理学大师彼得德鲁克曾说过：无数据不管理。这也是对指标，在项目管理和推进中重要作用的体现。
指标的根本目标，是为了推进项目管理。没有指标，就没有对项目过程的可见度，那么项目管理就无从谈起。对可见的事项，可以设置有适当的指标。从而依据这些指标进行判断，评估和决策，这为项目推进打下良好的基础。
指标的设计，是对项目中的具体事项进行数据定义、数据收集、持续分析、以及过程监控的过程。同时由于项目的复杂性，项目跨度时间的长期性，单一的指标，远不能满足对项目的管理要求。这就需要，对多个指标进行统筹，整合为一个整体的指标体系，才能更好的为项目管理服务。一个好的指标体系，对于项目而言可以是一把统一沟通语言的尺子，是一个统一方向的司南，也可以是一个持续发现问题、预警风险的机制。
设计理论
搭建指标体系，有不同的方法和模型，主要有 OSM 模型，AARRR 模型（用户增长模型），MECE模型（独立穷尽模型）等。OSM 模型是 Object（目标）, Strategy（策略）, Measure（度量）的缩写。由于 OSM 模型具有目标清晰、可落地性强等特点，作为经典模型而广泛使用。OSM 模型的主导思想，是将宏大的目标进行逐步的拆解，直到具体的、详细的、可落地的、可度量的指标。整个拆解过程，因为没有偏离方向，从而保证执行计划也没有偏离目标。本文，也是借助于 OSM 模型，对政企采购云平台项目进行指标体系的设计。
指标体系，服务于业务才能赋能业务。如果指标脱离实际的业务，那么数据就会失去其价值。所以，在设计指标体系之前，一定要清晰的了解业务目标，也就是模型中的 O（Object，目标）。业务的核心目标，是设计指标体系的方向。
基于业务目标方向，下一步就可以制定相应的行动策略，也就是模型中的 S（Strategy，策略）。行动策略的制定，可以根据产品生命周期，或者分区域进行拆解。也就是把业务的核心目标，拆解到产品生命周期，或者分区域指标中，从而在整条链路当中可以分析提升的点。
接下来是制定较细的具体指标，也就是模型中的 M（Measure，度量）。具体指标的制定，是将产品链路，或者分区域中的各个指标进行细分，和下钻。每个度量的指标，需要明确指标的六要素。比如，看到一只狗，用手比划：“那个狗好大呀”。这样的度量，很难让人理解到底有多大，也不能获取准确的度量信息。如果通过指标度量说明：“这只狗是大型犬，身高 87 厘米，体长 1 米 29 厘米”。这样大家能比较快速理解这只狗的大小。但是，这里指标的定义还是有异议，这样还是不清晰，还是有多种理解。比如狗“身高”的定义，包括不包括耳朵？这里就涉及到指标度量口径的问题。所以一个指标，除了指标名称和指标数据外，还需要带上更多的信息。即是指标有六要素，明确这六要素之后，一个指标就能完整、准确的描述对应对象了。指标的六要素，具体是指：
1、指标名称：对指标进行描述的唯一名称；
2、度量方法：定性，或定量统计的逻辑、口径；
3、度量单位：指标使用的单位；
4、度量数值：指标具体的数值；
5、时间范围：度量的时间段，时间点、统计频次等时间性属性；
6、空间范围：度量的区域性属性。
指标体系的设计
在项目演进的不同阶段，所关注的侧重点，是随着进展而变化的。按照项目所处阶段的变化，可以针对性的选取合适度量方法，适时调整，周期性的产出项目整体指标情况。每次指标体系的产出，都可以形成有效的改进项。对其改进之后，可以观察到对应的效果。持续的对指标体系进行改进，将对项目产生积极影响。其整体的节奏，可以是这样的。
业务目标的确定，直接影响指标体系的设计和最终效果。持续改进，适时调整，就是盯住最终目标，不断调整指标内容，度量方式等，最终实现业务目标的达成。在指标体系设计理论的指导下，结合业务的实际情况，可以形成对项目设计的指标体系。
本文以政企采购云平台项目为例，对其进行指标系统的设计。首先需要明确的目标是，设计一个指标体系，而不是单个指标。单个指标，能够获取的信息是零散的，有限的，孤立的。在单个指标基础上，需要将指标之间的关系链接起来。从多方面进行度量，形成全局、系统性的指标体系。这样，指标体系能有效的感知到全局，从而对业务目标能发挥积极作用。
在本案例中，指标体系设计的目标是：全面掌握政企采购云平台的技术情况，业务情况，从而更好的支撑云平台功能迭代，并保障其稳定。针对预期的目标，依据政企采购云平台的实际情况，对指标系统进行拆解。先拆解为区域，再对每个区域拆分为若干的具体指标。拆解，不仅仅能实现业务目标，也大大降低了具体落地目标的难度，从而提高了目标落地的可能性。拆解之后的分域为：业务数据域，产品需求域，研发过程质量域，服务与资源域，大数据监控域，安全指标域。
业务数据域：从政企采购云平台业务达成的角度，关注于交易GMV，用户数等业务相关的指标。
产品需求域：从云平台整体产品层面，关注产品需求总数，需求发布数等产品迭代相关的指标。
研发过程质量域：关注研发过程健康情况，交付质量等过程，质量相关的指标。
服务与资源域：关注计算云资源使用率，告警数，云服务质量等相关的指标。
大数据监控域：关注数据存储量，数据提取，数据监控等相关的指标。
安全指标域：关注主机防护覆盖数，应急漏洞响应情况等相关的指标。
基于OSM模型上，至此已经完成了O，S这两步骤，接下来就是完成M具体指标的设计，也就是每个指标的六要素的落地。在每个分区域，依据实际情况，按照每个区域各自的特点，制定本区域的指标。在设计具体的某一个指标的时候，需要考虑每个指标的实际意义，指标的可度量性等。指标具有实际意义，是这个指标被设计出来的前提条件。否则，就没有存在的必要性。可度量性，包括定性度量和定量度量，是指标存在的基础。如果这个指标具有实际意义，而且有落地性，接下来可以设计指标的六要素。每个指标设计完毕之后，可以盘点指标之间的关联关系，形成指标的网状链路，进而整合为指标体系。借助于指标体系，从而能够从全局，整体的洞察到业务目标。
以研发过程质量域为例，设计此分域的指标是这样的。
接下来，需要依据实际情况，完善每一个指标的六要素。项目的质量是开发出来的，无论是开发阶段，测试阶段都会对最终项目交付的质量造成影响。项目在开发阶段，提测质量是门禁的卡尺，是项目流水线中的质量活动顺畅进行的必要保障。质量门禁的设置，可以用相对低成本的方式，避免不必要的过渡资源消耗。因此指标设计，需要着重关注这一块。在开发阶段，设置了代码量，注释代码量，单元测试覆盖率，代码review提出意见数，代码review被提出意见数等指标。在测试执行阶段，从测试角色的价值视角切入，需要提炼测试活动投入而产生的价值。从缺陷的严重程度，自动化的产出价值着手，形成对需求开发正向的闭环指导。缺陷的严重程度，直接反馈项目开发的质量，也能体现测试用例覆盖的全面性。自动化的产出价值，是以抓住核心，维护稳定的关键。定期对自动化用例进行复盘，增补有效的测试用例，剔除无效的测试用例，减少不必要的维护成本。
然后将单个指标，整合为分区域的指标。每个分区域，也可以按照这个理念，针对性的设计区域的指标体系。然后将每个分区域的指标体系，进行整合之后，连接成线，线连成网，就可以得到整体的指标体系。接下来，持续观察指标体系的运行效果，适时对其进行调整。进而运营好此指标体系，为项目起到积极的作用。
指标体系的思考
怎么使用指标体系，特别是如何使用好指标体系，是值得思考的一个问题。指标体系，对于项目推进和管理，是一种强有力的工具。借助于指标体系，能够有效洞察项目的进展，项目中数据的异常点，项目的成果数据等。一个优秀的指标体系，能够帮助我们实现：描述现状、洞察原因、预判未来。
但是，指标体系也是一把双刃剑。如果使用不当，将会造成负面效果。在实际中，需要避免为了数据而度量，以数据为唯一依据等情况的出现。
对于指标体系的使用，有这几方面的思考：
对于指标体系，需要关注趋势变化，避免着重关注于某一个具体数值上。在产品需求域中，常见的指标是需求发布数量。这个指标属于定量分析。对于某个程序员，如果每个月都要求其必须完成x条需求发布，而且仅仅关注这一个指标而已。在这种情况下，以这个数据为唯一标准，不仅仅是对指标的乱用，也是管理措施的缺失。首先，仅关注发布需求的数量，是片面的，因为需求与需求之间的可比性往往是较差的。由于需求的颗粒度和复杂度不同，不能说一个大需求等于若干个普通需求。因此需求数量的绝对值累计，容易引起争议。相比于数量绝对值，我们更应该关注的是数量或分布的变化趋势。比如：在某一时间段内需求发布数量激增，则需要分析出需求发布数量的原因，以避免潜在的风险。其次，基于这个指标，可以分析在不同维度（比如按照子产品线，子开发团队，子应用模块等）的需求发布数量趋势，形成对应的趋势分析报告。从而可以对团队提出有意义的改进项，并且跟进执行效果。第三，针对趋势变化，识别出问题，可以进行根因分析。从而找到某个改善趋势的有效解决方法，使指标真正的对项目产生积极的影响。
指标体系是手段，是辅助诊断的工具，需要分析指标背后的深层次原因。指标，可以帮助找出项目中的异常情况，异常数据。但引发这个异常情况，异常数据背后具体的原因，需要使用者依据实际情况，进行深层次的剖析和解读。这个数据，也许凸显了急需解决的问题；也许反应了需要一个长期的顽疾；也许反馈了实际相符的正常情况；也许展示了最新的成绩。这些，都需要结合实际情况，指标背后的深层次原因。如果仅仅以指标数据，作为判断事项的唯一依据，那就是有失偏颇。不仅仅没有人文关怀，也会对项目本身造成伤害。指标体系，如果是一把剑的话，它应该是砍向项目中的问题，而不是项目本身。
指标系统上线，并不等于其设计工作已经完成，而是需要不断完善和迭代。特别是处在不同的生命周期中，持续时间较长的项目。在不同阶段，对项目所关注的重点，将会有所改变。随着关注重点的变化，需要不同的指标去跟踪。比如某信息系统在0-1开发的阶段，需要重点关注其需求域的指标。同样是这个信息系统，如果在维护阶段的时候，线上稳定性的重要更加凸显，此时需要重点关注研发过程质量域的指标。因此，指标体系，需要随着项目的生命周期，不断进行调整、迭代和丰富，从而对项目整个过程做到降本增效，事半功倍的效果。
总结
优秀的指标体系，借助于设计理论，贴合业务目标，助力于项目业务的达成。在指标体系的设计中，通过将孤立的，单个的指标串联起来，成线，成网，让通过单点看到全局，站在全局高度来解决单点的问题。同时在项目全生命周期里面，让项目组成员都参与到指标体系的设计中。大家协力思考，分析指标的业务价值，并在实践中，持续反馈指标的设计效果，从而让指标体系在不断的完善，不断发挥出指标体系的应用价值。
推荐阅读
招贤纳士
政采云技术团队（Zero），一个富有激情、创造力和执行力的团队，Base 在风景如画的杭州。团队现有 500 多名研发小伙伴，既有来自阿里、华为、网易的“老”兵，也有来自浙大、中科大、杭电等校的新人。团队在日常业务开发之外，还分别在云原生、区块链、人工智能、低代码平台、中间件、大数据、物料体系、工程平台、性能体验、可视化等领域进行技术探索和实践，推动并落地了一系列的内部技术产品，持续探索技术的新边界。此外，团队还纷纷投身社区建设，目前已经是 google flutter、scikit-learn、Apache Dubbo、Apache Rocketmq、Apache Pulsar、CNCF Dapr、Apache DolphinScheduler、alibaba Seata 等众多优秀开源社区的贡献者。如果你想改变一直被事折腾，希望开始折腾事；如果你想改变一直被告诫需要多些想法，却无从破局；如果你想改变你有能力去做成那个结果，却不需要你；如果你想改变你想做成的事需要一个团队去支撑，但没你带人的位置；如果你想改变本来悟性不错，但总是有那一层窗户纸的模糊……如果你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的自己。如果你希望参与到随着业务腾飞的过程，亲手推动一个有着深入的业务理解、完善的技术体系、技术创造价值、影响力外溢的技术团队的成长过程，我觉得我们该聊聊。任何时间，等着你写点什么，发给 [email protected]
微信公众号
文章同步发布，政采云技术团队公众号，欢迎关注