产品经理成长日记-从需求到产品

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

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

需求文档看不看

当你辛辛苦苦写出来一堆需求文档,跟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一起成长。

本文作者系大众点评产品经理@七手八脚裸奔地小石头。来源:leiphone.com

您的赞赏,是对我创作的最大鼓励。

评论( 11

登录后参与评论
  1. 其实描述的是从已规划的需求到技术实现这一段,比较细致。中间提出了跟开发和QA常见的问题,也给了一些可落地的解决方案。不过产品用户需求或者idea到产品需求这一段缺失了,感觉标题用第一段提到的产品和技术的沟通更恰当。

    回复
  2. 其实描述的是从已规划的需求到技术实现这一段,比较细致。中间提出了跟开发和QA常见的问题,也给了一些可落地的解决方案。不过产品用户需求或者idea到产品需求这一段缺失了,感觉标题用第一段提到的产品和技术的沟通更恰当。

    回复
  3. 写的不错!思路上有些方向了

    回复
  4. :grin:

    回复
  5. 很发

    回复
  6. 突然意识到居安国际的美尚美发的那群人也是开的Scrum会议…(笑)

    回复
  7. 写得真好,学习了

    回复
  8. 干货分享,好文章

    回复
  9. 这篇文章绝对值得一看!

    回复
  10. 分析的比较仔细,也比较到位!值得新入行的产品经理们去学习。

    回复
  11. 不错

    回复
加载中