管理成本与收益

周五又开周会了，气氛很凝重，主要是对近期发生的事情检讨，然后分析到底什么原因出现了这样的事情。

主要是因为两个项目，一个项目的事故在于用一个项目文件覆盖另外一个项目文件的时候，被覆盖的项目文件属性不会变。这一点很不make sense，而那个属性直接影响到手机同步数据的问题，所以自然到客户那边会感觉出了一个很大的事故。第二个项目的事故在于客户要求在每级数据库下加一个key字段，但是这边DEV在加的过程中，只注意到名称，没有注意到类型，导致某个key字段居然用image类型保存。

于是在会上每个人发表了自己的观点，总结起来主要就一点：心理麻痹。简单的说，在一个人在面对一个熟练工作的时候往往放松警惕，发展到最后事情有时候就不会考虑很全面，做事情的时候就不会足够的严谨。开发人员对自己放松了，很容易在产品中表现出来。第二个项目事故就是一个很好的例子，还是一个低级的失误，实在有些让人汗颜。

至于第一个事故，我的感觉还是过于自信。因为这个项目客户的一套API，IDE，客户端很特殊，网上找不到资料，而官方资料提供有限，所以很多机制，原理我们并不了解很透彻，在这种摸着石头过河的情况下，尽量还是少“想当然”一点，多检查几遍。说到检查，团队内部准备加入一个新的机制，就是放入一个Check list。每次最后软件打包的之前，由QA对照着Check list从上到下检查一遍，保证所有主要功能点覆盖而不遗漏。如果有这样的机制在的话，那么第一个项目事故就应该能够很快的检查出来，从而能够轻松定位到那个属性。

这样说来Check list就很重要了，因为任何管理手段都有成本，我们就应该在成本和收益之间找到平衡。Check list最好是要不遗漏，不重复。找出一条最短路径覆盖所有点，保证检查的效率。因为每次软件打包都有可能甚至对某些项目来说极有可能是在时间非常紧急的情况下发生的，能不能保证Check list的执行力是每个人应该思考的问题。根据我们目前项目组的情况，团队成员状态有所下滑，客户满意度有下降趋势，Check list的引入是非常有必要的。至于制定人的角色，可能QA更好些，第一是因为QA日常空闲时间比DEV要多，第二是因为写测试用例的QA写Check list驾轻路熟，第三是因为Check list主要是模拟客户行为找出比较大的问题或者低级错误的问题（以代替客户发现这些问题），而“模拟客户行为”QA更在行。

而团队成员有的也提出，搞一个“大家来找碴”的游戏，每次发给客户的邮件先发给我们大家，让大家帮助找错误。其实我是非常赞同这样的想法，第一保证质量，第二比较有趣味。但同时我也很担心这个游戏的成本和执行力。

个人方面，每个人每天都有自己的任务，都有自己最重要最紧急的事情，如果我在处理这些事情的过程中，有人邀请我做“大家来找碴”，我想我是不会做的，因为这种找碴本身很耗脑力和体力，除非我闲的时候我会看，否则我不会回复。机制方面，因为回复意味着你对你double check的结果负责，说到负责，“大家来找碴”最大的一个缺点是没有责任人，这是非常影响执行力的，“大家来找碴”其实就是一个mini的FTR，不过跟正式的FTR不同的是正式的会指定责任人，而这不会。没有责任人，那么发信的人就不知道等多长时间会回复，那么就不是很清楚是没有人看还是看了没有错误。团队方面，沟通的成本进一步增加，一天本来就有很多的邮件，客户的，leader的，同事的，如果还有与你无关的项目的邮件过来让你检查语法错误，我想每个人更会焦头烂额。

SQA也提出定期做一个全面的测试，但是开发主管也明显考虑到这个措施的成本以及收益之间的关系。

成本与收益，应该是软件项目始终要考虑的东西。