引论：

产品质量的好坏来自于客户的体验反馈，架构师的设计，产品的有序迭代、运营策划的客户调性匹配，售后部门的有效处理都是客户对产品质量感官的重要因素。然而这一切没有足够的资本驱动都是白费。

客户的体验反馈：

在客户管理工作中，客户服务工作是常与客户来往，直接为客户服务的工作，它起到公司和客户之间缓解矛盾、增进感情、加深了解进而提高服务的重要作用。 通过客户的咨询，反馈，投诉等问题发现企业存在的不足，以改善产品质量，改善服务规范，改进服务理念，客户服务的目的就是增加用户对企业的信心和忠诚度，从而提升企业的信誉和口碑，提升企业的业绩增长，客服服务对企业的长期发展有重要的作用。

架构师的设计：

系统架构师（又称企业架构师或者系统设计师）是一个最终确认和评估系统需求，给出开发规范，搭 建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。他/她主要着眼于系统的“技术实现”。因此他/她应该是特定的开发平台、语言、工具的大 师，对常见应用场景能马上给出最恰当的解决方案，同时要对所属的开发团队有足够的了解，能够评估自己的团队实现特定的功能需求需要的代价。

系统架构师该怎么来实现其“架构”企业的职能呢？尤其在设计企业 IT 策略时，该怎样体现架构师的价值？

这里以实例说明、摩托罗拉的副总裁 Toby Redshaw 说，架构师是“IT 策略中的中枢”，而且这一角色对公司的影响确实非常大。当 Toby Reshaw 在 2001 年进入摩托罗拉并担任其策略暨架构副总裁时，他俨然一位购房者对一套摇摇欲坠的公寓进行估价一样。他并不是仅仅只作些表面上的修改，而是拟定了一个重建摩 托罗拉整个基础结构的计划，这个计划可以彻底修整公司的基础建设。 就像一个建筑师设计一幢房子一样，Redshaw 拟出了一张技术构架蓝图，一座技术性的建筑，以便使被他称作“如意大利面条般错乱的应用程序，机器和管线”那些东西变得井然有序。他说，只要选择了正确的 架构策略并用对了人，摩托就可以用比以前更快的速度生产出大量应用软件，而且可以减少维持重叠系统的费用。 Redshaw 说、“如果你连建筑架构都搞不好，就算你的石匠技术再高明，又有什么用？架构师是 IT 策略中的中枢。” 像 Redshaw 这样的系统架构师们在企业内部的影响力非常大。很久以来，虽然他们一直在信息技术部门担任重要职务，但是他们经常受委托提供全面概况分析，并提出一些关于 如何遵照标准执行这些任务的建议，而这些对日常运作的影响极其有限。今天，随着各公司都在寻找重建他们的 IT 系统，使其更能有效节省成本，更灵活的方法，架构师愈来愈被看作是至关重要的因素。

一个定义明确的架构的目标在于降低运行复杂的运算系统的费用。一个公司可以采用一种特定的数据库配置，如微软的数据库，进而将系统标准化，而不需要让公司的每个部门安装它们自己所需要的数据库服务器。

Express 的技术架构副总裁 Andy Miller 说：“如果你没有一项强有力的架构策略，人人各行其是，最后以得到六种服务器和软件平台而告终，你的系统变成了大杂烩，而那将使你的费用激增。”把架构师 独立出来有很多好处，比如系统的整体把握，质量上的保障，技术上的先进性，架构的灵活性，高效性，还可有效地降低成本。试想，1 个月薪 1w 的架构师+10 个月薪5k 的工程师，肯定比 11 个月薪 6k 的高级工程师效果要好。一般来说，级别越高的架构师，经验更丰富，争相聘请的人也多，他们也是与公司全部的 IT 策略密切相关的专业人员。

产品的有序迭代：

互联网快速迭代，互联网产品应该设计简单，使用户接受。

运营策划的客户调性匹配：

产品策划分为两类;一类是产品研发策划，主要是针对市场需求，以细分市场为基础，形成一个产品开发的整体思路，以期拓展新的增长点。另一类是产品营销策划，即谋划通畅的销售渠道、持续的销售态势和维持产品设计的理想化售价，通俗讲，就是如何能更好地将产品卖掉，并在销售过程中，塑造新的品牌形象。

产品是企业的生命体，是企业创造社会价值和满足自身利益的唯一保障，失败的产品会给企业带来巨大的损失。国内每年上万的新产品上市，为什么成功的寥寥无几?这就缺乏严谨的产品策划工作所造成的后果，严谨科学的产品策划能让企业的产品推向市场就收获成功，避免错误的产品为企业带来巨大的损失。

测试的重要：

在很多大一些的IT公司，比如微软，开发职位叫Software Development Engineer，SDE，软件开发工程师;测试职位叫Software Development Engineer in Test，SDET，软件测试开发工程师，可见测试人员本质还是开发工程师。这有别于我们在公司里常常见到的QA，我是做游戏的，我见到的QA都是打开游 戏，然后点点点，从表现上测试功能是否正常，这样测试是无法全面测试的，这也难怪在很多公司里QA比开发团队地位低。我觉得，对于测试这个职位，要做好， 是很难的。他要能读懂策划文档和开发文档，从源头上开始着手。如果白盒测试，要能看懂别人写的代码;如果黑盒测试，要和开发人员多沟通，画出来实现的流程 图，并且分析网络协议;然后，设计完备的测试用例。如果不根据需求、设计和实现，设计完备的测试流程，而只是操作一下试试功能是否正常，很多隐藏的bug 是测试不出来的。

在传统软件行业：软件的质量和稳定最重要，代表企业：IBM、微软、思科等。根据我查到的资料，开发与测试人员比例，微软1:1，思科1:1.5，普 遍在1:1 – 3:1。SDET从需求文档、设计文档开始Review，SDE编码，SDET写测试用例，跟极限编程的过程类似。极限编程的基本过程：构思 - 编写测试代码 - 编写代码 - 测试，编写测试和编写代码都是增量式的，写一点测一点，在编写以后的代码中如果发现问题可以较快的追踪到问题的原因，减小回归错误的纠错难度。

而互联网行业：快很重要，有bug在线上也方便修改发布，更提倡full stack developer，代表企业：amazon、facebook、google等。开发与测试人员比例，google 10:1， MySpace 5:1。阿里资深专家，amazon前高级经理，陈皓认为：并不是互联网公司认为测试不重要，而是他们认为正因为测试很重要，所以才不应该交给只做测试的 人，开发人员要对自己开发的产品质量负责。对于一个公司，“产出性”的人应该多于“支持性”的人。当你的条件受限人手不够的时候，你必然不能干所有的事， 但你要去做很多自动化的事情，不管是自动化部署还是自动化运维。然而当你的人多的时候，你必然只会简单用人来解决问题。劳动密集型与知识密集型的公司差别 就在这里。

以微软和google为代表的保证产品质量的做法，都有道理，而且都是成功的。但是，我个人更倾向于full stack developer，第一，招很多SDET对大部分公司都不现实，合格的SDET薪资不会比SDE低;第二，我认为开发人员要对自己的开发的内容负责，主 动的想办法提高产品质量，而不是被动的等测试。

产品质量目标：

评估产品质量，常用的是千行代码缺陷率，以下是查到的一些业界的千行代码缺陷率数据。典型的统计表明，在开发阶段，平均50~60个，交付后 15~18个;微软内部测试的产品10-20个，正式发布产品0.5个;某外包公司，A级≤ 0.5个，B级≤1个，C级≤5个;航天飞机的软件，0个/50万行。缺陷率做到平均水平的1/10是很少见的，而如果10倍以上，产品可能永远也不会完工。

跟性能瓶颈一样，80%的错误往往出现在20%的代码中。大部分错误都是低级错误，比如，对需求或设计的误解、书写错误、赋值语句、边界错误或循环错误。大多数错误是容易改正的。另外，warning是很多错误的根源，所以工程里要禁止warning。

发现错误:

主要通过检查和测试。检查包括：需求检查、设计检查、代码详查，测试包括：单元测试、集成测试、系统测试等。

有统计数据表明：单元测试的平均错误检出率是25%，集成测试35%，小规模Beta测试35%，系统测试45%。而对设计和代码进行详查的错误检出率分别是55%和60%。

检查：

阅读代码要比测试平均每小时多发现80%多的错误，代码检查和测试所获得的收效之比为8:1。这是因为，错误越早发现，解决成本越低。

检查方法：协同编程，详查需求、设计、代码。不仅仅是检查，要提前思考怎么做?带着思考检查。

最后还是得有足够的资金。