小幺-幺言惑众

在考虑如何提高产品质量前，我们需要明白什么是产品的质量，对于很多从事软件开发或者互联网开发的工程师或者项目经理来说，第一反应估计应该是：“产品的质量就是产品的缺陷率“。这也无可厚非，这帮哥们都让绩效考核、KPI跟折腾的。其实真正的产品质量应该和用户满意度画上等号。考量一个产品是否满足质量要求应该就是考量的一个产品是否满足用户的要求，当然这里的用户是一个逻辑的概念，指产品的典型目标用户。

所以要提高产品质量就是要提高产品的用户满意度。这是一个系统的工程，涵盖了产品设计，产品开发的所有阶段和方方面面。基于时间和篇幅的考虑，本文只想对软件本身的质量来进行讨论。

一：软件的质量是规划出来的，而不是测试出来。

个人认为，项目的计划阶段已经决定了软件的质量。很多项目人员和项目经理一直对做软件的开发计划异常的不理解，认为在软件的过程种各种风险发生的可能太大，计划永远都跟不上变化。而我认为，这里的软件开发计划并不仅仅是一个时间计划。而是让项目经历在计划的过程种综合考虑项目的实施的各个方面，包括范围，进度，质量，风险等，从而形成一份包括进度计划，质量保证计划和风险计划的项目管理计划。在这里根据项目的情况，这些计划可以不以书面的形式来进行体现。然而项目经理一定要经过充分的思考和规划。

为保证软件产品的质量，项目经理在这个阶段要考虑的因素包括但不限于如下各个方面

1：定义项目的质量目标，这些指标包括功能指标，性能指标等等。项目也可以根据公司的情况为各个研发活动定义质量目标。比如设计阶段的Bug检出率等等。质量目标是基于，质量保证活动都要依据目标进行建设。

2：项目采用的软件开发流程。采用什么样的流程取决了公司的标准流程和裁剪规范以及软件项目的难以程度。在这个研发活动中项目经理需要根据自己的经验判断项目需要的质量保证过程。比如是否需要引入单元测试，是否需要测试用例等等

3：项目的三要素的平衡，我们之前说过，产品的质量=产品的用户满意度。所以对不同的产品用户的满意度是不同的，比如电信产品的质量要求和互联网产品的质量要求是不同的，项目经理需要能够根据产品的用户满意素来决定在项目的三要素之间来进行平衡。

4：项目的质量保证计划，这个研发活动应该是SQA的职责，但是很多企业都没有设立这个职位，在没有这个职位的时候，默认应该由项目经理来承担这个职责。项目经理要根据之前定义的项目目标来定义质量保证活动和质量保证计划。项目质量保证计划需要依据项目定义的软件开发流程，是对软件开发流程种质量活动的更详细的定义。

不管你采用的CMM还是敏捷的软件开发，以上活动都需要进行，只不过进行的复杂程度和研发活动的交付不同罢了，最基本的要求是项目经理要在自己的脑子里面考虑过以上事情。

从管理上来说“软件的质量是规划出来的，而不是测试出来”讲的是流程。决定软件产品质量的另外一个关键要素是人。这里的人包括了技能这个要素。在网络上关于CMM和敏捷开发的讨论层出不穷，基于我对它们的极端的理解。CMM强调的是流程。流程为王。而敏捷开发更多的是强调人的作用。当然这是一个极端的理解，它们的区别主要体现在侧重点的不同上。

       二： 产品是人做到的，所以产品的质量完全取决于产品的开发人员。

然而对人的管理是一门艺术，要远复杂与一切流程和规范。所以这部分技巧的整理是一个难题，有点只可意会不可言传的味道。再这里我只能做一个粗层次的介绍

    1：建立团队文化

建立团队文化非常的重要，因为重要所以也比较难以建立。你要提高产品的质量，首先要在您的团队里面建立一种负责任的团队文化，这只是其中一点，也是最重要的一点，如何建立高校的团队文化请参考本博客的相关文章。

    2：提高团队的技能，建立学习型组织

培养下属永远是一个Leader的主要职责，您需要通过努力把您的团队内建设成为一个学习型的组织，进而形成进取的团队文化，如何建立学习型组织请参考：http://www.abuer.com/manage/building-learing-organization.html

总之，如果您要提高您的产品质量，你可以从两方面下手，第一：建立一套合适的产品开发体系，可以参考IPD 。第二：进行团队建设，建立高效能的团队。

People often try to solve problems by introducing rules in an organization, in the form of “When situation X occurs again, you must do Y.” I admit that I am sometimes guilty of such behavior myself, though I am convinced that it is not the best approach. It is better to leave rule selection to individual team members, and instead focus on imposing the proper constraints. Agile software development should be about setting constraints, not rules.

It has been discovered that the flocking of birds can easily be modeled on a computer. This behavior, which is also apparent in many other kinds of animals, emerges through the application of a few very simple constraints:

1. Don’t leave the group;
2. Don’t bump into each other;
3. Fly in the same direction.

Specific implementations of these constraints are often used in the movie industry to create computer animated birds, bats, fish, penguins, you name it. (An example of such a model of flocking behavior is available here.)

Though we usually don’t talk about flocking when it concerns humans, the differences between a human team and a flock of birds aren’t that big. For a teams of software developers, flocking might roughly translate to these constraints:

1. Don’t single yourself out;
2. Don’t fight with team members;
3. Agree on the team’s direction.

Flocking behavior is often mentioned as an example of how a system can show complex behavior with only a few simple rules. However, I think the termrules here is not correct, or at least imprecise.

Complex Systems, Agents and Rules
Rules in complex systems are the building blocks of stimulus-response mechanisms. An agent receives some input (from other agents), processes it using a number of his own internal rules, and then responds by emitting some output (to other agents). The rules that an agent uses are not much more than a prioritized list of simple If-Then-Else constructs.

Now, I don’t know much about modeling computer generated animals, but I’m sure that the three constraints listed above are insufficient in getting the job done. A lot more actual code is needed to make sure that birds, bats, fish and penguins show behavior that conforms to these constraints. The actual rules, hardwired in tiny animal brains, or written in some programming language, might be something like this:

1. Calculate the average position of the birds that I can see;
2. Calculate the average direction of the birds that I can see;
3. If my distance from the average position > constant A, then adjust my direction towards the average by X degrees;
4. If the distance between me and some other bird < constant B, then move away from it by Y degrees;
5. If my direction deviates more than C degrees from the average direction, then adjust my direction by Z degrees towards the average;
6. Etc…
7. Repeat until we’ve landed.

Rules like this are a better reflection of what each individual in the group actually does. The result is that each individual won’t go astray, avoids collisions, and keeps up with the group. Which is exactly what evolution and natural selection required them to do, or they wouldn’t survive. But the actual rule selection process, carried out by each individual, is the result of trial-and-error by genetic programming and learning-by-example.

It’s Not About Rules, It’s About Constraints
The mistake people often make is that they directly try to “program” team members by giving them rules to follow. “IF you receive this type of document THEN you must perform that activity,” and “IF the customer wants some new requirement THEN you must start this-or-that procedure.” But the power of complex systems is that agents can manage their own rule selection process. People must restrict themselves to setting constraints, and then allow team members to solve their own problems.

Agile software development is the natural approach to manage software projects. It sets constraints like “collaborate with the customer“, “allow frequent changes” and “only deliver stuff that works“. And then it’s up to the team to select and implement rules like “IF the customer cannot travel THEN we do our demo using Skype,” or “IF there’s change request THEN we create a new branch in source control,” and “IF someone breaks the build THEN he must wear the funny rabbit ears.”

This also means that agile software development is not in the first place about pair programming, TDD, iterations, and the specific implementations of other rules and practices. (Note: the Agile Manifesto doesn’t mention any of these!) Sure, those practices are interesting and important. But as soon as you’re imposing them as fixed rules, you’re not allowing the agents in your complex system to carry out their own rule selection process.

And then they’ve lost the ability to be really agile.

http://www.noop.nl/2008/12/real-agile-teams-can-flock.html

Jurgen Appelo的部分观点如下：

鸟群行为的基本特点：

1. 不许离群
2. 不许相撞
3. 往一个方向飞

映射到研发段对上：

1. 不要把自己孤立
2. 不要跟其他人打架
3. 与团队的方向保持一致

有兴趣大家还是读一下原文。

花了基本上一个月的时间整理出来的全套的IPD项目管理和绩效管理流程。在Abuer’s blog上形成了两篇Blog

IPD项目管理和绩效管理（一）

IPD项目管理和绩效管理（二)

本来准备继续以Blog的形式贴出来，但是Blog的格式一直不是很理想，图片也看不清楚。所以把原始的Word文档贴了出来分享：《IPD(集成产品开发)项目管理和绩效管理完全手册》

IPD是华为从IBM引入的集成产品开发的方面，是一套非常优秀的管理系统。国内的一些搞IPD咨询的咨询公司大部门都是从华为出来成立的咨询公司。IPD虽好但并不一定适合每一个企业。

希望大家能够根据自己的企业情况进行优化。

和传统的软件企业不同，互联网企业的研发管理更加强调对市场的快速反应。在互联网企业里CMM、CMMI基本都是不和时宜的。而敏捷开发却由于其采用的快速迭代和轻量级的管理流程而更加适合互联网企业。然而轻量级的管理流程不是对管理的弱化。而需要更强的管理技巧。

就像《管理的境界》所言，和CMM不同，敏捷开发更加依赖人员的责任感、激情。如何调动产品开发人员的激情。这恰恰是管理的难点。也是一个管理者应该潜心修炼的技能。

Getting Real 由 37signals著作。37signals是一家位于芝加哥的创业型小公司，公司小到只有8个员工，但在业界享有盛誉。在芝加哥办公室上 班的有4个人，其余4个人分别在纽约，波特兰等城市soho办公。但是37signals公司基于web的小型商业软件产品的注册用户却超过了100万。《Geting Real》是一般操作性很强的书籍。非常适合互联网企业的研发管理。

网上有word版本的读书笔记，我把他放在我的服务器上。大家有兴趣可以研究交流一下< Getting_Real>

接上篇：《IPD项目管理和绩效管理一》

IPD概念阶段：

产品团队的开发强调以市场的成功为产品的成功，因此在进入产品开发，需要做细致的市场分析和产品调查，定位产品的细分市场以及定义产品的盈利模式。因此在产品开发团队之前需要有产品经理或者PMT（产品管理团队）来完成产品的市场分析，用以保证开发处理的产品能够满足和适应将来的市场和客户需求。当产品业务计划得到公司高层的通过，该产品方可进入开发阶段。

该阶段各个成员的主要活动和职责：

IPD计划阶段：

      通过概念决策评审后，产品开发进入计划阶段。在该阶段产品开发团队核心组成员基于对业务计划和需求的理解下，定义产品开发的项目计划，资源计划，风险管理计划，以及配置管理计划，质量计划等。

      二级计划指各个扩展组的计划，三级计划指包含子系统的扩展组的详细的时间和资源计划，如果没有则不需要三级计划。

该阶段各个成员的主要活动和职责：

IPD开发阶段：

      通过计划决策评审后，进入项目的开发实施阶段。各个PDT扩展组根据计划阶段定义的开发实施计划完成产品的规格开发，确保产品的最终的市场成功。

IPD验证阶段：

经过技术评审后的产品进入验证阶段确保产品的质量和功能满足用户需求。保证产品的最终能够成功。

  IPD发布阶段：

经过中试的产品并结果技术评审和决策评审后进入发布阶段。