您的位置首页  网站运营  产品

需求的生命周期中我们究竟该做什么?

  • 来源:互联网
  • |
  • 2019-03-14
  • |
  • 0 条评论
  • |
  • |
  • T小字 T大字
需求的生命周期中我们究竟该做什么?  产品经理们在处理来自不同地方的需求时,有着不同的工作方式和方法:分类管理、定期等不一而足…

原标题:需求的生命周期中我们究竟该做什么?

  产品经理们在处理来自不同地方的需求时,有着不同的工作方式和方法:分类管理、定期等不一而足。那么,对于需求的整个生命周期来说,我们究竟应该怎么做呢?

  需求的来源有很多。业务越复杂,需求就越杂。一个淘宝,产品需求就可以拆分成分类、检索、排序、商品展示、营销活动、支付、配送、售后等等。

  你的职级越高,也代表着身边人提需求的可能性越大。初入行的产品专员或助理,主要是得到被安排的任务;初级产品经理,需求来源主要是用户和上级;产品负责人,需求来源就要增加老板和其他相关部门; 而作为老板,谁都可能跟他提产品需求。

  所以在获取到需求这一时刻,就必须做一个判断,并且记录。如果不做判断堆在那里,等做的时候根本没办法梳理出头绪,可能大部分时间都在疲于需求清单。记录当然是为了方便回溯。获取到的再小的需求也记下来,不要指望你随时能想起来每天听过的每个需求。

  同样是页面写错了一个字,把「登录」写成「登陆」,和把「励 15 元」写成「励 50 元」,重要性不言而喻吧。有个大致的预估。

  需求来源会表明一些事情,要慎重思考。比如老板提到的,未必是目前你能理解的,但他认为特别重要,就暂且把这个当成特别重要的,这是任务。再比如是用户提到的,但细想他并不是目标用户,他的需求就不必太关注。

  我自己工作中有三类需求绝对不记:没说清楚原因的,不记(你做个 出来,别管那么多);不说清逻辑的,不记(啊,这里我也没搞懂,你先看看);不是实际遇到的,不记(哎,我觉得可能有人会这样用)。

  需求背景没搞清楚,完全是浪费时间。有一句话的记录,但不说背景,也是浪费时间。记的时候,我会确保格式是问题 + 方案,「X 在用我们的 功能时,感觉 X,我们可以尝试 X 这样的方案」。

  最后,依据这三个因素,判断属于大致哪个类别的。一般的需求管理都会分 P0-P3 或者 P1-P4,总之先打个标签。这里的技巧是尽量标记为比估计的更重要一层的需求,就是你感觉是 P2 的,暂且先标为 P1。这样以防错漏,低优先级的标成高的没关系,但高优先级的标低了会出现麻烦。这时候的预估往往不准确,但没关系,等后面第二步再说。

  隔一段时间,我们会开需求,整理需求池,也就是记录所有获取到需求的表单。

  之前的判断是粗估,这里的判断就要精细了。一般需求的重要程度很难量化,尤其来源复杂的情况下。营销部门着急要我们配合做活动,不做就少赚好多钱,业务部门着急要我们配合做一套自动化结账工具,做了能节省很多成本 有时抉择很痛苦。

  这里还是用最常用的判断方法,紧急重要四象限(请自行百度「四象限」)。重要程度大致按这种排序:

  大家把能考虑到的因素想全,会标上 P1 P4 的优先级。

  需求有不同的解决办法,我们会讨论清楚到底用哪种解决。比如我们发现有刷单现象,可以事前提醒,告知用户目前地理或订单信息有嫌疑;可以事中,必须到达指定地点、拍摄当地照片等等操作来用户;可以事后,提供给客服或者业务部门疑似刷单的名单和,罚款或者封号。这几项到底做哪个?还是做其中哪几个?优劣在哪?需要好好讨论。

  有时会有大概的方向,再去跟相关部门和需求相关的同事确认。这不在本文讨论范围内,暂且不提。

  我之前经历过两种需求分配制度。一种是每个人负责的需求范围有清晰的边界,那需求对应哪个模块,就直接分配即可;另一种是团队作战,每次指定或者认领,谁都有可能接手任意需求。

  前一种的好处在,模块清晰,负责人可以对自己负责的部分足够熟悉,但缺点是,工作量很可能不平衡,有的同事一直在忙,有的可能就比较闲,因为需求不是平均按模块分布的。

  在我们需求分配时,大致还是按照模块分配,但在出现工作量不平衡的情况时,会酌情调整一下,让活少的同事予以配合。

  不管怎么样,一定一定要指定负责人,他需要对需求负责,一直到产品上线后,出了的问题他也要承担责任。要运营良好的工作责任制。

  时间节点至少也要包括方案完成的时间。就是这个需求,能够完好提交给开发的时间。如果没有这个时间,对需求的管理就没有一点意义了。

  另外,如果是要跟相关部门再确认、或者要跟用户调研、或者要统计各种数据再作判断的需求,那还要有调研 / 讨论完成的时间。

  这个时间节点的划定,主要是按照方案的复杂程度,用经验做个简单判断。最长的时间周期也不能超过一周,需求的推动进度,因为很难有复杂程度超过一周的产品需求。对于有严格上线时间的需求(经常会出现,比如很苛刻的老板需求、投资人需求、需求等),要倒推出最合理又富有余地的时间节点。

  讨论完刚刚入池的一批需求,我们会再整理和讨论其它状态(有方案或者调研结论)的需求。这样会议结束,每条需求都会得到更新。

  我们在这个时刻,一般会让负责的产品经理,及时更新需求状态给需求来源方。当然,来源方 95% 的情况下会对进度不满意,这很正常,但除非来源方有确凿的理由,我们不会轻易调整优先级和时间节点。

  有了确切方案,我们会尽快跟研发的同事做可行性评审。这一步必不可少。我感觉题主出现的「落不了地」和「频繁更改」的问题,要着重在这个步骤里解决。

  一定要跟技术部门清晰的需求背景,让他们也想一些可行的方案。方案未必是完整、准确的,但他们提供的思,一般是可行性较高的。

  这个需要相关的同事仔细讨论。尤其是很多公司产品线比较多,有可能存在牵一发动的情况,如果相关的产品同事和技术同事不知情,必然会延期,必然会扯皮,必然会造成麻烦,必然会有各种改动。即便是再小的产品,也要分前后端,让技术的同事来判断有哪些人需要知情和参与评估。

  看方案需要多少人、多少资源、多少时间来完成,也要看方案在技术层面耗费的不太明显的成本,比如服务器成本、带宽成本,给用户造成的流量成本等。

  开发需求的次序,我们不是完全按照需求池里的需求优先级来的。刚才说到,在可行性评估会上,我们会核算大致的需求成本,那成本结合需求的优先级,就可以得出需求的性价比了。

  我在创业公司产品经理怎么做?提到过具体的方法,这里不再赘述。大概是用这样的表格:

  当然啦,如果什么事情都是原则上那样 就不会出现这么多扯皮的情况了。

  在开发中,扯皮的问题归纳起来就是三种:需求太多,没按时做完;需求有改动,导致了额外工作量以及开发的不满;有新的紧急需求,导致发布延期。

  方案不完整往往是没有考虑全面。这个跟需求管理本身没关系,就是在出方案的途中,看能不能把事情想全。

  之前我们经常出现,做的时候技术才发现卧槽这里有个逻辑没想通啊。然后喊产品来一起讨论的时候,大家发现需要加一些功能才能完善逻辑。最后结果就是周六加了个班,大家很不开心。

  这种事情也不好追责,毕竟参与者很多,流程拖得很长。硬要说是负责需求的产品经理有问题倒也可以,但总是片面的:他也不一定知道技术上开发才发现的逻辑。

  后来我们反思,各个流程中的环节都要做一些调整,才能确保最终产品方案的完整:

  之后再出问题,会回溯原因。如果是前两个环节出的问题,那就是产品经理的责任;如果是产品经理未知的逻辑,那就是可行性评审中,技术的同事的责任。

  这种情况基本都是需求方或者产品经理的问题:他们在提交方案前没有完全想清楚。

  有时候都开始开发了,业务部门来人说,哎我们发现这个问题好像不存在了,大家不要做了。他们觉得无所谓,还减轻了开发负担。但对技术部门的同事来说,就好像在说「你被耍了,哈哈哈」。造成的影响是恶劣的。

  产品经理在对接他们的需求时要做判断,他们是不是完全想清楚了,是灵机一动的小点子,还是不得不解决的问题。

  另外,还有一种情况,是需求方跟产品经理对接时出了问题。表述有误,并且方案没有跟他们核对清楚,结果产品功能上线,才发现并没有解决问题。

  我们的做法刚才多少提到了一些:要在任何需求的属性(内容、时间点)发生变化时,跟需求方同步。让他们知道我们的情况,也获取他们的意见和。

  比如,本来要做一个功能狙击对手,结果做了一半,竞争对手倒闭了,那这个功能就没有意义了,确实要废除。

  还有一些业务上的确无法预测的各种原因,导致原本存在的问题不存在了,也无可厚非。

  这种情况下,产品经理最重要的是安抚技术的同事,尤其是跟他们解释清楚背景和详细的原因,不要让他们误以为是刚才提到的前两种理由。

  需求从获取到上线,走完生命周期之后,还要有一个很重要的复盘阶段,尤其是在需求管理出过故障和问题的时候。

  略靠谱的团队,都会有复盘的机制,主要是防止问题再次发生。解决问题很简单,如何尽量规避下次再出问题很复杂。

  大致就是,要搞清楚之前出现问题的所有逻辑和流程,再去看在哪些环节可以做点什么,去防止再次出现。这块的内容说得多了又得写一篇文,就不多讲了。

  以上就是我的经验,仅供参考。没有什么流程和机制是完美的,关键在于怎么去解决自己的问题。如果哪些思给你了,那就够了。

  刘飞,原嘟嘟美甲联合创始人,锤子科技产品经理,人人都是产品经理专栏作家,豆瓣《最好的时代:可能是最真诚的创业日记》作者。文能提笔抒骚情,武能切图画交互。

  现在全公司上下用鱼骨执行力软件做需求管理,所有的事情必须提交一个任务,指定一个负责人和完成时间,关于这件事情的讨论必须在任务里,整个工作变得非常有效率和条理

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集、培训、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。

免责声明:本站所有信息均搜集自互联网,并不代表本站观点,本站不对其真实合法性负责。如有信息侵犯了您的权益,请告知,本站将立刻处理。联系QQ:1640731186
友荐云推荐