ASK MO第71期 | 除了惩罚和激励，还有什么办法提高软件质量？

如何提升品质，就要从质量本身着手，上线之后问题多，我们需要找出问题的原因，而不是第一时间看我们敏捷流程哪些地方做得不好，流程不能解决一切问题。

就拿上线后问题较多举例，问题是由很多原因造成的：

1、比如我们测试的时候没有问题，但是放到外网就出了很多问题，那极有可能是测试环境和外网环境差异较大引起的，而且没有搭建预发布环境，没有在这个环境上测试过。

2、系统太复杂，改一发则动全身，外网BUG不知道怎么的就引发了。

3、项目时间紧，开发提交测试延期，但是上线时间又是固定的，没有时间进行充分测试，所以只能匆忙测试上线，上线之后问题比较多。

4、开发提测版本质量较差，测试用例只能走通1/3，其他用例走不下去，只能要求开发再提交一个版本。

5、测试出太多问题，开发没有时间去修改，但看到版本上线时间这么紧，明知道有BUG还就只能发版本。

轻轻松松我就举出来这5个问题，其实还有很多，但很多问题不是敏捷可以解决的，我们还是具体问题具体分析会比较好。

如何制定敏捷开发质量规范&流程。其实我很怕听到“制定”两个字，很多公司培训了敏捷之后，也不考虑公司具体情况，就开始做敏捷开发流程，做敏捷质量标准，规范。

- 但是，敏捷有标准吗？

- 没有。

- 那定什么？需不需要流程和规范？

- 需要，但是流程需要演进而来，而不是空中楼阁。

拿敏捷的最佳实践往上去靠，这是小白玩敏捷最喜欢干的事情，也是很多敏捷教练喜欢教大家做的事情，而结果往往就是没什么用，领导是开心了，但是团队觉得不落地 ，形式化，很快就坚持不下去了。

- 那流程需要怎么做？

- 我们需要做找到试点团队，通过和试点团队一起工作，来试图找到试点团队的实践，然后进行改善，并让其他团队进行学习，再在其他团队产生实践，生成scrum master指导手册，此指导手册并不具有强制性，而是指导性。

最后，如果觉得指导手册当中的哪些实践非常好，可以固化下来，才考虑形成规范，这样才是公司的实践规范。

这个事情急不来的，冰冻三尺非一日之寒，解决问题也不是一朝一夕。

我在接触NPDP证书之前，发现的确没有产品经理的体系认证课程，NPDP应该是第一个。当我真正了去接触NPDP之后，发现这一套体系还真是有很多可取之处的。所以我也我也学了npdp，但是我发现npdp也会存在一些问题，因为他其实和很多培训一样的，就是这个东西是一套理论框架，其实看起来挺完整，但是需要落地的时候你会发现，其实有很多东西它落不了地啊，所以我觉得你用只是用他来拓展你的思维，让你有一套体系方案，其实是很好的东西。但存在一个落地的毛病，所以你自己要去甄别一下。

其实市面上很多这种培训认证都有这样的问题，就是你看起来好像他说的很有道理，但就是学完不知道怎么用起来，他只是蜻蜓点水的告诉你,一个好的产品体系是什么样的，但是他并不会告诉你说一个好的产品经理应该怎么做。这是很多人学过很多认证课程的一个通病。

所以为了解决问这个问题，我开始开发了acp的弟子班，那么acp的弟子班，我力求把他打造成中国第一个致用的项目经理平台，我希望在课堂上让你知道正统的acp是什么样的，然后等你考试完了之后啊我再不断的去教你，我们作为公司的项目经理，我们怎么样在公司去落地这一套方法，怎么样真正解决企业的问题。

让每个人学以致用，知行合一才是我一直以来所要打破的原有的这个市场上的一些乱象。

其实这个问题挺有意思的，初中高阶项目经理，我认为最大的区别其实是在于他自己的综合能力。

初级项目经理，其实他更注重的是他的执行力，也就是说你能够把别人安排你的一个事情能够独自做好，这个项目的跟进，你能够跟进好项目的计划，然后你能规避项目的风险，解决项目的问题就好了。

中级项目经理，其实他在处理问题的时候，他需要去借鉴一套方法论，比如说PMP的项目启动，计划，执行，监控，收尾。或者是敏捷的方法论，它能够依靠着那个方法论依葫芦画瓢把这个事情做好。并且，它能够对这个更复杂的项目进行管理，甚至跨团队的项目。

高级项目经理，他更多的是需要站在更高的角度上去思考，比如说。公司的业绩是什么？我怎样达成公司的业绩目标，需要哪些人来完成这个事情，这些人是怎么组织起来的，他们各自需要做一些什么事情，我要怎么样有效地去管理能控制风险？

最后，高级项目经理他是学习了一套方法论，并且它能够灵活的去运用，把这些方法论转变为自己的能力，然后不断去总结，输出自己的方法论。我认为这是高阶和中阶的最大的区别。

这个问题就像在问莫名老师，你觉得如果一个司机他闯红灯，我们不做任何惩罚的话，是不是我们等他素质高了之后，他就自然就不会闯红灯了。

所以我们解决这个问题，需要去让他看惨兮兮的车祸视频，需要提高他们的素质，加强素质教育。这些都可以去解决问题，但是它不是解决问题最有效的方式，因为见效太慢了，它是长期解决问题的方式。

你们以为这几年闯红灯事情少了是怎么弄的，这都是罚出来的，2个红灯你的驾照就没了。

最有效的方式当然是有奖有罚，很多团队的领导，特别是研发的领导，以前他自己是从底层一步步爬上来的，那么他当他坐上这个位置之后，通常都会比较体恤兄弟们，他会换位思考：恩，开发兄弟们很辛苦啊，挺不容易，加班这么多，项目时间又紧，所以他们质量不高，我可以批评一下，但是惩罚是不是做得有点过了。

其实这个是不对的。不要忽略一个问题，就是人和人之间是有差异的，如果大家都跟你一样自觉跟你一样积极，那当领导的就不是你就是他们了。

重新回到这个问题上来，提高代码质量和软件质量，除了惩罚的机制，我相信没有别的有效和快速的方法，假如我代码写的不好，工资也照发，年终奖没少我的，只是说两句，我就知道了，下次即使这样也不会有什么，还怪自己胆子不够大，我代码写得多，当然问题多了。

好，问题来了，人都会对比的，那些写代码写的好的人，会这样想：我花了很多精力去优化我的代码，质量我是最好的，但是我和别人代码写得差的没有什么区别，人性都是懒惰的，那为什么我要写的好呢？我只是在打一份工，我不是为了改变世界。

久而久之会造成劣币驱逐良币的现象，大家都会往坏的走，然后又有一个很好的借口，因为业务需求多，大家都在赶进度，但是我写代码写的快，领导看到的我出活就快。

另外，很多质量人员，现在的主流度量方法还是是代码行数，他们认为，我的代码行数够多，对组织的贡献也就越大，那么我就把这个优点放大不就好了。反正质量低点没有没有惩罚没关系，这个项目的80%的代码都是我写的，你好意思和我提这些小问题吗？写得多所以错的就多，这是很正常的。

很多质量人员希望去搞流程和规范，但是流程规范又没有奖罚，那做流程干嘛呢？还不如没有流程，大家越快越好就行了。

还有一些度量，它度量的是需求的生命周期，也就是说这个需求提出来到我上线总共花费的时间，越短越好，那么又会存在一个问题了，大家都在赶时间，你提的需求我立马响应是吧，那最好的方式是什么？我做一个需求发一个需求，这是不是最快的？对不对？我觉得不能做的需求我就坚决不接，能做我今天开始接，明天就上线，这个是不是最快的，大家都往着这个趋势走，那秩序算个啥？

而且我在做这个需求的时候，我绝对不会考虑后面那个需求。因为我一旦开始接了，那这个需求我就要最快的发布，我只要不开始，那需求还是在好好地放那里，不算我的绩效，所以说上有对策下有政策。

那么怎么样才是最好的呢？很简单，我们需要引入质量内建，就是每个人都要保证自己的完成质量。只要下游发现了你的质量问题，就可以给你相应的惩罚，这个要加入到你的绩效里面去，这样质量就有保证了。

· · ·END· · ·