产品经理一个月以来的随笔

     经过了四个多月的折腾，我终于清楚的找到了自己要走的道路——做产品。面试的第一家单位是导师推荐的，其实我都不知道为什么会被选中，因为本来当时自己只是想找份实习而已，开始还想学技术来着。9月份，入职一家小公司开始了我的产品之路……

     第一个项目：英赛运动理疗

     其实在做这个之前，公司已经找到了外包，给出了一个大致的需求，我要做的就是把师傅写的需求和外包写的需求给整合到一起。于是我就认真把两份文档都仔细看了，然后开始拼接，在我看来把主要的内容拼起来应该就差不多了，因为核心功能毕竟没有多少。而且我觉得有些功能可有可无，于是我就很主观的删掉了部分功能。当交个师傅的时候，发现师傅并不满意，尤其是他写的很多需求被我删掉了，于是我又询问了为什么要有这些功能，最终被说服然后把这些又加进去了。

     其实这是我第一次列需求列表，我都不知道用户人群是谁，这个APP的核心功能是什么，要达到什么效果。就凭着自己的理解然后开始天马行空了，其实这样也没什么不对，因为产品都要经历这样的一个阶段，而且产品经理要敢想。但是话说回来，敢想更要敢于否定自己的天马行空，因为现实是很残酷的，你会发现你的很多实际中的情况并不是你想的那么简单。

     于是我开始去参考市面上有的APP，运动类的比如：运动家、微运动、微健身、健身宝典、健身专家等，经过不断的对比和筛选，终于找到了类似的我们需求的，但是当时我并不知道这是竞品分析，当然也没有输出竞品分析文档，因为公司来的比较实际，觉得可以用就可以了，根本不需要这么高大上的分析和比对。于是我连最基本的竞品分析都没能写，就拿着手机上安装的一堆APP去跟师傅和boss去讲大体要做什么样子了。现在想想，其实自己分析了APP还是应该输出一个竞品分析的文档的。

       第二件事情：测试乐享生活APP

      这个工作耗费了我将近两周的时间，天天都是在记录各种测出的bug和问题，然后用EXCEL表格列出来，给开发人员看。我以为用文字描述出来就可以了，其实后来事实证明并不是这样的，你想的、你写的、你想表达的和程序员看到的、想到的、理解的很多时候并不是一样的。所以这也给我好好的上了一课，在跟别人交流的时候简单的文字描述并不能准确的传递你要表达的意思，你要面对面的跟别人交流，把自己的意思表达清楚。尤其是不要随便就跟开发说参考原型图，一定要准、详细、到位，让开发明白你的意思。如果一个bug可以复现，一定要把自己测试用的环境、账号、操作步骤都告诉开发，好让他明白这个bug是什么。

     开会总结；乐享生活一期项目结束总结

乐享生活会议记录
9/21/2015
1.原型图旁注明功能详细说明
2.visio（线框图画图工具）
3.工作分配：相似度高的模块分配给同一个人完成
4.提高代码规范性
5.不要有太强的主观意识，项目的大方向要跟着原型图走
6.项目需求优先级排序：要先做需最近交付的需求内容
7.对需求不清楚要多沟通
8.对框架上的功能加注释
9.考虑问题要全面，多加判断
10.框架的抽取应在定原型图时确定好
11.代码生成器：生成常规代码，自己添加逻辑
12.前台与后台结合测试。
13.测试用例按角色来安排顺序
14.测试数据要饱满、真实
15.考虑交互跳转，网络状况（网络状况不好、网络类型转换）、内存等对测试的影响
16.先写详细的需求文档再做原型图
17.对用户的需求交谈要宽泛些，界面细节不要做太多承诺
android：
1.android开发在不确定需求的时候，按照原型图来做
2.加注释
3.框架多多完善，不要局限
产品：
1.需求文档（正式需求文档）、原型图、测试计划（系统功能）、UI测试（按照原型图）、buglist
2.测试用户在测试时分角色
3.认真看原型图、严格按照原型图
4.交互跳转
5.测试建议（网络、内存等测试条件）
测试：
1.手动单元测试
2.代码审查
3.代码重构