初次了解产品

  　  产品经理在不懂的人的眼里不明白是做什么的，或者说经理级别的，好高大上，其实你要是跟别人说你是做app的，那么许多人就了解了。

　　其实通过上述的一个小例子来说，在产品的角度上讲，如果你诉说的对象是公司里其他部门的人，比如开发，测试等等，如果不说清问题的本质的话，是很难让工作继续下去的，因为你首先要一针见血的表述出你想让开发做的需求，或者你跟测试或者交互交代清楚各个功能模块的功能设计，而并不是模棱两可的去说你的需求。

　　产品周期，产品周期一般分为四个时段，探索期、成长期、成熟期、衰退期。而在探索期到成长期之间版本迭代是非常频繁的，在这里产品不要局限于本次的迭代，而应该在本次迭代成功后，即即将上线的时期，就要筹划下一次版本迭代的内容和时间，并通知各个相关部门。在产品的设计和上线后，一定不要考虑近期的效益，因为产品是一个循序渐进的东西，在你设计时，并不一定要着急去做某个模块的设计或者需求分析，而是从一个大的层面考虑为什么要做这个产品，做这个能干什么，后期如果做了怎么去运营，如果确定好了以后，也不要着急的去做具体的设计工作，而是熟悉你要做这个产品核心业务的业务流程是个什么样子的，它的业务逻辑是什么样子的，在熟悉后要详细的对用户做需求分析，在这里可以运用“五个为什么”的方法去询问，并且用黑箱子的方法去引导用户说出他的核心需求并整理出一份需求文档，（提一句这个需求文档所包含的需求不只是包括使用人群，比如还有老板、客户、运营、销售等等方面的需求综合在一起），并且分析出1-3个核心需求，因为你在做产品的时候不会一下做许多需求，而是围绕自己的核心需求去做功能，（提一句，再最后确认好需求后，再将需求产品化，并且应该讲每个核心需求用官方语言概括出来，这个是后话啦），核心功能确定好以后，要做的就是梳理核心业务流程，画流程图和脑图写需求文档和画原型，当然别忘了在这之前，要好好的跟开发和设计师以及测试好好的进行沟通，告诉他们你是怎么想的，当然啦，你也可以开一个需求分析会，将自己整理的一些想法或者一些草图给开发设计以及测试看，这时要好好梳理业务流程和需求的取舍，因为在好的想法遇到现实也是骨感的，因为得考虑技术的可实施性，以及在交互时会不会产生不必要的麻烦或者对用户造成不必要的操作上的重复或者复杂。

　　当需求分析会沟通完成后，就要确定需求文档和原型设计，这时开发开始进行开发以及交互设计也在进行，产品要做的就是跟进项目的进展，并且不断地在用户或者老板之间游说，因为会时不时的有新的需求提出来，有的可能天马行空，不切实际，但是有的却是可以实现的，这时还是得及时跟开发和设计及时沟通，并且及时更新需求文档，方式有很多种，可以直接过去说或者及时性邮件或者有一个固定平台，固定时间进行内容更新。（当然这都是我个人想的哈哈哈），后面就是测试同学们了，这里产品应该没什么特别要跟进的，因为都是在挑bug，除非是特别触动到业务逻辑层次上再去干预。

　　后面就是产品上线等等一些事情，其实还得写好多啊，哈哈，比如内测版本先发布一个，范围（如果版本是从0到1），那么可以让公司的人员进行体验，并且及时了解产品的不足和bug。并且个人觉得还是将这些数据化更合适一些，因为数据大多数的时候更让人信服，这时应该再一次开一次会议，或者说产品部门自行召开，在联合其他部门召开，（这也是自己想的，因为产品是一切发起的源头，也应该最明白产品的功能和核心的业务逻辑），等梳理清楚后，在召开部门与部门之间的会议，进行版本的迭代，最后上线。（因为在上线的事情还不是特别的了解和理解，所以有很多情况考虑不到，应该多思考）

　　上线后就是分析产品的有点与不足，并且培养种子用户，增加用户使用量。另外在上线的版本上，依靠设定的诸如数据埋点获得用户真实数据，或者用户对某个功能模块在评论区的评论等等，来作为下一个版本更新迭代的重要依据，（其实在新产品上线之前，其实产品经理本身就应该结合市场和已确定好的特定用户进行新一轮的产品迭代的工作的开展，另外要考虑潜在用户的用户行为，为产品用户数量的增加埋下伏笔，当然更新迭代后没有促进用户数量的有效增加，可以考虑各方面因素，有选择的去掉某个功能）下一个版本上怎么增加用户基数。（具体操作可以根据各方面反映上来的需求，通过双钻设计进行产品的更新迭代）

　　好啦写了这么多，其实并没有很工整的去写，只是随笔记一下，让自己复习复习这两天的学的东西。个人观点，欢迎指正。。。。（小白一个）