质量审计路径的起点

友情提醒：释放双手，戴上耳机，听听看~

Vol.054 质量审计路径的起点|主播：萌萌

管理小学问，每日微课堂。

这里是光环微课堂，每天七点半，一起聊聊项目管理的修行之道。

今天我想和你分享的内容是“质量审计路径的起点”。

如果你也喜欢今天的文章，欢迎拉到文末给我们点个在看。

在我们之前讲到的质量审计路径中，项目质量管理是从获取客户的质量期望开始的。

那么 ，我们应该怎么获取客户的质量期望呢？

之前我们在讲范围管理的时候 ，说过很多的方法，比如说访谈、定量分析、定性分析等。

其实各种方法都是通过跟客户沟通或者直接从客户那里获取一些白纸黑字的要求，这样帮助我们确认，客户认为怎么界定产品质量是不是可以接受的。

这部分工作其实就是在获取客户的质量期望。因为之前在范围管理中已经讲过，这里就不再具体展开讲述了。

不过有一个问题是，当我们获取了客户的质量期望之后，客户的质量期望可能有很多，也会有很多不同的条件，这些条件我们不一定全都能满足。

所以我们需要为客户的质量期望建立优先级，到底有哪些验收标准是必须满足的，有哪些是可以差一点去满足的。

如果在项目前期 ，我们没有界定清楚的话，就按照自己的想法决定优先满足哪些验收标准，到项目结束的时候就会发现，很有可能我们和客户的的验收标准是不一样的。

当我们和客户的验收标准不一致的时候，那客户很可能会对项目的可交付成果不满意。

为了避免出现这种问题，在项目一开始的时候，不但要明确客户对项目产品的验收标准。

而且要搞清楚，对客户来说哪些标准是最重要的，哪些是不重要的，也就是要把客户对产品的验收标准进行排序。

比如说我们要上线一个新系统，可能会基于各种不同的维度产生很多的验收标准。

有的客户会认为系统功能是最重要的，有的客户会认为系统的运行速度是最重要的。

就算是对同一个维度，不同客户的验收标准也可能是不一致的，比如有客户觉得同一个页面功能越多越好，还有客户觉得同一个页面功能越少越好。

100个人可能会对项目质量有100个期望 ，但我们的验收标准不可能同时满足所有人的期望。

所以我们需要想办法对客户的验收标准进行分级，因为如果我们不能同时满足所有验收标准的时候，就需要知道哪些标准应该先满足，哪些标准可以后满足。

在这个时候我们需要用到一个技术，叫做优先排序技术（Moscow）。

这种技术是把所有的事情都分成了四个不同的优先级——

优先级第一位的事情是必须做的（Must）

优先级第二位的事情是应该做的（should）

优先级第三位的事情是可以做的（could）

而优先级第四位的事情是可以不做的（won't）

我们可以使用这种方法对不同相关方的验收标准进行排序，分别是：

必须达到的验收标准有哪些，这些标准是产品必须要通过的；

应该达到的验收标准有哪些，从理论上来说这些标准也是必须要达到的；

可以达到的验收标准有哪些，如果时间不够那我们是可以考虑把这些标准拿掉的；

还有一部分标准是可以不做的 ，这部分标准我们直接拿掉就行了。

另外，还有一个容易被大家忽略的地方是什么呢？就是容许偏差的问题。

大家都知道质量标准不是死的，它一定不是一个具体的数字，而是一个区间。

比如说我们做一个IT 项目，在系统上线的时候会有很多的技术参数，这些技术参数一定是有一个范围的。

但很多IT 系统并不是只有技术参数，因为很多IT项目最终都是为了解决业务的问题，这个项目对业务的支持是体现在业务流转过程中的。

也就是说，只有业务人员觉得好用，那产品才是好用的；如果业务人员觉得不好用，那它就不好用。

所以，很多时候我们会去看质量的容许偏差，比如说像压力测试、bug数量这些容许偏差的标准是很容易制定的。

但也有一些质量的容许偏差不是那么好制定的，就像我们常说的“界面友好性”。

什么是好的，什么是不好的，这个是一定要达成共识的，比如是不是业务部门有一半的人觉得好就可以了，还是业务代表觉得没问题就可以了。

这些都是需要去谈的，它是有一个容许偏差的活动量在里面的。

所以，除了在技术参数上需要有一个容许偏差的空间，在业务层面也需要有更加灵活的容许偏差.

当然这需要我们在项目前期跟业务部门达成共识，这样验收的时候才好协商。

再有就是验收方法，这也是项目经理不能忽视的问题。因为不同的人验收方法是不一样的。

举个简单的例子，比如我们开发完某个系统之后，会进行集成测试。然后要找业务部门在测试环境下进行测试。

上线之后，在生产环境下把产品不同的功能都测试没问题之后，测试就完成了。

问题是，这种验收方法必须要在项目前期跟业务部门达成共识，否则业务部门可能会有别的验收方法。

比如他们可能会提出一些你完全没有想到的测试场景，或者他们会有一些自己进行测试的方法，他们使用系统的方式可能和IT部门是千差万别的。

所以怎么进行验收，是需要跟业务部门进行界定的。

不是说业务部门验收的方式不对，很多时候我们认为业务部门的验收是更正确的，因为本来很多的IT项目就是为了满足业务部门的需求。

所以我们需要在项目前期跟业务部门沟通清楚，看他们打算怎么进行验收，了解他们在实际场景中是怎么去使用这个项目产品的，这些都需要和业务部门达成共识。

就算这些问题业务部门没有提出来，我们也要去提醒他，让他们去思考这些问题。

不管是站在公司的角度、业务的角度、还是IT项目的角度来说，双方都要就项目验收方法达成共识。

这样才能保证项目成果是令大家都满意的。

最后业务职责的问题也是需要加以重视的，到底由谁负责验收也是需要在项目一开始就明确下来的。

项目没有人验收或者验收的人太多都是有问题的。

如果没有界定出来由谁负责验收项目，将来验收过程中又会产生各种问题，可能有的人觉得验收通过了，有的人觉得没通过，那这样项目就一直不能结项了。

所以，在项目一开始，我们必须要就质量容许偏差、验收方法、验收职责和关键相关方达成共识，这也是我们做好质量管理的起点。

好了，以上就是我们今天的主要内容，希望通过今天的内容能够帮助你了解，在项目前期与关键相关方就质量容许偏差、验收方法、验收职责和关键相关方达成共识的重要性，我们下期再见 ~

今日BGM

点击聆听

今天我们使用的BGM是由陈淑桦和罗大佑一起演唱的《滚滚红尘》，歌曲收录在专辑《一生守候》中，这首歌也是同名电影《滚婚红尘》的主题曲。

在歌曲中罗大佑一贯的率性中透着柔情，回应着一往情深的陈淑桦，也配合着暗暗起伏的旋律。

罗大佑创作的角度是顾全大局、高瞻远瞩，站在俯瞰芸芸众生的角度，以悲天悯人的旋律来唱尽世间情怀。

若干年之后，当我们重温这部影片时，这首主题曲还是穿透了滚滚红尘，滞留在我们的耳畔心间。

尤其那些经历过沧桑的人，当听到这熟悉的旋律和歌词时，一股难言的感动会从心底深处升起，耳边回响着：“起初不经意的你，和少年不经事的我，红尘中的情缘只因那生命匆匆不语的胶着。想是人世间的错，和前世流转的因果，终生的所有也不惜换取刹那阴阳的交流……”