《产品研发过程实践》（19） SQA

作者:asky 日期:2007-04-29

字体大小: 小中大

SQA人员，是一个对项目流程进行监控的人员。他是一个监控者的角色。我们可以想像一点，SQA使用各种方式，从项目中获取信息，并且站在第三方的角度上，来衡量项目的进程，估算项目的进展。并且通过各种通报手段进行预警等工作。

但是，恐怕绝大多数公司SQA部门似乎变成了一个文档管理部门，他们仅仅监控了项目的关键几份文档的入库，认为通过监控这些文档，就可以监控整个过程了。这是一个笑话。负责一些的SQA人员，会通过长时间的工作，感到一些不对劲，为什么我总是无法发现项目问题呢？于是私下的频繁沟通，换位思考等更有效的方法开始衍生出来，这是一个进步，比那种“文档保管员”有用得多。他们至少开始意识到自己和项目组团队不是警察和小偷之间的关系，是一种合作关系（这不是公司的大道理，那种大道理我连听都不想听）；但是，他们还是发现，自己对于流程的监控并不是那么有效，经常是外部而不是他们发现项目组问题，这似乎成了一个事后追查部门，而不是过程监控的部门。

在我和SQA人员进行配合的过程，我对以下几种SQA人员抱有好感，他们一般具备以下的特制：

1.          他们多少是参与过项目，并且很多人在进行SQA管理之前，具有非常丰富的项目管理经验，我曾经碰到过一个SQA Leader，具备6年以上项目管理经验；和他进行合作的时候，我感到至少我们能够就某些问题的操作性进行一些讨论，并且他也能理解我在项目中碰到的具体问题，并为我提出建议，如何进行流程裁减，并且执行某几个关键流程来解决目前的问题；

2.          他们是良好的沟通者和良好的协调者，他们很会换位思考能力。让一个团队或者一个个人喜欢一个“监工”，是一句笑话，但是在公司各个部门合作过程中，如果仅仅是这种关系，将是一个双败的结局，当然，SQA可以通过通报的方式，来使得项目组按照流程来进展，但是项目经理也可以通过事后造文档等等工作，来使得目标发生严重偏移。和上面提到的那个SQA的合作过程中，他经常性提到的一个词是“操作性”，我们最主要讨论的问题是：根据团队的现状，我们主要需要改进哪几个点？而不是在你面前摊开一本书，然后说：“照着这个玩意干！”。这种SQA基本上是扯淡！

3.          他们是一个数据敏感性的人，他们能够根据公司大量的项目数据，进行各种整体和搜集，从中发现问题，并且提出改进现实的改进措施。在得实和SQA的合作中，是比较让人愉快的。SQA经理最经常说的一句话是：“我如何能够帮助你在项目中进行改进？”，虽然我们所希望看见的改变，一点也没有发生，但是，至少让我感觉到了我们是一起企图让项目走得更顺利的。SQA经理，在2004年末，对开发一部的所有项目进行了综合和分析，的确让我看见了不少存在的问题，以及一些主观和客观上存在的因素；

4.          他们是一个乐于接受新事物的人，而不是紧紧抱着N多年以前的某个观点不放的。当然新观点，不一定是正确的观点，老的观点，不一定是腐朽的个观点；但是，对于项目管理过程中的新思路，和新思维的接受，恐怕并不是对SQA的奢求，毕竟这是你的本职工作；但是，有多少SQA乐于接受新的流程和过程？并且考虑在这种情况下，如何进行监控，能够给自己带来什么变化？

5.          讲求操作性，而不仅仅是原则：SQA说明需要做什么，但是具体做事的人，是项目组成员。所以，在执行一个原则的时候，请多少考虑考虑可操作性，不要发布了一堆规则，然后让大家执行。如果执行发生问题，就说是项目组的问题，事实上，这也是我们不成熟的一个表现，在公认的情况下，这一般是管理者的问题。请记住这一点，当你发布如下命令的时候，你就成了一个“具备理想化倾向的监工”，比如在没有专职文档工程师的前提下，需要对超过30份文档进行相互间逻辑的维护工作；希望通过各种流程和规范，认为能够使得所有工作不再需要经验，而仅仅需要傻瓜就能完成；等等。明确的说：这是不现实的，如果你一定要发布这种流程，请至少自己先做一次，然后再考虑如何推进，只考虑目标，不考虑是否能够实际操作的人，也许学校的课堂是一个好的归宿，但是公司不是！

在这里多说一句的是：流程是什么？流程是一种经验的固化，他的作用是使得各个团队之间的经验能够得到快速复制，并且使得一个团队快速得到成长；但是绝大多数流程缺乏前置条件，这隐藏着一个假设，即认为所有项目都能从一个一致的过程中，得到有益的指导；这实际上，是不现实的。举一个旁证，我们招聘一个管理者（People Manager）的时候，喜欢问的几个问题是：“你如何对待团队中的冲突？”“你如何对你的下属进行考核？”等等，事实上，我们大家都知道，任何一个公司中，无论是季度考核还是年度考核，都是有流程的，但是，我们为什么问这个问题，我们希望听见的，不是你们的考核表如何组成这种文档上的东西，而是你如何面对考核过程中的沟通问题，如何通过考核，来实现你的组织目标等等；我们绝对不会因为一个人掌握了一个大型公司（比如GE公司）的全套规章制度，就认为他是一个良好的管理者，绝对不是！（顺便说一句，我这里有大约100M的这样的文档模板，如果有谁认为这是一个管理者的80%的工作，请向我索要，我保证你能够通过阅读这些文档，顺利地成长为以一个出色的“规章制度管理员”）。那么为什么我们认为项目管理就是这样一种流程呢？无视项目中的不同，无视其他的前置条件，仅仅通过一些规章制度，就能做好呢？此上的话题也许有些偏激，但是这是我在工作经验中，感觉这种思路给软件业造成的损害，已经开始越来越突出了。有一个大型软件公司的老总宣称，只要给民工培训3个月，他们就能成为一个合格的软件工程师。我不相信这一点，也许这种软件也就能给仅仅通过3个月的民工所使用（当然，在这里我无意对民工表示任何的不尊，因为这一天即使到来了，我还是会尊重我手下的每一个程序员，是他们用自己的聪明来构造了整个软件，而不是流程构造了整个软件，虽然流程有助于构造好的软件）。

我做为一个比较愤青的项目经理（大家说，70年代的人，是一个愤青的年代，也许吧，我觉得我还是不够成熟，还是一个愤青，但是愤青有一个好处，就是会说出自己的不满，而不会假装喜欢），向各位SQA提出一个要求，请你在发布任何一个流程的时候，用笔计算一下，这个流程给整个开发成本造成多少影响，你的目的是什么？看看为了达到你的目的，我们是否值得付出这些成本？看看还有没有更简洁的方式，来达到同样的目的。我不希望仅仅为了煮熟一个鸡蛋，就烧毁整个村庄，虽然他也能煮熟鸡蛋。

同时，请建立自己的理论体系，不要看见文档都正常入库了，就认为一切正常了，如果项目如此简单地就能进行管理，恐怕也不需要有经验的项目经理了。请在自己每个流程企图去落实的时候，考虑一下如何逐步推进，如何在将来对这个流程进行评判，是否真的对软件有利？是否能够节省掉其中的某些部分。这是对于一个管理者来说，非常重要的活动发起能力，请多少锻炼一下自己的流程发起能力。说到这里，想起一点不同来，在很多外企，非常关注一个管理者的活动发起能力，如果一个活动不能发起，不能落实，是管理者的职责，但是很多国内的企业，把这个看成一个属下的一个执行能力。呵呵，这一点的确很奇怪的，执行能力不是为了弥补发起能力的不足的。缺乏前者，强调后者，恐怕效果也不会很好。联想的执行能力很强，但是一般来说，我们看不见强制发起的一系列流程，都会经过一个阶段的铺垫然后再开展下去（包括裁员的时候也是如此，一般提前2个月就开始有风声了，告诉你，找找自己的奶酪哦……）

如果说，我们看见不足，立即用流程规范，是一种快速变化的短期行为，那么同样的，请在发现流程过于庞杂的时候，也请立即削减流程或者适应流程。请保护保护各位公司中的项目经理，他们的精力不是无限的，他们只能有精力做好几件事情，如果什么都要做，那么他们只能做死为止了。

我推荐的一种监控过程是如此的：在项目的阶段中，设置Mailstone，不管Mailstone是什么，但是目标必须是可见的，比如某一个功能被加入到项目中，做为内部版本发布了（有一些项目经理告诉我，这对於他们的项目来说不现实，我的认识是：不可能，一个项目不可能只能在最后才能集成起来，如果是那样，所有项目管理的所谓监控都是扯淡，我们都是在空谈。如果一定要这么做，那么还不如不监控好了），相关的设计文档和需求文档被更新了，同时这些功能通过了简单的冒烟测试，被测试人员所接受，那么这个Mailstone算通过。在项目过程中通过此种方式来进行监控project的进展，成本计划和风险计划，在项目周报中体现，并且这是项目周报最需要关注的点。在项目后期，进入到集成测试阶段，那么Bug图表是必须监控的。从Bug系统中导出的Bug情况日报表和修复Bug所需要的时间等等，是可以从中看出项目是否在正常推进的。在每个Release阶段，我们需要对BaseLine的成果进行一次Review，在明确需要进行的某几个过程和文档（我的建议是，如果你的团队非常不愿意，或者你的团队还没有到这个程度，那么还不如不做，但是如果确定要做的几个过程，还是有必要加以严格监控的。我的唯一建议是：做好你能够做好的事情，就能够使得团队不断进步。），加以监控。仅仅是监控文档或者监控周报，没有任何数据支撑，仅仅是描述，企图用此来监控项目，不如说是为了收集数据，准备在后期给项目经理失败的时候，来个最后一击而已。

同时，加强和项目经理的沟通，包括公开的沟通，比如非常重要的几个会议：项目首次例会，项目的启动会议等等，这些会议还是参加比较好，不然这些信息你还是需要向项目经理咨询的。那么还是自己了解一下比较方便；包括私下的沟通，我的建议是：如果一个SQA同时监控的项目为7-8个的话，那么你应该有时间，可以就这些项目，每周和具体项目经理进行一次面谈，为时大概半小时到一小时左右，看看项目进展如何，并且反馈一些问题和意见。这些私下的反馈，会让你了解到很多台面上不能讲的话（你别告诉我，你们公司如此的公开，以至于这种私下的沟通是不需要的，我只能说，如果有这种念头，恐怕太幼稚了）。但是记住一点，不要把私下沟通的一些内容，在公司内部传播，不管是正式渠道还是非正式渠道，不然当项目经理知道，他私下沟通的内容，第二天就会放在老板的办公桌上，那么任谁都无法和你沟通了，你所要做的就是，了解这些信息，并且看看，如何处理这些问题，加强SQA和团队的合作。

做好一个SQA有1个基本的平衡能力需要把握，首先，SQA首先是一个监督的角色，所以不要费尽心机去企图讨好项目经理，这是和你的岗位职责相违背的，从一个职业素养的角度来说，说出你应该说的，是一个SQA必须的，否则要你何用？其次，SQA又需要站在一个合作的角度来进行工作，正如上面说的，监工的事情，在IT行业中，特别对于SQA来说，是一个很难做好的事情。OK，任何工作都需要在钢丝上跳舞，希望SQA的同仁们也跳的漂亮一些吧，别老是搞得自己和“人形的规章制度”一样，挺累的，不是吗？如果一件事情，你做得如此累，而且别人也觉得很无聊，那么也许这件事情本身就错了。

其实，上面推荐的方式，不管如何做，关键点就是三个：明确监控的点是什么，监控的点的产出必须是和产品产出明确挂钩的（象什么开发人员日志之类的东西，就不必监控了，意义不大，那是项目组内部的事情，如果你非要把这些文档拿出来给别人评审，那么想想你小时候为老师写的周记吧。反正我已经很多次拣到钱和很多次搀扶老奶奶过马路了），沟通能力！

和诸位SQA共勉！