Post by "robinshen", 11-29-2006, 9:17
-----------------------------------------------------
How to improve our work?
对于维护工作来说，能够在需要的时间内提供质量可靠的产品，是我们工作的核心目标，而其中质量则显得尤为重要，我们的所有工作的安排都应该围绕这个目的来进行。结合会计7维护工作中的一些经验和教训，谈一谈我的一些想法。
产品的质量就是产品的生命，其重要性不言而喻，那么如何才能保证我们提交的产品质量的可靠性呢？维护人员的责任心；工作能力；细心程度；是否有足够的耐心；经验等等。我们可以轻易地列出多个可以影响产品质量的因素。当然，对于维护工作来讲，产品的质量和维护人员息息相关，而维护工作对于维护人员的要求在各方面来说都相当的高，不巧的是，我们经常会发现找到一个有责任心，有工作能力，工作细心且有耐心，经验丰富的维护人员并不容易L。而一个人，即便是具有了上述优秀的素质，其能力也难免受到各方面客观因素的影响，从而导致出现意想不到的疏漏等，那么，什么才是保证产品质量的最有效手段呢？我认为有以下几个方面：
1） 合理的流程
为什么要说到工作流程呢？因为人的主观意识的不确定性太大，人的责任心，细心程度，耐心程度等受其他因素干扰而出现波动的可能性很大，虽然有的时候其本人并未察觉。如果将我们产品的质量交给毫无保证的主观意识，无疑是相当危险的。而工作流程则是一个可观的东西，它能规范我们的工作，失其按照一定的规范来进行，从而能够避免许多因为人的主观意识而导致的错误。而无数的成功经验都告诉我们，合理的工作流程正在各方面发挥着非常重要的作用。我们的维护工作需要有责任心，有工作能力，细心，有耐心而且经验丰富的维护人员，只有这样，我们的工作才能做得好，但是如果我们将对产品质量的追求归结为对维护人员能力的依赖，那就大错特错了，我们应该达到的效果是，利用我们科学合理的操作规范，使得不管维护人员如何改变，都能保证我们交付的产品质量不受影响。
那么，维护工作需要什么样的工作流程呢？
从一次批量的修改开始说起，最初是对需要修改的bug的大致分析，估算出大概需要的时间并安排Schedule，然后是和需求方确认，得出最后的Schedule，根据经验，Schedule没有必要细化到一个小时，能细化到2个小时就可以了，另外需要在允许范围内预留适当的预留时间，通常维护工作中会有一些临时需要调查的问题，虽然其占用时间多少并不固定，但最好估计一下并将这部分时间考虑到Schedule中。接下来就是按照Schedule的安排修改Bug，这个环节没有什么特别要说的，不过如果需要修改的bug量比较大，总体修改需要的时间跨度比较长的话，应该考虑中间安排几次小结，对修过的bug进行回顾并安排简单的测试，对Schedule和实际进度的差别进行适当调整，以保证工作的有序性，避免后期时间紧张造成质量没有保证。一般来讲这样的小结以一个月至40天为宜，可以根据具体的情况作适当调整。需要重点说的是在bug修改完毕以后，到提交新版本之间这段时间。在bug修改完成以后，最好安排专门的测试人员专门进行测试（当然每一个bug在单独修改完成后都应该是被维护人员自己大概测试过的），同时维护人员利用这段时间进行Code review,逐一回顾修改过的每一个bug，如果时间和人员上允许，最好专门安排一个对该产品比较了解的人一起作。而对于测试人员来说，对产品的测试则不仅仅要测试修改过的每一个bug，也应该在最后提交之前进行一次全面测试。因为通常第一次针对每一个bug的测试会发现一些问题，需要重新修改，所以我倾向于在修改后对每一个bug在进行一次测试，直到没有问题后，才安排全面的测试。当然这些会花费大量的人力和时间，但在产品提交前的短时间内投入较多的精力保证产品质量是值得的。
以上的流程是对我们现有的会计7维护工作流程的一些总结以及自己的一些想法，希望能起到一些抛砖引玉的作用。
2） 足够的投入和重视
提到这个，并不是说我们原来对维护工作不够重视，我们都很明白我们提交出去的产品质量对于我们来说意味着什么，我们都希望能提交出去的产品质量上乘，能得到用户的认可和好评，为此我们也采取了各种有效的方法以及必要的投入，但是，由于我们目前人手有限，使得我们对维护工作的投入大打折扣。我们每一个产品的维护工作通常是一个人负责，在每次提交之前，会安排一个测试人员进行测试，但是由于我们人手有限，开发进度紧等原因，维护工作的测试往往得不到足够的投入，临时抽出来的两天的测试时间，有时候甚至不能保证能整块的放在维护产品的测试上，而这些都会影响测试的效果，进而影响产品的质量。关于在维护方面测试的投入，由于客观条件的限制，我们可能目前无法有更大的改进，但是无论如何，我觉得这方面都应该引起我们的重视。有时候我们寄希望于维护人员的细心和自己测试来保证产品的质量，我觉得这是不合理的，维护人员细心一些，考虑周全一些的确可以避免很多问题，但是这只是一个手段，而不能成为依赖，一个人再细心，总有疏漏（客观上的确是这样L），而指望一个人自己测自己写的程序，其中的不妥之处就更是一目了然了，不然，我们干脆在开发的时候就完全不需要测试人员了，大家都自己测自己的程序就可以了。但是显然，这个是行不通的。
3） 明确责任
说要明确责任，并不是说为了追究责任，因为大家工作都是一个目标，为了保证产品的质量，这里说的明确责任，或许说明确分工更为合适一些，就是要让每个人都明白自己需要做什么。比如说，维护人员的责任就是在修改问题的时候尽量考虑全面，尽量细心以避免错误，高质量的修改程序，当然，也包括对产品的备份，一些文档的整理等等；而测试人员的责任就是要尽量去发现问题，不漏掉任何问题。考虑到我们公司的特殊性，我们和日方的工作分工就更应该明确，以免出现相互依赖和误会。
另外我觉得还应该保证维护人员和测试人员工作的独立性，避免相互之间的影响。比如说面对一个bug，测试人员在测试的时候，不去管维护人员怎么修改，只从最原始的资料（对我们来说就是public folder 里的bug以及一些确认的mail）出发，按照自己的理解测试，这样才更能发现问题，这本身也是一个相互制衡的关系，可以避免因维护人员和测试人员的思维误区的重叠而导致共同的疏漏。
做了一年多的维护工作，对这一年来的工作也时常有些思考，回顾这一年的工作，有比较让自己满意的地方，也有许多失误，对于成功，固然值得高兴，而对于工作的失误，我认为也完全没有必要失望，毕竟从中反映出了我们工作中不够完善的地方，而从中吸取教训，思考如何能把我们的工作做得更好，才是最有价值和意义的事情。值得令人高兴的是，在维护工作中我也学到了不少的东西，慢慢的变得更有经验，同时，我们对于维护工作也有了越来越多的投入和重视，管理上也越来越规范化，可以预见我们以后的工作会做得越来越好。
以上原本是我们上次开会前我写的一些想法，这几天又作了一些修改，希望能为我们的工作提供一些借鉴，有不妥的地方还请指正。 |
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图