对一款OA系统来说，除了从源头入手，做好模块化架构外，还可以通过哪些层面确保OA系统的高质量，给用户打造良好的体验呢？本文将针对这一问题做仔细展开，希望对你有帮助。

大家在提到质量的时候大多会想到一些形容词，如：好、坏、一般，用这些词来指定某个产品是否好用、是否耐久、是否有缺陷。所以大多数人一提到质量，总难免想到产品缺陷，因此，缺陷少就自然而然地成为了高质量的代名词，软件产品也不例外。那么软件缺陷少就能代表软件产品质量好吗？

“这是肯定的”。也许在10年前甚至更早的时候用户会这样回答。

但是随着信息化建设不断推进，用户的信息化水平也有了很大的提高，在和用户沟通的过程中，出现最多的反而是“XX功能真不好用”、“首页加载这么慢”、“这个界面真不好看”、“这个功能不是我们要的”……这类偏用户体验的反馈。

美国著名质量管理专家J.M.Juran博士从客户的角度出发，提出了产品质量就是产品的适用性，即产品在使用时能成功地满足用户需要的程度。由此可见，软件缺陷少不再能够代表软件的质量高，而是仅仅成为了衡量软件质量的其中一项指标。

“好看、好用、bug少、能解决实际问题”是用户对软件高质量的最直接反馈。但是如何才能保证软件的高质量呢？

从开发的角度来看，软件需要达到高内聚、低耦合、代码简洁易懂。称之为软件的设计质量，具有外部不可见性，“高内聚低耦合”满足软件易于扩展、易于复用的要求，“代码简洁易懂”满足软件易于维护的要求。易于扩展和复用能够保证快速响应用户新需求，易于维护能够保证快速响应用户需求的变更。

协同办公系统（本文简称OA）基于公司通用开发平台、采用模块化架构思想建设而成。模块化架构思想从根本上保证了OA系统达到“高内聚低耦合”的建设目标，通用开发平台从基础层面确保了软件的产品质量。除此之外，项目组还重点从以下几个方面保证OA系统的高质量。

一、需求分析阶段

有这样一句话：“风险躲在需求的迷雾之后”。充分体现了需求分析的重要性，需求分析工作做得到位，就能为开发出优秀的产品奠定良好的基础，反之则有可能导致出现潜在的质量问题和业务价值的丧失。为了拨开“需求迷雾”，项目组在需求分析阶段做了大量的工作。

• 要求需求分析人员在与客户沟通的过程中避免使用计算机专业术语，要结合OA系统特性总结行业术语并在和客户的沟通交流中逐步学习客户“语言”。这样可以最大程度打破与客户之间的沟通障碍，为客户需求的收集和理解提供便利。
• 除却常用的通知公告、新闻、工作流、人力资源等通用模块，OA系统还具有强大的包容性，可以最大限度的容纳客户个性化需求，因此要求需求分析人员能更好地理解客户的业务，必要时采用驻场等方式观察客户实际工作流程。如系统开发过程中为满足客户对督查督办业务的需求，项目组派专人负责直接与客户督查室工作人员保持密切的联系，及时收集分析用户需求并反馈给开发人员。
• 即使是通用模块，在面对大量客户的时候也难免会遇到个性化的要求，对此项目组在保证系统稳定的前提下积极响应并尽量满足用户。极力把OA系统打造成一款适用于客户、让客户满意的产品。

二、实现阶段

软件实现阶段的主要活动包含：详细设计、编码、测试，是软件项目过程中工作量最大、历时最长、细节最多的阶段。如果保证实现阶段各项工作的开展，是确保产品高质量的重中之重。在实现阶段，项目组主要采用以下原则做到质量保证。

• 对于简单需求，关注重点集中在编码和测试，尽量弱化详细设计，避免耗费大量时间做无用功。
• 需要做的详细设计也把侧重点放在领域模型设计、业务流程设计、数据库设计、核心算法设计，并在需求变更的时候优先调整详细设计避免设计与实现脱节。
• 代码规范基于阿里巴巴java编码规范结合具体情况进行调整，使之更符合项目组的要求，比如：要求类、方法、变量等的命名严格使用能代表实际意义的英文或缩写；简化对代码注释的要求，只有复杂的算法逻辑才要求必须添加注释。
• 进行不定期code review，代码走查人员不局限于固定的项目成员，而是采用互查的方式进行，通过这种方式可以让项目组成员学会阅读代码，发现好的编码思想和算法逻辑，也能发现别人代码中的不足以给自己警示，最终达到全员开发能力的提升。
• 要求开发人员对自己负责的功能做到单元测试，并根据业务的变化及时调整测试用例，也为代码重构工作的开展提供保障。
• 业务需求的变更、code review的结果，都可能需要变更代码，项目组以此作为代码重构工作的触发点。重构不是简简单单地增加代码或删除代码，需要在对业务理解的基础上进行恰如其分的代码调整，而代码重构也是开发人员对业务需求加深理解的一个过程。

三、运维阶段

关于扁鹊有一个小故事：

魏文王曾经向扁鹊求助：“你们家三兄弟都擅长医术，那么谁的医术最高明呢？”

扁鹊回答：“大哥的医术最好，二哥的医术稍微差一点，而我的医术最差。”

魏文王不解：“那为什么只有你闻名天下呢？”

扁鹊给的解释是：

“大哥治病是在病人发病以前，这时候病人都不知道自己有病，大哥下药就把病情扼杀在萌芽中，即使他的医术不被世人所理解，但在我们家，都认为他的医术很高明；

我的二哥治病是在病情刚刚显现的时候，这个时候病人的病情还不是很严重，病人也没有什么痛苦，二哥一剂药下去就可以药到病除，所以很多人都认为二哥只是治小病很灵；

而我治病，是在病情已经很严重的时候，病人已经受到了很多的病痛折磨。所以他们看到我用针放血、或用毒药以毒攻毒、或者动大手术，让病情很快痊愈。所以病人都认为我的医术非常高明，只有我闻名天下。”

运维阶段的质量问题往往是设计、开发阶段积累造成的，如果真的在运维阶段出现了要动大手术的情况，那么形势就真的不容乐观了，动的好则如扁鹊一样“名扬天下”，动不好可能就是“亡羊补牢，为时已晚”了。所以项目组在实现阶段加强对代码质量的严格把控是很有必要的。

为了把好最后一道关，项目组应非常重视系统的线上运行状态，通过各种监控和预警措施提前发现问题并将其扼杀在萌芽中。

虽然项目组在质量管理方面做了很多准备和努力，但是对质量的把控仍然不能称之为完美，还需要项目组把更多的精力放在质量管理上，需要公司提供必要的支持，需要所有人参与到质量管理工作中。我们的目标：实现全面质量管理。

何为全面质量管理，答：就是一个组织以质量为中心，以全员参与为基础，目的在于通过让客户满意和本组织所有成员及社会受益而达到长期成功的管理途径。

本文由 @花田ikdo 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议