一、需求整理方面

　　完整详尽的需求规格说明书会有以下好处：

　　1、便于与客户沟通

　　尽可能地以书面形式将客户对产品的功能需求、性能指标、技术参数记录下来，在开发之前若需与客户沟通，便可以产品需求规格说明书为依据与客户沟通，看是否存在认识上和理解上的差异。必要时可请客户签字以表确认。

　　例如：赵教授相关项目是一个典型的例子，启动之初，需求上不太明确，我们应敦促其写好需求文档，然后我们和其讨论具体需求规格。或者引导客户将需求逐渐表达出来，我们将规格需求整理好，发至客户公司，让其确认，这样更方便促进对项目的理解，避免产生偏差，造成不必要的时间上的浪费。

　　2、便于开发团队内部使用

　　一个描述详细的产品性能指标说明书，便于开发人员和项目负责人对产品各项功能的认识达到统一，利于开发人员尽快理解产品的各项功能、性能，尽快开始展开工作，提高工作效率，也便于其他相关产品开发人员理解产品的性能。

　　例如：我们的钥匙产品，功能虽然不是特别复杂，但是初接触钥匙时，可能会对各种钥匙的功能、特性、用途以及名称产生疑惑，如果事先有各种钥匙各项功能以及用途的详细说明，以及各种钥匙之间都有哪些联系的详细说明，可能更便于开发人员对产品的理解，尽快开始相关工作。

　　3、便于后期产品的测试和形成说明书

　　有了产品需求说明书，也就有了产品的各项功能指标，略加修改，就可以成为指导测试人员进行测试各项功能、性能的依据。也可以略加修改成为产品的说明书，便于客户阅读。

　　二、开发与文档

　　1、文档的完整性

　　文档描述尽量做到完整、充分、易于理解，对于协议文档最好每个协议命令有格式方面的描述，也有示例，便于开发人员理解，开发人员拿到文档之后，基本对文档所描述的产品或协议理解了90%以上，这样就能够花尽量少的时间，就达到理解的目的。完备、描述清晰的文档，也便于后期测试产品时核查，后期升级同类产品时也能够用于参考。

　　2、软件与文档版本的一致性

　　开发人员手中的技术文档不是最新的技术文档，或者各个技术人员手中的技术文档版本不同，内容略有差异，这时开发人员对于所要开发产品的性能指标或技术细节理解可能就会产生偏差，如果技术文档中描述的技术协议不同，就会造成开发人员合作开发同类产品时，某些技术点对接不成功，经反复沟通，对照代码与文档，最后才发现不一致的地方。这样就会造成工作效率的下降。

　　这个问题在我们的开发过程中有时也会存在，例如：GPRS产品的通讯协议与软件程序不一致，开发期间，有时会以产品功能为准，这时就应该修改技术协议，否则，后期其他开发人员用到此产品和协议时，会非常费解，因为技术协议和产品运行结果的实际情况不一致。应该以何为准呢？虽然不会造成大的后果，但对后期的类似新产品开发、前后台对接都会造成一些影响，影响进度和效率。

　　建议安装使用版本控制软件，并且养成及时更新文档的好习惯。

　　3、代码的重查

　　随着开发产品的增多，开发经验的积累，开发人员的水平也逐渐提高了，有时候回头看自己以前写的代码，可能会发现有很多可以优化的地方，可以提高代码的效率节省资源，另外，也可能会发现代码中潜在的bug，一直没有发现，这个bug可能会在某种情况下触发，造成产品出现问题。代码重查就是要提前发现程序中潜在的问题，及早修正。

　　建议把代码重查作为我们开发人员的一个好习惯，逐渐养成。

　　三、建立全面完整的测试机制

　　在产品出厂之前，进行全面而细致的测试非常重要，不论我们的硬件产品还是软件产品。否则到了客户那里出现这样那样的问题，会造成坏的影响。

　　我们现在基本是每人负责一个产品，此时就需要将产品性能、技术参数、各个功能点罗列齐全，客户有新的功能需求提出来，我们就把新增加的功能点添加到需求文档中，同时添加到测试文档中。如果对产品的测试流程有影响，也要对测试流程进行相应的调整，便于后期测试人员对产品进行全面的测试。

　　测试方面可能会存在的问题，一般是开发人员或客户发现某一个问题之后，反馈给研发部，开发人员将产品问题修改之后，提交给测试人员测试这一功能点，若这一功能点不再出现这一问题，即大功告成。其实开发人员修改此功能之后，可能会影响其他功能，应将产品交给测试人员进行全面测试。测试人员将整体功能按照测试流程全部重新测试一遍，以保证其他功能没有受到影响。