PM成长日记:从需求到产品

标签: 互联网新闻 | 发表时间:2013-03-13 01:22 | 作者:七手八脚裸奔地小石头
出处:http://www.yixieshi.com

   本文作者系大众点评产品经理@ 七手八脚裸奔地小石头

  本篇本来打算写如何跟技术进行沟通,其实跟技术的沟通,是贯穿于整个从需求文档到产品上线、产品跟踪、迭代的过程之中的。本篇更多的是讲作者工作半年来,从需求文档到产品上线的过程,也希望与同行朋友多交流。

   需求文档看不看

  当你辛辛苦苦写出来一堆需求文档,跟UED的同学定好交互、视觉、重构;满以为技术会认真对待,但是你会发现,技术同学基本不会看你准备的一堆东西,基本是按照自己的理解来开发,当开发不下去,第一时间也不是看文档,而是看测试用例,或者直接跟产品沟通;基本文档只是QA同学对着写用例。

  刚刚开始工作的时候,对于技术不按照文档开发,是比较着急上火的,经历一段时间后,发现重点就好了。产品的本质是保证产品核心功能的质量,保障用户体验,用户端和商户端的功能不能含糊;运营后台、客服后台之类的,保障功能完整和业务流畅的基础上,可以给技术适当的自由发挥;就算是前台页面,多听听技术的意见,让技术同学参与进来;开发过程中,保持沟通,对于技术提出的问题,最快速度的响应。

  什么样的需求要写文档?对于功能性、涉及业务流转,状态切换,边界条件灰常多的需求,流程图、交互、PRD一个都不能少;对于非功能性的需求,提升用户体验的部分,文档可以不准备,准备好原型图,然后在上面标注出重点,交付的时候讲清楚。

   todolist与优先级

  产品在迭代过程中,不断有新的需求,不断有需求被完成,通过list来管理这些需求,整理的过程也是对产品思考的过程,不停问自己,这个需求用户是谁,解决什么问题,是否必要,以及是否必要现在就做?

  list的好处就是,可以尽量多的记录所有需求,虽然有些天生就是被砍的命,但是list一堆需要完成的事情,对整个项目组都会有紧迫感;一句话讲清楚每个需求,标明优先级,负责人,对应的开发,开始时间,完成时间,完成状态,让项目组所有人(包括老板),都知道我们现在有多少事情在做,已完成来多少,接下来做什么。

  需求永远做不完,对于优先级安排,平时工作中最常用的就是四象限法,重要又紧急,重要不紧急,紧急不重要,不紧急也不重要,根据项目实际来做判断。

   需求会议

  12年都是一周一次迭代,每周都会有下次迭代的需求会议,并不是真正意义上的需求评审,产品驱动的公司,基本就是需求讲解,交付,以及相关时间点确认

   需求准备要充分

  在需求会议上,面对技术和QA,甚至老大们的挑战,这是正常的,他们会问为啥要这么做,为啥不那么做,甚至直接对你的需求提出挑战:这个东西不靠谱,不可能;拍桌子打板凳的事情也时有发生;唯一避免发生的情况,就是对于需求的准备要充分;不管面对何种挑战,讲清楚数据、用户需要、和竞争对手怎么做的,基本就能说服;一般只要保持平和的心态,不会有大问题。

  真有自己无法立即解答的,快速承认错误:不好意思,这个是我没有准备好,会后我再去做详细调研和准备,快速跳过这个问题,继续下面有把握的内容;会后再去完整论证,并把问题描述清楚,邮件给大家;既可以避免冲突,会后大家平和心态来对待,也便于解决。

   讲好我的故事

  这里应该是讲好用户的故事,为啥叫讲好我的故事,因为产品需要把自己代入到各个角色中;做过几次用户访谈,很多用户描述这样一个场景,我快下班了,拿出点评App搜索附近找吃的;运营说这个这个很烦,我需要这么这么做,其实可以这样就解决了;

  客服说,这个信息在这里查,那个信息在另外一个页面,每条记录处理的时间增加多少分钟;

  最有意思的是商户端,商户那边有签合同的、店长、负责人、前台、收银,会计,每个人都有可能来用我们的后台,去商户端做访谈的时候,观察他们如何使用点评的产品;

  讲需求的时候,先描述用户遇到的困境,绘声绘色,动人心弦;如何做到,代入自己的角色,不要假装用过,而是自己真正使用过程中的痛点,放大再放大,感情方式来打动技术。

  描述痛点只是第一步,可以清楚描述,如果这个需求做来,运营效率可以提升多少,节约多少成本,最终转化率预计提高多少,以及ROI(投入产出比),所有功能点的改进,最后都可以结算为Money,因为钱,会让所有人兴奋,并集中精力来解决问题。

   让更多的人参与需求讨论

  需求被挑战,会有点不舒服;但是若所有人都表现出对你的需求漠不关心,那才是最难受的。如何让技术更多的参与需求讨论:首先可以挖掘对业务有兴趣的人,多跟他们聊,他们会主动告知他们的想法。一般工作几年的技术比刚刚工作的童鞋更关心;其次让技术有存在感,定时告知他们相关的产品数据,月用户数,月增长量,收入等,根据技术所开发的功能点,细化到此功能带来的数据,以及同比环比数据;最后在Scrum中,计划扑克能够让所有人都参与到需求当中,因为每个人都要评估task的工作量,目前来看,效果还不错。

   确定好时间点和相关责任人

  Scrum确实是一个好的方式,能够估算出工作量,并且技术自发领取任务,直至每个人工作内容都填充满整个sprint。

  在未开始Scrum之前,每周一次需求会议,只是交付好相关需求,由开发主管来指派任务,并定好工作计划表,然后QA同学补充相关测试安排,最后敲定上线时间。

  其实不管何种方式,最终的结果导向就是,产品尽快上线,且以最有效、风险最小的方式。

   适当地砍需求

  产品是不需要懂技术,但是如果能根据需求大致预估工作量,排期更简单;每次我都会提前多准备一些,连交互和重构都准备好,摆出一副不做此需求是誓不罢休的架势;资源充分时,技术童鞋会主动领取需求的,但是当工作都排的比较满的时候,就很难了;所以需求评审时,每个需求的优先级都排的高高的,将用户痛点描述的栩栩如生,如果技术实在抱怨太多,那就象征性地砍掉部分,前提是保证核心必须完成,其实当砍掉一部分,不会一直砍下去,而且心里也会有满足感;其次给技术紧迫感,赶紧完成,后面还有一堆事情呢,即使这次迭代不做,下次迭代也需要完成

   产品开发过程中

  保持沟通

  在产品开发过程中,技术都是非常有责任心的,会帮你考虑边界条件,作为产品积极响应技术提出来的各种疑问,是维系技术与产品之间很有效的方式。虽然有一些问题,可能是技术对需求的理解并没有产品那么深刻,讲清楚就好了,没有必要上纲上线,因为最终大家的目的都是为了产品,另外公司开始实践的Scrum也对整个团队保持沟通,既是要求,更要成为一种习惯。

   认真对待测试用例

  测试用例,又是一个保证产品质量的利器;刚开始工作的时候,认为测试用例只是QA同学的工作,第一版本App上线做UAT的时候,发现对着需求文档并不能完整验证完所有需求,但是对着测试用例,所有的主流程,辅助流程,边界条件,非功能性需求,清晰明了,感觉太有用了。所以每次都提前完成需求文档交付QA,QA在技术正式进入研发完成用例文档;在过测试用例时,产品同时参与,避免一些需求理解上的偏差,此外技术同学对着case开发,比需求文档描述更清晰,另外技术同学可以参与部分自测;UAT的时候,也是产品的参考。

   需求变更与delay

  需求变更是永恒的话题,Scrum中一般是不接受需求变更,其实不允许变更的本质不是需求定板不动,而是对产品提出了更好的要求,从需求调研、准备、设计、交付每一步都需要考虑周全和清楚;即使在要求严格的Scrum中,需求真的不能变更么?如果临时线上bug造成用户无法访问,技术同学是不是要停下手中工作,来排查线上故障呢。作为一个产品,不是神,尽量保证所有的需求都是合理且必要,并且将所有的需求准备工作做到位;如果还不能避免,就要影响甚至说服整个团队来拥抱变化。

   正确处理需求变更

  需求变更已经发生,那就赶紧处理吧。如果是产品没考虑清楚,用户调研或者数据支持出错,果断向团队承认自己的错误,没有人会责怪一个真心诚意道歉的人;并在第一时间交付变更后的需求文档、交互、视觉、重构等,并跟技术沟通如何以最小的代价,完成此次实现;若技术的工作在本次迭代已经安排很满,那考虑需求的紧急程度,适当情况下,可以放到下个迭代去完成。

  若是因为行业或者市场变动,产品转型等原因,直接向团队传达变更的原因,以及接下来的产品规划,让所有人都看到一个清晰明确的目标,技术会有疑问和挑战,耐心解答,通过行业数据、竞品等角度去阐述;遇到老板变更需求,那比较简单,因为老板的需求优先级永远是最高的,但是作为跟技术直接沟通的产品,要认真对待老板变更的部分,若老板频繁变更需求,烦的是技术,会不会以后合作留下影响呢。

   关于产品delay

  不管产品还是技术,没有人愿意看到delay的;面对delay,怎么处理?换个思路:就算delay了,只要用户还能用,服务照样跑,地球还照样转。如果真的导致用户不能访问,整个技术团队肯定加班加点,不吃不喝也会搞好的。一旦出现delay,整个团队一起来排查delay原因,是需求变更,还是资源没到位,还是项目之间的耦合关系,前面小的改动,导致后面项目的延期,做好每次的总结会议,并在下一个迭代中避免此问题。

  目前团队中正慢慢引入Scrum敏捷开发,而本篇总结,大部分是基于小瀑布模式的迭代;需要学习的还有很多,一转眼又过了两个月,正式工作已经八个月,需要走的路还有很多,跟随整个team一起成长。

相关 [pm 成长 日记] 推荐:

PM成长日记:从需求到产品

- - 互联网的一些事-关注互联网产品管理,交流产品设计、用户体验心得
   本文作者系大众点评产品经理@ 七手八脚裸奔地小石头.   本篇本来打算写如何跟技术进行沟通,其实跟技术的沟通,是贯穿于整个从需求文档到产品上线、产品跟踪、迭代的过程之中的. 本篇更多的是讲作者工作半年来,从需求文档到产品上线的过程,也希望与同行朋友多交流.   当你辛辛苦苦写出来一堆需求文档,跟UED的同学定好交互、视觉、重构;满以为技术会认真对待,但是你会发现,技术同学基本不会看你准备的一堆东西,基本是按照自己的理解来开发,当开发不下去,第一时间也不是看文档,而是看测试用例,或者直接跟产品沟通;基本文档只是QA同学对着写用例.

从编辑到PM

- 小鱼 - 所有文章 - UCD大社区
春节前收到一封陌生人的来信,一位网站频道编辑,向我咨询转型PM的可行性. 他问道:“你觉得做媒体和做产品,以前一样么. 话题很有趣,我也乐意就此写点什么. 遗憾的是,编辑转产品的成功概率却是不高的,就我的经验来看,存在四个障碍. 媒体工作需要捕捉阅读的共性,即“大家都爱看的内容”,相对来说比较忽视用户的个性化特征.

如何与PM沟通

- - 曉生
1.要学会听取别人意见,也许PM提出的问题你并没有考虑到,集思广益,可以得出有更好的方案. 值得肯定的是,你设计时已经能学会从产品角度考虑,引导用户操作,而不是单纯的好看. 只要不是单纯审美上的PK,都可以讨论,不是吗. 2.让产品阐述自己的需求点,明确重点. PM们七嘴八舌肯定不对的,要引导他们梳理出统一的意见.

PM札记:产品设计这两年

- - 所有文章 - UCD大社区
做产品差不多也两年左右了,基本上这条路是磕磕绊绊,迷迷糊糊,但好歹大方向是正确的,有空回想总结起来,唏嘘不已,看看以前对产品的看法,再看看今天对产品的认识,不仅感叹自己当初的幼稚,如今,更多的是了解了自己的无知与渺小,怀着一颗谦卑的心,继续学习,在产品这条路上寻找自己的价值. 产品职责包含很多东西,产品设计只是其中的一种职责,只是简单的描述一下我在产品设计上的弯路,回想起我的产品设计生涯,目前走过了三个阶段:.

PM培训的答疑课小结

- - 阿里巴巴(中国站)用户体验设计部博客
这期PM培训的最后一次课安排的是答疑,回答了一些同学们普遍关心的问题. 对学员们和讲师的讨论,我做了些小结如下:. 产生这种情况说明项目管理已经存在大的问题了. 要做到的是提前预知,避免这种情况的出现. 万一出现了,首先要深入了解原因. 两个方向,项目内搞定或者项目外搞定. 回答这个问题的关键是找关键路径.

浅析PM工作流引擎

- - CSDN博客推荐文章
1.      JBPM工作流引擎是用来做什么的. 首先要说明的一点是工作流引擎指的并不只是JBPM,JBPM只是工作流引擎的一种. JBPM利用JPDL流程定义语言将现实生活中处理事务的业务流程进行抽象,形成一套业务流程规则,只要处理该项业务就必须按照这个流程规则进行. 举一个很简单的例子,就拿看医生来讲,看医生的整个流程必须是先挂号,再看病,再抓药,只要你进行看医生这个业务就必须按照这套流程进行.

如何防止架构师PM化

- -
和一些做项目主架构或者一号位的同学聊天,经常会听到一种说法:项目主架构做着做着就会做成PM. 这背后什么含义呢,细品下来有几层意思:. 整个集团的架构非常复杂,涉及的域众多,做主架构或者一号位需要大量的协调投入;. 不同域之间的资源错配现象严重,需要投入大量精力在锁定资源和推进排期上;. 项目结构过于复杂,PM催主架构,主架构催域架构,域架构催开发,层层订,各种站会,代码没几行,会议一大堆;.

您的团队需要什么样的PM?

- - 所有文章 - UCD大社区
     在腾讯,多数部门的实际采用了职能化或弱矩阵的组织结构形式. 中心和小组等组织层级实质属于职能线条,产品、开发、测试、运营、运维等职能角色是产品运营的主要角色,而各部门都会或多或少有一些全职或兼职的PM组织管理着各类跨职能活动.       基于各自情况的不同和各自对PM职位理解的差异,对PM职位的定位也千姿百态.

作为一个PM 该如何做好产品竞品分析?

- - 互联网的一些事-关注互联网产品管理,交流产品设计、用户体验心得
  在企业中竞品分析工作大多数产品经理实际工作中很少去做,要么由市场和运营人员代劳,也或者产品部门配备市场研究相关岗位定期来做. 而近来部门同事实行每月对现有产品进行竞品分析,参与一部分工作. 对于既不是专才和通才的产品经理来说也是一种全新历练和学习.竞品分析结果只能作为一种参考依据(由于信息挖掘渠道和关注点都相对带有主观性,比较危险的是有些产品经理会特意朝预期潜意识心里判断来收集数据),通常服务于领导及产品管理层对产品信息动态能够有意识的去关注及时调整相关目标;.