抱着一名对产品新接触的新人来说，产品需求这些词语对我来说并不是陌生的，但是对于真正的产品我没有接触过。
首先 我先说一点题外话：
刚开始接触简书没有多久，我发现好多人的简书都写的非常漂亮，所以我就想尝试一下；
第一次文章，可能不是很好，由于我是断网写的，连上网络后就立马发布了自己的文章，发布了之后发现文章只有one，我就哭了。
犹豫了好久，发着呆于是又打开电脑。
我不相信我不能再写一遍，毕竟亲身经历，连接网络再一次坐了好几个小时，功夫不负有心人终于完成了初稿。
one
我是从实施运维转岗为测试然后决定要做产品经理，转测试岗主要是由于公司的调剂。但是做产品经理是我主动决定的。
刚开始做测试我是很投机的，怎么来说呢？我是一直好奇在开发之前到底一款软件为什么要定义成这种糟糕的样子呢？因为作为一个实施运维人员来说，客户每次都给我们打电话抱怨这个功能不好使，那个功能不好用。我们这些后勤人员做起工作来真的很难为。至于解决的办法呢，我估计每个做运维的都知道how？
转测试后我就接触了一个新的项目测试，测试的前辈告诉我，你就按照现在仅仅开发的系统做测试，主要测试每一个功能点是否可用，我就傻傻的把系统从头到尾点击了一遍。但是当我点完一遍系统，我看一遍我的系统，我发现我的bug问题单好多都是需求，而不是bug。我思前想后了一下发现：我测试的系统没有一个标准。我很纳闷这测试的工作好难开展呀。
沉思了半天后我就仔仔细细的请教了一下之前的前辈，他告诉我测试的标准是产品需求的需求文档和开发的开发文档作为标准，（我估计现在好多测试应该也是一样，要么没有需求文档要么没有开发文档。）当然我就开始找到相关需求产品人员寻到产品需求文档，当我打开文档，发现需求是模糊的，此时我就稍微懂得因果所以然。
two
由于项目的紧急，我被分派出差支持项目，其中还有开发、需求、项目经理等人。刚一开始我们就开了临时会议，在会议上开发毫不客气的就针对需求文档以及原型发起了战争：
1、需求描述的模糊，不清楚，看着需求文档不是很了解客户的意愿，也不是很符合整个项目的逻辑；
2、在原型上开发指出了这个不能实现，那个不能实现。以至于需求工程师都有点哑口无言了。
3、最后一点开发指出的这些数据是从哪里来的？为什么要这么做？ 。。。一个都没有答出来。如果一个需求连这个都答不上来，如何让系统能完整的呈现在客户眼前。
就这样这个会议很不开心的结束了。后面的需求工程师又再一次的和客户沟通了需求，和开发商量对策，此间我承载着客户、开发、需求的配合。终于再多次的磨合中，完成了项目的上线。
。。当然在项目的中间我无数次的回归测试，甚至有时候我都想吐了。
但是最终还是坚持了下来。
three
从那之后，我就给自己计划了目标。产品就是一门艺术品，精致的可以被展览。我愿意去创造这个艺术品，即使再辛苦，我也要为的目标划上一个完美的句号。
我现在刚从事产品，现在不能对产品下太多的定义和话语。但是我会一步一步学习，坚持不懈是我前进的动力，态度决定一切。我永远相信自己。
小故事结束，我是新手，同时希望和我一样是新手的朋友们能坚持自己。
网友评论