需求的整个生命周期中,我们应该做些什么?
1. 获取阶段
需求的来源有很多。业务越复杂,需求就越杂。一个淘宝,产品需求就可以拆分成分类、检索、排序、商品展示、营销活动、支付、配送、售后等等。你的职级越高,也代表着身边人提需求的可能性越大。初入行的产品专员或助理,主要是得到被安排的任务;初级产品经理,需求来源主要是用户和上级;产品负责人,需求来源就要增加老板和其他相关部门; 而作为老板,谁都可能跟他提产品需求。
所以在获取到需求这一时刻,就必须做一个判断,并且记录。如果不做判断堆在那里,等做的时候根本没办法梳理出头绪,可能大部分时间都在疲于折腾需求清单。记录当然是为了方便回溯。获取到的再小的需求也记下来,不要指望你随时能想起来每天听过的每个需求。
做判断的内容具体是什么呢?
第一,判断需求本身的重要性。
同样是页面写错了一个字,把「登录」写成「登陆」,和把「奖励 15 元」写成「奖励 50 元」,重要性不言而喻吧。有个大致的预估。
第二,考虑需求来源。
需求来源会表明一些事情,要慎重思考。比如老板提到的,未必是目前你能理解的,但他认为特别重要,就暂且把这个当成特别重要的,这是政治任务。再比如是用户提到的,但细想他并不是目标用户,他的需求就不必太关注。
第三,简要得到需求背景。
我自己工作中有三类需求绝对不记:没说清楚原因的,不记(你做个 XX 出来,别管那么多);不说清逻辑的,不记(啊,这里我也没搞懂,你先看看);不是实际遇到的,不记(哎,我觉得可能有人会这样用)。
需求背景没搞清楚,完全是浪费时间。有一句话的记录,但不说背景,也是浪费时间。记的时候,我会确保格式是问题 + 方案,「XXX 在用我们的 XX 功能时,感觉 XXX,我们可以尝试 XXX 这样的方案」。最后,依据这三个因素,判断属于大致哪个类别的。一般的需求管理都会分 P0-P3 或者 P1-P4,总之先打个标签。这里的技巧是尽量标记为比估计的更重要一层的需求,就是你感觉是 P2 的,暂且先标为 P1。这样以防错漏,低优先级的标成高的没关系,但高优先级的标低了会出现麻烦。这时候的预估往往不准确,但没关系,等后面第二步再说。比如这样:需求的整个生命周期中,我们应该做些什么?
2. 讨论 / 设计阶段隔一段时间,我们会开需求讨论会,整理需求池,也就是记录所有获取到需求的表单。我们会详细讨论每个需求的情况,确认几个事项:
一,需求的优先级
之前的判断是粗估,这里的判断就要精细了。一般需求的重要程度很难量化,尤其来源复杂的情况下。营销部门着急要我们配合做活动,不做就少赚好多钱,业务部门着急要我们配合做一套自动化结账工具,做了能节省很多成本... 有时抉择很痛苦。
这里还是用最常用的判断方法,紧急重要四象限法则(请自行百度「四象限法则」)。
重要程度大致按这种排序:
不做会造成严重的问题和恶劣的影响的
做了会产生巨大好处和极佳效果的
跟重要合作对象或投资人有关的
跟核心用户利益有关的
跟大部分用户权益有关的
跟效率或成本有关的
跟用户体验有关的
紧急程度按这个排序:
不做错误会持续发生,造成严重影响
在一定时间内可控,但长期会有糟糕的影响
做了立刻能解决很多问题、产生正面的影响
做了在一段时间后可以有良好的效果大家把能考虑到的因素想全,会标上 P1 - P4 的优先级。
二,方案的方向
需求有不同的解决办法,我们会讨论清楚到底用哪种解决。比如我们发现有刷单现象,可以事前提醒,告知用户目前地理位置或订单信息有嫌疑;可以事中限制,必须到达指定地点、拍摄当地照片等等操作来限制用户;可以事后惩戒,提供给客服或者业务部门疑似刷单的名单和证据,罚款或者封号。这几项到底做哪个?还是做其中哪几个?优劣在哪?需要好好讨论。
有时会有大概的方向,再去跟相关部门和需求相关的同事确认。这不在本文讨论范围内,暂且不提。
三,指定负责人
我之前经历过两种需求分配制度。一种是每个人负责的需求范围有清晰的边界,那需求对应哪个模块,就直接分配即可;另一种是团队作战,每次指定或者认领,谁都有可能接手任意需求。
前一种的好处在,模块清晰,负责人可以对自己负责的部分足够熟悉,但缺点是,工作量很可能不平衡,有的同事一直在忙,有的可能就比较闲,因为需求不是平均按模块分布的。在我们需求分配时,大致还是按照模块分配,但在出现工作量不平衡的情况时,会酌情调整一下,让活少的同事予以配合。不管怎么样,一定一定要指定负责人,他需要对需求负责,一直到产品上线后,出了的问题他也要承担责任。要保证运营良好的工作责任制。
四、划定时间节点
许多产品经理会疏漏这点,只是觉得尽快去做,但总是做不完。时间节点至少也要包括方案完成的时间。就是这个需求,能够完好提交给开发的时间。如果没有这个时间,对需求的管理就没有一点意义了。
另外,如果是要跟相关部门再确认、或者要跟用户调研、或者要统计各种数据再作判断的需求,那还要有调研 / 讨论完成的时间。这个时间节点的划定,主要是按照方案的复杂程度,用经验做个简单判断。
最长的时间周期也不能超过一周,保证需求的推动进度,因为很难有复杂程度超过一周的产品需求。对于有严格上线时间的需求(经常会出现,比如很苛刻的老板需求、投资人需求、政府需求等),要倒推出最合理又富有余地的时间节点。
讨论完刚刚入池的一批需求,我们会再整理和讨论其它状态(有方案或者调研结论)的需求。这样会议结束,每条需求都会得到更新。我们在这个时刻,一般会让负责的产品经理,及时更新需求状态给需求来源方。当然,来源方 95% 的情况下会对进度不满意,这很正常,但除非来源方有确凿的理由,我们不会轻易调整优先级和时间节点。
3. 待开发阶段有了确切方案,我们会尽快跟研发的同事做可行性评审。这一步必不可少。我感觉题主出现的「落不了地」和「频繁更改」的问题,要着重在这个步骤里解决。可行性评审上,完成的是对需求的大致评估,要做的有这么几件事:
第一,方案本身的可行性。在技术方案上,是不是能够完成?就是让技术部门评估这个问题。
第二,有没有更好的方案?一定要跟技术部门灌输清晰的需求背景,让他们也想一些可行的方案。方案未必是完整、准确的,但他们提供的思路,一般是可行性较高的。
第三,涉及的产品和技术环节有哪些?这个需要相关的同事仔细讨论。尤其是很多公司产品线比较多,有可能存在牵一发动全身的情况,如果相关的产品同事和技术同事不知情,必然会延期,必然会扯皮,必然会造成麻烦,必然会有各种改动。即便是再小的产品,也要分前后端,让技术的同事来判断有哪些人需要知情和参与评估。
第四,方案的成本如何?看方案需要多少人、多少资源、多少时间来完成,也要看方案在技术层面耗费的不太明显的成本,比如服务器成本、带宽成本,给用户造成的流量成本等。
有了这样的讨论,会议输出的,就是比较严谨的可执行方案(或草稿)了。如果会上遇到各种问题,要确认解决问题的时间节点。
4. 开发阶段
开发需求的次序,我们不是完全按照需求池里的需求优先级来的。刚才说到,在可行性评估会上,我们会核算大致的需求成本,那成本结合需求的优先级,就可以得出需求的性价比了。我在 创业公司产品经理怎么做? 提到过具体的方法,这里不再赘述。大概是用这样的表格:需求的整个生命周期中,我们应该做些什么?
提交开发之后,相当于关闭需求。原则上,本次迭代不再加入新的需求。当然啦,如果什么事情都是原则上那样...就不会出现这么多扯皮的情况了。在开发中,扯皮的问题归纳起来就是三种:
需求太多,没按时做完;
需求有改动,导致了额外工作量以及开发的不满;
有新的紧急需求,导致发布延期。
这三种问题,再抽象一下,导致的原因很多,大概有几类,分别是:
一,产品方案不完整
方案不完整往往是没有考虑全面。这个跟需求管理本身没关系,就是在出方案的途中,看能不能把事情想全。之前我们经常出现,做的时候技术才发现卧槽这里有个逻辑没想通啊。然后喊产品来一起讨论的时候,大家发现需要加一些功能才能完善逻辑。最后结果就是周六加了个班,大家很不开心。
这种事情也不好追责,毕竟参与者很多,流程拖得很长。硬要说是负责需求的产品经理有问题倒也可以,但总是片面的:他也不一定知道技术上开发才发现的逻辑。
后来我们反思,各个流程中的环节都要做一些调整,才能确保最终产品方案的完整:
分析需求时,先梳理逻辑再出方案。能画流程图的画流程图,能画逻辑图的画逻辑图,能画脑图的画脑图,穷举整体的逻辑。
讨论方案时,所有产品经理参与小组讨论,一起提出疑惑,发现问题。
可行性评审时,技术从逻辑角度提出质疑,发现问题。
之后再出问题,会回溯原因。
如果是前两个环节出的问题,那就是产品经理的责任;如果是产品经理**的逻辑,那就是可行性评审中,技术的同事的责任。
二,需求方的主观改动
这种情况基本都是需求方或者产品经理的问题:他们在提交方案前没有完全想清楚。有时候都开始开发了,业务部门来人说,哎我们发现这个问题好像不存在了,大家不要做了。他们觉得无所谓,还减轻了开发负担。但对技术部门的同事来说,就好像在说「你被耍了,哈哈哈」。造成的影响是恶劣的。
产品经理在对接他们的需求时要做判断,他们是不是完全想清楚了,是灵机一动的小点子,还是不得不解决的问题。另外,还有一种情况,是需求方跟产品经理对接时出了问题。表述有误,并且方案没有跟他们核对清楚,结果产品功能上线,才发现并没有解决问题。
我们的做法刚才多少提到了一些:要在任何需求的属性(内容、时间点)发生变化时,跟需求方同步。让他们知道我们的情况,也获取他们的意见和建议。
比如这是我们的需求同步流程:需求的整个生命周期中,我们应该做些什么?
三、无法预测的客观原因
这种是唯一一种能够接受的原因,不需要有谁承担责任。比如,本来要做一个功能狙击对手,结果做了一半,竞争对手倒闭了,那这个功能就没有意义了,确实要废除。
还有一些业务上的确无法预测的各种原因,导致原本存在的问题不存在了,也无可厚非。这种情况下,产品经理最重要的是安抚技术的同事,尤其是跟他们解释清楚背景和详细的原因,不要让他们误以为是刚才提到的前两种理由。
5. 复盘阶段
需求从获取到上线,走完生命周期之后,还要有一个很重要的复盘阶段,尤其是在需求管理出过故障和问题的时候。略靠谱的团队,都会有复盘的机制,主要是防止问题再次发生。解决问题很简单,如何尽量规避下次再出问题很复杂。
大致就是,要搞清楚之前出现问题的所有逻辑和流程,再去看在哪些环节可以做点什么,去防止再次出现。这块的内容说得多了又得写一篇文,就不多讲了。以上就是我的经验,仅供参考。没有什么流程和机制是完美的,关键在于怎么去解决自己的问题。
如果哪些思路给你了启发,那就够了。