入行产品这一年我的心得体会

　　产品新人想要快速地成长，不仅需要时间和经验的积累，还需要主动地沉淀，形成自己得框架。
　　入产品坑已1年有余，是该有写一点东西的必要了。真的该有写一点东西的必要了（借用一下鲁迅先生的手法）在不断的practice后，总结下来，大致总是以下这4个方面的事情：
　　一、需求管理
　　据我这1年多近2年的临床经验，虽说资历不够，但不多不少，还学到点东西
　　相信所有的产品新人刚入行时，接触的最多的行业概念都是需求吧，当然我也不例外，也是从需求开始做起，到现在带小组做项目，自己经手产品从0开始到上线的方方面面。
　　1。需求收集
　　其实一开始上司大多会让你去跟进一些功能优化的需求，因为这只需要在了解业务的基础上，对功能优化点进行跟进即可，几乎没有难度。这阶段还不知道怎么去挖掘需求。
　　当你跟需求有一段时间后，你的疑问就来了，为什么要这样优化？是谁提的要优化？做了这个优化对什么东西造成什么影响也就是产品人常常挂在嘴边的需求分析的5W1H原则了。
　　跨过了这个阶段后，就到了收集需求阶段。需求收集无外乎3个来源，3个途径：
　　需求来源
　　公司相关业务部门（市场、运营、销售、客服等）
　　用户客户
　　产品经理老板创造需求（这需要产品经理本身具备很高的产品素质）
　　PS：乔老爷子曾经说过：Peopledon’tknowwhattheywantuntilyoushowittothem（在你把东西拿出来之前，用户根本不知道想要什么）。前人留话了，有时候，我们需要去创造需求。但世界只有一个乔布斯，因此我们还是脚踏实地，仰望大佬吧
　　收集方式
　　用户调研反馈：问卷调查、用户访谈、信息采集（包括工作人员在内）
　　来自boss的idea（boss根据他对市场的敏锐度做出的决策）
　　产品数据分析：功能数据、市场数据、竞品分析数据
　　产品从无到有阶段，需求来源多半是由产品经理老板用数据分析的方式获得需求。项目落地实施阶段，需求来源大多是从用户调研反馈得之。项目运行数月后，用户反馈、数据分析则变成了主要的收集方式。
　　2。需求分析
　　需求分析，用哲学上的一句经典名言来说：从哪里来？要到哪里去？这句话用在需求分析上再合适不过。延伸一下，就是需求分析的5W1H原则了：
　　what：需求是什么？
　　who：谁提出来的？
　　why：为什么要做这个需求？
　　where：什么场景下有这个需求？
　　when：该场景下的什么时候需要用到这个需求？
　　how：怎么做这个需求？
　　有时候，用户的需求并不会很直接的告诉你。好比女生在和男生交往的过程中，某天拿着美妆博主的试色图片和对方说：你看她涂这个颜色真的好好看哦。这时钢铁直男和情圣的反应就完全不一样了。
　　直男：我觉得都一样啊，都是红色，并附带黑人问号脸；情圣：确实好看，也很适合你哦（过两天约会的适合用精美的礼盒包好送到女生手里）。同样的话，不同的答案造成的心里落差，可谓千差万别！！
　　有时候，或者说用户根本不知道自己要什么（前面提到过）。你需要去引导，或者去思考用户言语背后的真实需求。
　　共享单车出来之前，我想大家都有最后1公里的困扰。但那时候，如果你跟别人说，公司去地铁站好远啊，坐公交很堵，走路又太慢，那对方对半会跟你说：买电动车吧，骑车去公司；买个代步车吧等等。
　　直到摩拜单车出现在大众视野，我们才知道，自己不过是想要解决最后1公里的困扰（想给共享单车的发明者加鸡腿）。其实这样的例子很多，只要仔细留心身边的一切。
　　3。需求跟进
　　据我这1年多的临床经验，一个需求的完整生命周期可以划分为6个部分：
　　需求确认阶段：该阶段需要将收集到的需求加以确认，再根据需求的重要程度进行优先级排序。一般是在月初，因此一般会定下本月要做的需求（这个视团队习惯而定）。
　　需求设计阶段：这阶段产品们会将需求转换成原型图，并且将初版的prd输出，发送到团队群内。供研发团队进行一个初步的技术评估。
　　需求再确认开发排期：开发和产品们会就第二阶段产品输出的原型及prd进行一次头脑风暴及需求确认，确保双方的理解一致，减少后期因为理解偏差造成的影响。
　　需求跟进阶段：产品会根据上一阶段的开会结果，重新整理prd，发到团队的协作平台上，并及时更新。协作平台的内容包括各个系统的需求池，以及问题记录。当然，产品还会实时跟进开发进度，处理开发在开发过程中遇到的各种疑难杂症。
　　测试验收阶段：以PRD文档为准进行测试验收（PS：小公司有可能根本没有测试，因此产品还要承担测试的工作）。开发根据测试结果进行问题修复，全部修复完成后，提交代码，发布上线。
　　运维阶段：需求上线，并不是需求的终点，而是产品投入市场的起点。需要产品人通过跟进用户反馈，对正式数据进行对比分析，验证是否真的满足用户需求。然后不断的更新迭代
　　PS：运营阶段还有一件重要的事，在需求上线之前，一定要和各个需使用到该需求的业务部门沟通好，甚至说培训好。否则上线后，会措手不及，甚至导致各部门之间的不愉快
　　二、产品设计
　　清楚地记得，第一次设计的产品是一个APP的订单列表页面，现在看来这不是信手拈来么，但当时由于业务不熟，产品概念还未形成，以至于根本不知道从哪里下手。
　　幸好有巨人的肩膀可以站立，通过对其他APP的借鉴和模仿，倒也没出什么逻辑问题，只是设计缺乏重点，如图（大家可尽情吐槽）：
　　图21
　　1。前端
　　前端也可笼统的称为客户端，在没有微信小程序之前，前端有APP设计，WEB设计。
　　微信小程序的风刮起来后，做前端的产品还需做微信端设计。一般情况下，都是APP微信小程序组合
　　前端产品既要好看，更要实用，二者缺一不可。但非要说一个更重要的，那还得是实用。毕竟，解决用户问题的产品才是好产品
　　入行的时候这个观念就已深深藏在我脑海里，因此我一直都特别注重实用差点忘记好看，所幸公司的UI设计师一定程度上弥补了我的不足。
　　在反复和设计师交流的过程中，了解了一些好看方面的知识（同设计师交流，必须多学点UI方面的知识，不然怨念很深）
　　另外没接触过微信小程序设计的同学，做之前，请一定要先看微信小程序设计规范！！不要问为什么，等做出来四不像时，你就知道为什么了。
　　2。后台
　　后台系统常见的有开放式后台系统和非开放式后台系统。相对来说，公司大多都还是非开放式后台用的多些。
　　开放式后台系统常见的有：微信公众平台、淘宝卖家平台等；开放式的后台在用户体验上会稍微注重些。
　　非开放式后台不会在界面上提供注册功能，后台系统用户的添加一般是拥有相关权限的管理员添加配置，最常见的是ERP系统。（这1年多，我从专门负责1个ERP后台APP，到现在同时兼顾2个。由于前1个系统已经非常稳定，因此大部分时间都放在维护今年3月开始的新系统上）
　　后台设计，非常注重业务逻辑的流转，在没有了解清楚业务的每个细节前，千万不要轻易下手。否则后面会有无止境的修改（开发心里会骂你一百遍，就问你怕不怕）。流程图是必须的，重要功能的时序图也是必须的；
　　这是很久之前画的比较笼统的促销活动流程图和时序图（献丑了）：
　　221流程图
　　222流程图
　　三、数据分析（功能）
　　数据分析不可谓不重要，一切想法要论证是否正确，都必须通过数据说话。但刚入行根本没有数据概念，一心埋头苦干。
　　直到某次作报告，总监问到我转化率是多少的时候，我一头雾水才开始关注数据。
　　PS：首先声明，这里说的数据分析特指功能数据分析，不泛指行业、市场等数据的分析，这种分析可在数据分析网站上查看行业报告。就不细说，最主要是我觉得以我目前的知识面来说，不足以将这种数据看的透彻
　　1。数据来源（常用的有2种）
　　采用基于前端页面的数据采集工具获取，如小程序的数据助手等可视化的数据采集产品；
　　通过数据埋点的方式，在开发时根据设计提出的需要埋点的地方进行数据采集，需要时从数据库导出查看即可。
　　2。优缺点对比
　　用数据采集工具
　　优点：不用费时费力去做开发，方便快捷，一般都有载体产品，可随时查看；
　　缺点：特定的数据无法自定义，统计数据相对概念化。
　　通过数据埋点可
　　优点：可自定义任何自己想要的数据，尤其能够满足特定场景下的特定场景的数据统计；
　　缺点：费时费力，需要人工成本较高，从前期到设计都需要耗时耗力；
　　PS：附一张数据埋点的表（仅供参考，请多指教）
　　四、项目管理
　　PS：由于是中型创业公司，组织机构不够完善，并没有项目经理的存在，因此，我们产品基本上承担了项目经理的责任；
　　由于本人资历尚浅，经验不足，在项目管理方面，我只做到了解每一个人的性格做事风格。
　　甚是幸运，这1年多与项目小组的所有开发人员都相处得十分愉快，项目进行的也很顺利。大概是他们性格好，又肯配合，技术又很给力（给他们加鸡腿，真的给力）！这一年，我们项目组每月的绩效，半数以上都是超过100的
　　关于项目管理，过个几年在来写可能会不那么尴尬，现在写有种小孩扮大人的感觉暂时就写这么多，谢谢大家，欢迎大家指出我的不足之处，和我交流心得体会，但不欢迎喷子