选择分类
  • 云瑞原创
  • Mockups
  • Ui Kits
  • 背景纹理
  • 图标
  • 平面图形
  • 探索
  • 笔刷
  • 图层样式
  • PPT模版
  • 影视素材
  • 教程
  • C4D资源
  • PS动作
  • 常用3D资源
  • 字体
  • 网站模板
  • LR预设
  • 设计学院

一个产品的迭代生命周期中,我们究竟有哪些职责?

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

一. 获取阶段

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

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

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

做判断的内容具体是什么呢?

第一,判断需求本身的重要性

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

第二,考虑需求来源

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

第三,简要得到需求背景

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

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

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

比如这样:

一个产品的迭代生命周期中,我们究竟有哪些职责?1461587996-9851-0425b

二. 讨论 / 设计阶段

隔一段时间,我们会开需求讨论会,整理需求池,也就是记录所有获取到需求的表单。我们会详细讨论每个需求的情况,确认几个事项:

1. 需求的优先级

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

这里还是用最常用的判断方法,紧急重要四象限法则(请自行百度「四象限法则」)。

重要程度大致按这种排序:

  • 不做会造成严重的问题和恶劣的影响的
  • 做了会产生巨大好处和极佳效果的
  • 跟重要合作对象或投资人有关的
  • 跟核心用户利益有关的
  • 跟大部分用户权益有关的
  • 跟效率或成本有关的
  • 跟用户体验有关的

紧急程度按这个排序:

  • 不做错误会持续发生,造成严重影响
  • 在一定时间内可控,但长期会有糟糕的影响
  • 做了立刻能解决很多问题、产生正面的影响
  • 做了在一段时间后可以有良好的效果

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

2. 方案的方向

需求有不同的解决办法,我们会讨论清楚到底用哪种解决。比如我们发现有刷单现象,可以事前提醒,告知用户目前地理位置或订单信息有嫌疑;可以事中限制,必须到达指定地点、拍摄当地照片等等操作来限制用户;可以事后惩戒,提供给客服或者业务部门疑似刷单的名单和证据,罚款或者封号。这几项到底做哪个?还是做其中哪几个?优劣在哪?需要好好讨论。有时会有大概的方向,再去跟相关部门和需求相关的同事确认。这不在本文讨论范围内,暂且不提。

3. 指定负责人

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

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

在我们需求分配时,大致还是按照模块分配,但在出现工作量不平衡的情况时,会酌情调整一下,让活少的同事予以配合。不管怎么样,一定一定要指定负责人,他需要对需求负责,一直到产品上线后,出了的问题他也要承担责任。要保证运营良好的工作责任制。

4. 划定时间节点

许多产品经理会疏漏这点,只是觉得尽快去做,但总是做不完。时间节点至少也要包括方案完成的时间。就是这个需求,能够完好提交给开发的时间。如果没有这个时间,对需求的管理就没有一点意义了。另外,如果是要跟相关部门再确认、或者要跟用户调研、或者要统计各种数据再作判断的需求,那还要有调研 / 讨论完成的时间。

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

讨论完刚刚入池的一批需求,我们会再整理和讨论其它状态(有方案或者调研结论)的需求。这样会议结束,每条需求都会得到更新。我们在这个时刻,一般会让负责的产品经理,及时更新需求状态给需求来源方。当然,来源方 95% 的情况下会对进度不满意,这很正常,但除非来源方有确凿的理由,我们不会轻易调整优先级和时间节点。

三. 待开发阶段

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

1. 方案本身的可行性

在技术方案上,是不是能够完成?就是让技术部门评估这个问题。

2. 有没有更好的方案?

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

3. 涉及的产品和技术环节有哪些?

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

4. 方案的成本如何?

看方案需要多少人、多少资源、多少时间来完成,也要看方案在技术层面耗费的不太明显的成本,比如服务器成本、带宽成本,给用户造成的流量成本等。有了这样的讨论,会议输出的,就是比较严谨的可执行方案(或草稿)了。如果会上遇到各种问题,要确认解决问题的时间节点。

四. 开发阶段

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

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

一个产品的迭代生命周期中,我们究竟有哪些职责?1461587988-9360-0425c

提交开发之后,相当于关闭需求。原则上,本次迭代不再加入新的需求。当然啦,如果什么事情都是原则上那样… 就不会出现这么多扯皮的情况了。在开发中,扯皮的问题归纳起来就是三种:需求太多,没按时做完;需求有改动,导致了额外工作量以及开发的不满;有新的紧急需求,导致发布延期。

这三种问题,再抽象一下,导致的原因很多,大概有几类,分别是:

1. 产品方案不完整

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

之前我们经常出现,做的时候技术才发现卧槽这里有个逻辑没想通啊。然后喊产品来一起讨论的时候,大家发现需要加一些功能才能完善逻辑。最后结果就是周六加了个班,大家很不开心。这种事情也不好追责,毕竟参与者很多,流程拖得很长。硬要说是负责需求的产品经理有问题倒也可以,但总是片面的:他也不一定知道技术上开发才发现的逻辑。后来我们反思,各个流程中的环节都要做一些调整,才能确保最终产品方案的完整:

  • 分析需求时,先梳理逻辑再出方案。能画流程图的画流程图,能画逻辑图的画逻辑图,能画脑图的画脑图,穷举整体的逻辑。
  • 讨论方案时,所有产品经理参与小组讨论,一起提出疑惑,发现问题。
  • 可行性评审时,技术从逻辑角度提出质疑,发现问题。

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

2. 需求方的主观改动

这种情况基本都是需求方或者产品经理的问题:他们在提交方案前没有完全想清楚。有时候都开始开发了,业务部门来人说,哎我们发现这个问题好像不存在了,大家不要做了。他们觉得无所谓,还减轻了开发负担。但对技术部门的同事来说,就好像在说「你被耍了,哈哈哈」。造成的影响是恶劣的。

产品经理在对接他们的需求时要做判断,他们是不是完全想清楚了,是灵机一动的小点子,还是不得不解决的问题。另外,还有一种情况,是需求方跟产品经理对接时出了问题。表述有误,并且方案没有跟他们核对清楚,结果产品功能上线,才发现并没有解决问题。

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

一个产品的迭代生命周期中,我们究竟有哪些职责?1461587992-9928-0425d

3. 无法预测的客观原因

这种是唯一一种能够接受的原因,不需要有谁承担责任。比如,本来要做一个功能狙击对手,结果做了一半,竞争对手倒闭了,那这个功能就没有意义了,确实要废除。还有一些业务上的确无法预测的各种原因,导致原本存在的问题不存在了,也无可厚非。这种情况下,产品经理最重要的是安抚技术的同事,尤其是跟他们解释清楚背景和详细的原因,不要让他们误以为是刚才提到的前两种理由。

 五. 复盘阶段

需求从获取到上线,走完生命周期之后,还要有一个很重要的复盘阶段,尤其是在需求管理出过故障和问题的时候。略靠谱的团队,都会有复盘的机制,主要是防止问题再次发生。解决问题很简单,如何尽量规避下次再出问题很复杂。

大致就是,要搞清楚之前出现问题的所有逻辑和流程,再去看在哪些环节可以做点什么,去防止再次出现。这块的内容说得多了又得写一篇文,就不多讲了。以上就是我的经验,仅供参考。没有什么流程和机制是完美的,关键在于怎么去解决自己的问题。如果哪些思路给你了启发,那就够了。

 

转载注明:云瑞
文章来源:人人都是产品经理
云瑞设计小程序
云瑞设计小程序

微信扫一扫
手机使用更方便!

云瑞设计订阅号
云瑞设计订阅号

关注我们的微信订阅号,不错过任何福利。