在GRSX项目组的这段时间，通过与开发和产品的接触发现，大部分问题是出在了开发这里，总结了如下几点体会：

1.需求xmind有描述的，开发理解的不充分或者没看到关键信息(eg:五年随机，一年重点的时间段问题)

2.改bug的时候只关注当前问题中的描述，对其他地方的影响考虑不充分(eg:随机抽查解封后，不清空操作人员等信息，但是需要在列表中不显示相关信息)，或与需求描述不清晰有关

3.这段时间我的角色好像成为了开发兼测试，在测试系统的时候，最希望得到的反应是“咦~我当时怎么没发现”，却不希望听到的是“怎么跟当时的需求不一样了呢、又变！”。之所以会出现我所不希望处出现的结果，究其原因，不外乎当时产品方发出的需求信息与接收方接收到不一致，再深入分析，或许是在分析需求的时候理解不够全面，还有一种情况就是在开发理解需求后，给产品的反馈 产品以为开发体会到了需求意图。 针对这些问题，我的建议是：双方在进行需求分析交流的时候，要明确主要内容，并各自得到详尽的反馈；反馈信息的时候要用一种共性的语言描述，不要只站在各自角色的角度理解相同名称的信息。 总结一点就是：要正确传达和接收需求。

4.在测试别人写的代码的过程中，时长会遇到一些不理解：“你这是bug吗、跟产品确认了吗，你是看的哪的需求测的(言外之意:要按着需求测，不要测需求之外的功能)”。这些或许反映的是所有开发的共性问题吧，不希望自己写的代码被别人挑出毛病(坚信自己写的肯定是对的)，有一种自己赤身裸体被别人指点的意思。所以就有了：开发骂测试(“都不理解需求就在那测”、“肯定又是自己改数据了”、“操作有问题吧，不可能会是这样”)，开发骂产品（“又再变需求”、“开发之前不是这样说的啊”、“怎么就没有一个详细的需求呢”）。作为一个开发，我想对所有开发者说一句，不但要精通技术更要精通业务。借用一个哲人说过的话“我希望我们团队的每一位都能够学习技术，钻研业务”。 在这个过程中，虽然听到了不一样的声音，但是我还是坚持了我的原则，对我们开发出来的产品负责。还有一句就是“一个好的开发者，不需要对着需求，一字一句的开发，要真正的理解客户想要的是什么” 用邓先生的话总结一句，就是“实事求是”！