产品实现的功能是产品价值的体现形式。功能实现是基础。功能没有实现，其他方面做得再好也没有意义。那么，如何保证实现的功能覆盖了需求呢？

本文主要内容如下：

• 如何做到：实现的功能覆盖了需求。

• 仅仅实现了功能有什么问题。

要实现功能覆盖需求，需要团队不同角色的共同努力。如下图所示：

（一）开发人员自测

开发人员自测指：开发人员开发完后，自己测试功能是否可以全部实现。如果产品经理有出验收标准，则需要对着标准跑一遍。对前端来说，自测的内容主要是：功能，UI交互和浏览器兼容性。

开发自测很重要。一方面，程序员自测，能更早的发现问题。越早发现问题，修复问题花的成本越低。另一方面，开发人员自测是对自己代码质量负责，也是专业素质的体现。没自测就提交测试，也浪费QA的时间。

建议将自测这块体现到工作流工具中。如果你用的是CODING，可配置任务流转规则：状态流转到测试中时，一定要填写自测的内容：

QA会对功能做全面深入的测试：不仅测试正常的流程功能，还会测试异常流程，异常值，边界值等。因此，QA测试是对功能实现检查中很重要的一环。

专业的QA都会设计测试用例。测试用例完整的覆盖需求。QA测试通过，就是要通过所有的测试用例。

当然，QA测试也存在局限性：如果开发过程中引入的缺陷不在当前测试功能的范围内，QA很有可能发现不了。要缓解这种局限性，有2个建议：

• 开发在提交测试时，告知QA可能会影响的其他功能。

• QA不管测试什么功能，测试完成后，都要再跑一遍产品所有模块最核心的测试用例。

  
  

  
  

（三）产品经理验收

产品经理验收的是功能。产品经理对功能更敏感，容易发现漏做或实现的不对的功能。

（四）设计师验收

设计师验收的是UI和交互。设计师有“像素眼”：能发现常人发现不了的UI问题。

对于短期项目，仅仅实现功是没问题的。但现实中，很多是长期维护的项目。随着时间的推移，会加很多功能，也会改很多功能。项目会变得越来越大，越来越复杂。只管实现，不管代码的维护性。会加速的出现如下的问题：

• 增加新功能，改bug越来越难。花的时间也越来越长。

• 改了这个bug，出现其他bug。

因此，对于长期项目，我们不仅要实现功能，还要注重代码的可维护性。我在后面的文章中会做详细介绍。