最近app开发已经接近尾声了，为了赶进度准备开始一边测试一边开发，公司没有专门的测试人员，只好有我这个产品经理来做简单的黑盒测试，没有想到测试时发现了很多问题，我一边做记录一边通知开发人员修改，但是，更多的时候我在思考为什么会出现这么多问题。从测试出来的问题来看，大概分为这么几类：1.自己工作失职在一些功能上没有考虑周全；2.开发过程中需求文档更新后开发人员并没有及时注意到；3.开发人员自己的失误。关于第三点无需多言，每个人都有失误犯错的时候，你发现这样的BUG，开发人员很乐意去修改的。重点我想讲讲前两点问题，由于前两种情况出现BUG的时候，开发人员修改BUG时内心会出现逆反心理，他们会义不容辞的反驳你为啥一开始都没有考虑周全，为啥更新了没有人及时通知我，导致沟通的成本增加从而影响开发进度。就这两点我想从我自身产品经理的角度谈谈。
1.需求文档没有考虑周全
从本质上来说需求文档不可能一次性考虑周全，只能做到尽可能周全。这也是我在这次测试中不断反思自己的地方，这个地方问什么没有考虑到？这个异常情况为什么没有考虑进去？等等类似的问题，而且在测试过程中一些相对来说比较复杂的业务逻辑自己在文档中并没有表达的很清楚。基于以上这些考虑，我总结出来文档的两个问题：“全”和“准”。关于“全”无外乎就是自己不细心和缺乏经验。后者只能在不断的工作中去总结吸取教训，而前者是可以通过结构化的思维和方法来尽量避免的，我想到的方法是通过页面条件来排除，而另外还需要我自己去总结一套适合自己的结构化的文档出来，比如：最常见的输入和显示，输入内容的限制，输入为空时的异常情况，显示内容的不同状态等等，我想这些是需要我慢慢去总结的，更重要的是我要在以后的工作的去这样思考问题，慢慢的建立起自己结构化的思维方式。
2.开发过程中需求文档更新后开发人员没有注意。
这个是团队之间配合的问题，一方面需要更好的工作流程来制约，而另一方面更重要的是团队沟通的问题。先来说说前者，“工作流程”这样的制约因团队而不同，不是所有的团队都会按照的流程来走的，尤其是对于一些小团队来说，为了提高工作效率和开发进度，会不自然的省略掉一些流程，我想是不是可以考虑把“工作流程”这样一条线，改成一个点，团队中的重要人去控制这样的点，即使省略了部分流程但是每个“点”还是不能被省略点，但是即使这样最后还是需要团队人员的磨合，其实关于这一点归根到底还是团队人员相互磨合相互“妥协”的工程，好产品背后都有一个好团队，但是团队和产品一样并不是一开始都很完美的，也是需要不断的迭代更新才能慢慢趋于完美。第二个就是团队沟通的问题，测试中我发现一个特别的地方，Android没有遇到这样的bug而ios遇到遇到了，仔细回想起来Android的开发人员跟我沟通了这样的问题而ios没有，由于是小团队一般情况下Android开发都会去告诉ios该怎么实现，但是总是有遗漏的地方，所以以后不管是什么问题，我都会记录下来然后及时更新自己的需求文档，并通知他们所有人。其实这是自己工作的失职，我要坚持以后遇到什么样的问题，我都要及时更新自己的文档，并及时通知所以开发人员。
今天看了一个视频——三十天坚持做一件事情。我决定坚持写点东西，让自己更多的时候去思考，只有思考才能写出东西。写东西不重要，重要的是思考的过程。
