7D性能项目日记3：性能项目的进度如何管控？

@[toc]

一、前言

今天来唠唠性能项目的进度管控。

在性能领域中，一直存在着两种不同的声音。

• 一种就是只测不调，给个结果；
• 二是不仅测而且调优，要达到容量规划的目标。

这两种做法直接影响了管控的方式。

二、性能项目要不要分析调优取决于目标

性能项目按第一种做不是不可以，如果是在仅需要验证系统容量有版本迭代中有没有下降，或者做个基线摸底的话，这是完全可以的。

按第二种做，是基于项目的目标来的，如果一个系统生产上已经出现了因为峰值而产生的性能风险，再加上业务量还会有增加。那显然为了评估系统在未来的业务场景中仍然有能力支撑，就需要分析优化了。

这两种类型的项目，在做法上有很大的区别。根据我对性能的理解，整理的性能方法论整体结构如下：

如果是只测不调的做法，这里面的分析阶段、环比阶段就可以放弃掉；如果是在版本迭代之中做的性能验证，其实前面的方案阶段和准备阶段也是可以不要的，因为前面的工作已经是做过了的，直接做执行就可以了。

对于一个性能验证的工作来说，这个执行场景的周期一般都不会太长，一两周足够。

这样验证型的项目一般也不需要复杂的管控，跟着企业的上线工艺走就行了。当然这样的项目体现是性能验证的价值，每个人都像是流水线上的一个工人，你需要的只是扳一下螺丝。很多企业的内部性能团队和外包公司的性能团队都是这样做的。同时，这样的项目也是最废人的，当你在这样的环境中工作了多年之后，再出去找工作的时候就会知道有多废人，那可是大好的青春呀。

但是！切忌在性能验证的项目中，还妄图加上分析调优的工作，根据我的经验，想在这个过程中加分析调优的企业，基本上都会把这个周期干的特别紧张。其实如果只是时间紧张而有好的结果，倒也无所谓，就是人累一点。实际情况是，有些项目中，人累也累了，分析调优的工作却没有好的结果，最终导致人累又感觉项目没做好。

在完整的又测又调的性能项目中，根据上面的图可以看到，我大概是分为了几个阶段，要做的事情也大概列在那里了。做过性能项目的人，大概都知道这些东西。
但是！区别就是细节上有没有做到。

下面我们说一下细节。

三、性能计划

做性能项目管理的人一定要学会做性能计划。在我见过的项目中，有很多人觉得计划就是一纸空谈，走个过场的东西，只要列几个里程碑的时间点就可以了。
在这个项目的初期，我刚介入的时候，计划就是这个样子。

更细的就没有了。其实如果在一个企业内部做事情，没有涉及到多方企业的配合，再加上项目延期并不影响自己这个月的薪水，做出这样的计划来，我倒是不奇怪。
但是做为一个有合同、有金额限制、有利润限制、有周期限制的性能项目来说，这样的计划就等于放任不管，是完全不负责任的计划。

首先，性能计划应该包括的是：多少人要用多长时间用什么资源做多少事情，有什么依赖的前提条件，需要什么外围的配合，最终产出什么样的结果。另外，如果配合的不好，会导致延期风险的话，具体会延期多久，都要在计划中体现出来。也就是项目经理需要知道一个项目中有多少事情才可以，要不然就会在后续的工作中不停地被事情推着往前走，到处救火，做不到未雨绸缪。

其次，性能计划应该是广而告之给项目中所有相关的人。上到决策层的领导，下到干活的一个性能测试工程师，以及每一个接口人。

然后，在项目执行的过程中，如果任务提前了，那是好事；如果延期了，一定要把风险暴露出来给所有人。

我做项目的习惯是一周至少做一次项目沟通，告诉所有人，我们的进度如何，有什么风险，需要什么配合。

而在这个项目中，我一看到这个计划，脑袋都大了。这是一个8个系统+全链路的性能项目，客户给的周期是2个月。分析人员还没影。还有10年前的系统，技术架构、中间件、数据库等都比较老旧。

一听上去就是风险很大的项目，居然就弄了这么个计划。让我更担心的是，居然没有人提出异议。

在启动会的前两天我看到这个计划，然后我就拉甲乙双方的项目经理到会议室里说，这个计划不行，得改。如果启动会只是走个形式，什么内容并不重要，也许没人提出异议，但是如果启动会上有人认真看，这必定是一个启动失败的会。

然后我就把之前做的一个性能项目计划模板拿出来给他们了，让他们按这个逻辑去改。

在这个模板中，我已经设置过任务的前后依赖。如下所示：

在这个计划中，可以看到每个人在什么时候要完成什么事情，需要什么前提条件。如果出现风险，那就会看得到。

有很多干活的人，觉得计划是对自己的管束，于是都不怎么关心计划做成什么样子，反正你让我干什么，我就干什么就行了。而性能项目经理，有些觉得自己也不是能做主的人，反正还有甲方的项目经理管着，所以也不愿意在计划上花时间。所以通常都是弄一个草稿的计划去应付一下了事。

在我的性能项目中，我对计划的期望是可以管控一个项目中的任何一方。性能项目是一个多方配合的事情，当瓶颈多的时候，靠什么来管理第三方、第四方呢？去催人吗？有些人还不配合，难道去求着别人做事情吗？做性能项目需要这么低贱卑微吗？当然用不着。

既然是项目，既然是需要合作，大家都做好自己的专业工作，按照职业的方式来做就好了。所以我每个项目做了计划之后，就会把计划发给所有人，细到每个人要完成什么事情。当你知道了自己要做的事情之后，我们到点收货即可，如果前提条件没满足，又没有提前预警，那就是项目经理的失职。

如果第三方不配合，倒也不用着急上火，只要升级问题就好了，不管是上层领导去协调、还是商务层面去惩罚，那都是手段。并不是你想不配合就可以不配合的、想发脾气就可以发脾气的、想挂电话就挂电话的。

其实性能项目计划不是管人的，而是管事的。

对于项目中的人来说，认真工作的人，不会担心计划的管控力，因为那些事情本来也是要做。不认真工作的人，才会对计划有反感。

另外在性能项目的计划也不是定了之后就不能改的，领导层需要看到的是项目的风险在哪里，而不是死守着计划的时间点。即便是有政治任务，最后的时间点不能改变，那项目中确确实实做不到了，领导也照样会理解，并协调支持。

所以定义好计划的每个阶段的输入输出、每个人在项目中的职责就很关键。

有了计划才能体现项目中每个人的价值。

四、项目成本

做为一个性能项目经理，一定要能算出项目的每个周期中要用多少成本。

首先是人员成本。像我们这个项目平均8个人在现场，每个人都有价格，一天是多少钱，基本上是明确可以算出来的。因为我不是最先介入这个项目的，人员成本、合同金额我也不清楚。大概估算了一个，两个月，8个现场的人，再加上各类活动（像招投标成本、现场远程会议讨论等）、商务成本、差旅成本等等，怎么着也有个60-70万吧，如果是近百万的项目，如果还想有个10%的企业利润，那显然项目拖一周的话，利润就会少一点，如果拖半个月、一个月的，我估计利润也就没了。

其次是沟通成本。沟通过程当然是靠项目计划去管控，但是有些沟通成本是计划中体现不出来的。比如说概念的统一，在性能项目中，有人喜欢用QPS、RPS来做指标，有人喜欢用TPS、HPS做指标，有人喜欢用在线用户、并发用户做指标，那我们就需要在项目之初告诉所有人，最后我们是用什么指标来标识项目是不是可以达标。

再比如说之前企业中使用的是我一直批判的“性能测试”、“负载测试”、“压力测试”等做为场景名，而现在要改到”基准场景“、”容量场景“、稳定性场景等”。那就需要说明为什么要做这样的改变，并且说明这样做的好处。

根据之前我在极客时间的专栏中写到的场景对应替代的梳理。就是这样：

这个异常场景，我也强调过，如果仅对性能项目来说，可以不做，再加上在非功能场景中也会覆盖这部分，所以根据需要做即可。

注：非功能方面是另一个宏大的话题，最近两年的时间里，我都在做这方面的方法论研究和落地实施，现在已经形成了比RESAR性能方法论还要大的完整的从理论到实施的体系。有兴趣的可以找我探讨。

场景分类的名字，我也不是死板的必须坚持，像有些企业中把异常场景叫高可用场景、健壮性场景、可靠性场景等，我也会随着客户内部的定义而入乡随俗。

而场景如何执行，需要在方案中做明确的说明。再加上一些性能测试人员由于按之前的工作逻辑已经被固化，还需要在项目中纠正过来。仅这个沟通成本就够扯两个小时的。

上面只是举了两个在项目中沟通成本的例子，当然还有很多其他方面的沟通成本，比如：场景递增速度、参数量级、优化方案讨论等等等等。

在性能项目的管理中，还有更多的细节，有机会我们一一拆解。