1线产品经理的工作感想.doc

一线产品经理的工作感想 只是个人的工作心得和所思所想，信马由缰一通，做产品的人能大致看得懂就行了。 没啥铺垫的，直入正题，一块块来：先上一张图 　　需求文档看不看 　　当你辛辛苦苦写出来一堆需求文档，跟UED的同学定好交互、视觉、重构;满以为技术会认真对待，但是你会发现，技术同学基本不会看你准备的一堆东西，基本是按照自己的理解来开发，当开发不下去，第一时间也不是看文档，而是看测试用例，或者直接跟产品沟通;基本文档只是QA同学对着写用例。 　　刚刚开始工作的时候，对于技术不按照文档开发，是比较着急上火的，经历一段时间后，发现重点就好了。产品的本质是保证产品核心功能的质量，保障用户体验，用户端和商户端的功能不能含糊;运营后台、客服后台之类的，保障功能完整和业务流畅的基础上，可以给技术适当的自由发挥;就算是前台页面，多听听技术的意见，让技术同学参与进来;开发过程中，保持沟通，对于技术提出的问题，最快速度的响应。 　　什么样的需求要写文档?对于功能性、涉及业务流转，状态切换，边界条件灰常多的需求，流程图、交互、PRD一个都不能少;对于非功能性的需求，提升用户体验的部分，文档可以不准备，准备好原型图，然后在上面标注出重点，交付的时候讲清楚。 　　todolist与优先级 　　产品在迭代过程中，不断有新的需求，不断有需求被完成，通过list来管理这些需求，整理的过程也是对产品思考的过程，不停问自己，这个需求用户是谁，解决什么问题，是否必要，以及是否必要现在就做? 　　list的好处就是，可以尽量多的记录所有需求，虽然有些天生就是被砍的命，但是list一堆需要完成的事情，对整个项目组都会有紧迫感;一句话讲清楚每个需求，标明优先级，负责人，对应的开发，开始时间，完成时间，完成状态，让项目组所有人(包括老板)，都知道我们现在有多少事情在做，已完成来多少，接下来做什么。 　　需求永远做不完，对于优先级安排，平时工作中最常用的就是四象限法，重要又紧急，重要不紧急，紧急不重要，不紧急也不重要，根据项目实际来做判断。 　　需求会议 　　2014年都是一周一次迭代，每周都会有下次迭代的需求会议，并不是真正意义上的需求评审，产品驱动的公司，基本就是需求讲解，交付，以及相关时间点确认 　　需求准备要充分 　　在需求会议上，面对技术和QA，甚至老大们的挑战，这是正常的，他们会问为啥要这么做，为啥不那么做，甚至直接对你的需求提出挑战：这个东西不靠谱，不可能;拍桌子打板凳的事情也时有发生;唯一避免发生的情况，就是对于需求的准备要充分;不管面对何种挑战，讲清楚数据、用户需要、和竞争对手怎么做的，基本就能说服;一般只要保持平和的心态，不会有大问题。 　　真有自己无法立即解答的，快速承认错误：不好意思，这个是我没有准备好，会后我再去做详细调研和准备，快速跳过这个问题，继续下面有把握的内容;会后再去完整论证，并把问题描述清楚，邮件给大家;既可以避免冲突，会后大家平和心态来对待，也便于解决。 　　讲好我的故事 　　这里应该是讲好用户的故事，为啥叫讲好我的故事，因为产品需要把自己代入到各个角色中;做过几次用户访谈，很多用户描述这样一个场景，我快下班了，拿出点评App搜索附近找吃的;运营说这个这个很烦，我需要这么这么做，其实可以这样就解决了; 　　客服说，这个信息在这里查，那个信息在另外一个页面，每条记录处理的时间增加多少分钟; 　　最有意思的是商户端，商户那边有签合同的、店长、负责人、前台、收银，会计，每个人都有可能来用我们的后台，去商户端做访谈的时候，观察他们如何使用点评的产品; 　　讲需求的时候，先描述用户遇到的困境，绘声绘色，动人心弦;如何做到，代入自己的角色，不要假装用过，而是自己真正使用过程中的痛点，放大再放大，感情方式来打动技术。 　　描述痛点只是第一步，可以清楚描述，如果这个需求做来，运营效率可以提升多少，节约多少成本，最终转化率预计提高多少，以及ROI(投入产出比)，所有功能点的改进，最后都可以结算为Money，因为钱，会让所有人兴奋，并集中精力来解决问题。 　　让更多的人参与需求讨论 　　需求被挑战，会有点不舒服;但是若所有人都表现出对你的需求漠不关心，那才是最难受的。如何让技术更多的参与需求讨论：首先可以挖掘对业务有兴趣的人，多跟他们聊，他们会主动告知他们的想法。一般工作几年的技术比刚刚工作的童鞋更关心;其次让技术有存在感，定时告知他们相关的产品数据，月用户数，月增长量，收入等，根据技术所开发的功能点，细化到此功能带来的数据，以及同比环比数据;最后在Scrum中，计划扑克能够让所有人都参与到需求当中，因为每个人都要评估task的工作量，目前来看，效果还不错。 　　确定好时间点和相关责任人 　　Scrum确实是一个好的方式，能够估算出工作量，并且技术自发领取