一、需求整理方面

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

　　1、便于与客户沟通

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

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

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

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

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

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

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

　　二、开发与文档

　　1、文档的完整性

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

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

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

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

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

　　3、代码的重查

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

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

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

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

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

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

　　例如：湖南的设备曾出现的问题，有功总不等于尖峰平谷之和。以前是相等的。后来有其它问题修改之后，代码上可能动到了这一部分，但是由于客户要求匆忙，没有时间让测试人员进行全面的测试，以至于后来遗留了这个问题，当时是由后台软件弥补了这个问题。

　　测试产品应该尽量形成常态化和规范化，不久前见到有一套“客户”编写的短信设备测试流程图，我们更应该对每个产品建立这样一套的流程图，便于测试人员测试，也便于新员工的快速掌握。否则测试步骤不同可能就得不到正确的结果。这样的步骤也可以后期形成用户的操作说明书。

　　如果没有完整且全面的测试机制，产品的性能可能完全依赖于某个开发人员的责任心和技术水平。产品的性能就会因技术人员的状态变化受到太大的影响。有完整且全面的测试机制的话，就可以尽早发现问题，解决问题，尽量避免在客户使用时产生问题。

　　四、建立常见问题集

　　随着产品的生产、使用，我们都尽力保证产品不出现问题，但再完善的测试条件和测试手段可能还是与用户的现实环境有差别，产品出现问题也是在所难免。可能是软件的问题，或者某一个硬件的问题，有时候这些问题存在普遍性，我们可以更改，有时候一些问题比较偶然，不太常见。另外，有时候我们内部测试人员分工可能不同。不同的测试人员测试不同种类的产品，对自己负责的产品熟悉，别人负责的产品不熟悉，当因为某测试人员另有工作安排时，他负责的产品别人可能不太熟悉，遇到问题不知该如何解决。

　　有时候某些问题解决不了，还要麻烦开发人员亲自解决。

　　如果我们养成了解决了某类问题，将此类问题，汇集起来的好习惯，积少成多，分门别类的总结下来，某类产品常见的问题和解决方法就能够汇集成册，能够方便测试维修人员进行测试和维修，这样也能适当减轻开发人员的维修任务，并且提高了效率，有了积累。

　　例如：不久前测试短信设备，测试人员一直说短信设备有问题，发某个命令后，短信设备会死机。但在我们研发部这里一直测不出所说的问题，后来发现是跟设备电压有关，使用备用电池，并且电压低于 6.8V时，会出现死机的问题，而在研发部一直接的交流电，所以没有这个问题。但是这个事情是后来才听其他测试人员说才知道的，此前陈杰和我都不知道有此问题，双方都测了好多遍，在测试该短信设备时，就花了一些本不该花的时间，感觉有些冤枉。如果此前有问题集，当中提到了这个问题，我想我们就不会再花费时间在上面了。

　　五、其他建议

　　1、工作的计划性

　　开发工作需协调有序进行，不因某些原因（如某个开发人员忙于其他事情）而耽搁整个开发进程。

　　某一段时间内，各开发人员将该时间段内的工作计划提交总工，总工可将需协调合作的项目协调好，对时间进行统筹安排。最好不要看到一件干一件，最后时间可能会拉得过长。

　　2、项目的总结

　　建立事后分析报告：在某一个项目或产品生产发布之后，对整个需求、研发、测试、生产、销售过程的分析描述，分析各个过程中遇到的问题，解决的过程，以及该产品有哪些优点、闪光点，以总结经验，优点以后可以继续推广使用，遇到的困难以及产品存在的缺陷，在以后尽量弥补和避免，以期以后可以做得更好。

　　最后

　　每遇到一个问题，我们都应当庆幸，因为现在公司规模还小，现在遇到这个问题，我们还有时间和精力去审视这个问题出现的原因，并且避免以后再出现类似的问题。以后随着公司规模扩大，市场扩大，再出现某些问题，可能就会造成极大的恶劣影响。所以现在每次遇到问题时，无论是产品缺陷还是其他非技术性问题，我觉得这都是好事，我们目前就是要遇到问题，并解决问题，逐步建立起机制，避免类似问题的发生，逐步完善并成长。

　　公司已经有着自己的运行机制和方法，可能需要不断的完善和进步，以上几点建议只是我个人的建议和看法，希望能对我们产品的开发和生产有益处，同时希望能起到抛砖引玉的作用，让我们大家能进行思考，完善自我，让我们的事业蒸蒸日上。