如何看待“产品经理总是改需求”这件事?

01

“产品经理总是改需求”,是“产品经理”最出圈的刻板印象之一。

这个印象,或者说这句牢骚,显然最开始是出自于程序员圈子。

因此,“需求”这个概念,就可以简单地理解为“产品经理要求技术团队开发的任务”。

那么,“改需求”,就是“变更任务要求”。

根据我的经验,程序员抱怨“改需求”,一般会是下面的这2种情况:

  1. 在一个开发周期内,产品经理已经将开发任务安排下去,项目已经进入开发阶段了,这时产品经理要改需求。
  2. 项目上线运行没多久,产品经理要求在下一个开发周期对这个项目进行修改。

其中,容易引起程序员不满的是第1种情况。一般说“产品经理改需求”的,大多也是指的第1种情况。

02

导致改需求的原因有很多,而首当其冲的就是,产品经理策划时考虑不周全。比如,模块前后矛盾,某个对象状态缺失,交互设计不合理,等等。

对于刚入行的朋友,我建议你要把关注的重点放在这个上面。

一个产品经理,如果交付的PRD始终错漏百出,那他肯定是走不长远的。

至于其他原因,比如领导改变主意、合作方有新要求、市场环境变化,等等,大多不是产品经理所能控制的。这里就先不讨论了。

策划时如何考虑周全,是一个非常复杂的问题,三言两语说不明白。这只能自己慢慢摸索,并不存在一步登天的捷径。

这里,根据我的经验,分享2点建议。这些是我认为比较重要,但网上却少有人提及的。

1. 通盘考虑项目在不同平台上的实现形态,尤其要关注各个平台自身的特殊情况和特殊要求

公司产品,一般会有PC端、触屏端、安卓端APP、iOS端APP,有时还会有微信小程序。其中,触屏端,还需要特别区分“微信框架下”和“非微信框架下”。

比如我们要做一个专题,这个专题将会放在触屏端和APP端。那这个专题的“分享”功能需要怎么策划呢?

首先,APP的分享模块,一般是原生的。形式大概是底部弹窗,在弹窗内选择“微信好友”、“微信朋友圈”、“QQ好友”、“QQ空间”等方式。出于成本考虑,安卓端和iOS端,会采用一样的设计,不用分开讨论。

然后,再看微信框架下的触屏端。因为我们无法调起微信的分享模块,所以形式上就不能是底部弹窗,而是需要做一个遮罩层,提示用户自行操作分享。

最后,我们来看非微信框架下的触屏端。这个就非常复杂了。因为你无法确定,用户到底会用什么浏览器去访问。所有浏览器都分别进行适配,又非常麻烦。这种时候,出于成本考虑,就要想,是不是可以把非微信框架下的分享模块给隐藏掉。

类似的,我们在策划的时候,需要通盘考虑不同平台的情况,分别进行应对。

如果你的公司同时有多条产品线,或者和其他公司有商务合作,那就更复杂了,要根据公司业务情况综合考虑。

2.确保自己已经正确掌握产品当前的真实状态,尤其要注意以前做过的特殊处理

时不时会有这样的新闻,一个小小的突发事故,就给某公司的软件系统造成巨大的伤害。然后大家突然发现,这家公司外表光鲜亮丽,然而内部极其混乱,系统里不知埋了多少坑。

其实,这种情况并不鲜见。尤其是在各种普通小厂,几乎是一种常态,只是暂时还没暴雷而已。

因此,具体到产品策划,你不能理所当然地认为,公司的产品有在正常有序地运转着。反而是,很有可能在你不知道的地方,产品已经出问题了。

  • 比如,某个功能,上线的时候好好的,后面不知道哪次更新,就给覆盖掉了,没人知道。
  • 比如,某次开发,为了赶工期,只上线了部分内容,剩余部分计划以后再改,但是至今一直没有搞。
  • 比如,开发某个模块时,把另一个模块给搞坏了,然后进行了紧急修复。至于是怎么修复,没留下文档。
  • 比如,原来负责的程序员离职了,接手的人看不懂上一任的代码,改着改着就面目全非了。

如果你不是在知名大厂,那么这些情况,基本都是日常。

所以,策划时,就需要自己先实际去跑一遍产品相关模块,确保自己已经正确掌握产品当前的真实状态。无法直接在前端页面确认的,需要找到相应的程序员,通过查代码来确认。

只有前提条件对了,后面的推演才有可能是对的。

03

一旦程序员开工了,再让他修改,都可能把他惹恼。

所以,很多产品新人,在对接技术的时候,总是战战兢兢的,生怕哪句话说得不是,就把人家给惹恼了。

其实,大可不必如此。

改需求,是一件很频繁的事情。也就是说,是产品和技术工作中的日常。就这么一项日常的工作,每次都要发火、怼人、吵架,你觉得可能吗?如果真是如此,公司早就倒闭了,员工早就因打架斗殴而实现“财务自由”了。

实际工作日常,并没有段子那么有戏剧性。

比如说,曾有一次,我要求新增一个移动端的页面。这个页面有2种状态(假定用“A”和“B”来表示)。当用户访问时,A账号显示A状态,B账号显示B状态。

然后,我要求,当用户点击“返回”时,要回到他进入时候的页面。从首页进的要回到首页,从会员中心进的要回会员中心。这个很好理解,也没什么不合理的。

但是,在具体实现时,却出现了问题。

接手的程序员不是做一个有“A、B”2个状态的页面。而是做了2个页面,A页面对应A状态,B页面对应B状态。用户访问时,默认进入A页面。如果是B账号访问的,那就在进入A页面的瞬间,自动跳转到B页面。

这样看起来也是能满足要求的。

但是,我在验收的时候发现,当B账号用户要从B页面返回时,因为他是从A页面来的,所以按照我定的要求,会跳回A页面。可他刚进入A页面,A页面就会启动判断机制,自动又给跳回到B页面去了。

那么,从用户的角度来看,就是,点了“返回”之后,一直在B页面转圈,回不去了。

这可怎么办呢?

页面做都做了,没办法。我只能修改要求,改成把返回路径写死,统一跳转到会员中心。

以上这样的例子,其实才是日常工作中的常态。

没有段子里面写的那种剧烈冲突,也没必要去追究是谁的错。大家都是为了完成项目,出现问题互相协商解决,仅此而已。

所以,当你要进行需求变更时,不需要有太大的心理负担。

而且,技术团队普遍开发任务重。所以,能否准确快速地了解需求变更的内容,才是程序员真正关心的事情。

04

作为产品新人,很可能你的第一件工作,就是“改需求”。

你刚入行,还没法独立地去做一个需求。这时候一般会把其他产品同事手上的项目,分给你跟进,算是练练手,熟悉一下工作流程。

这个项目,不会太复杂。但是,也不至于简单到可以放着不管。

你在跟进过程中,大概率上还是会遇到一些问题的。而你人生的第一次“改需求”,很可能就发生在这个时候。

还没学会怎么“提需求”,就要去“改需求”了,你肯定会感到措手不及。

这里,我总结了4个要点,希望能给产品新人提供一些帮助。

1. 等到相关干系人明确说出“要改需求”,才可以行动

需求变更,是一件非常容易造成混乱的事情,所以必须要事先确认清楚。最好能得到公司领导,或者需求部门主管的确认。再不济,至少得找需求经办人确认。

同时,需求变更,意味上线时间可能推后,或者程序员需要加班赶工。严格来说,产品经理并没有做出这种决定的权利。只有领导确认了,你才得到了授权,才可以行动。

2. 严格按照公司的需求变更规范去做

需求变更是一件经常发生的事情,任何公司都不可能一直让它处于失控的状态。

所以,每个公司,多少都会对需求变更有一些规范要求,有些是明文规定,有些是约定俗成。

这些规范,不一定完全合理,但肯定是公司团队在实际工作中提炼出来的最优解。

如果不按公司的规范流程来,责任的问题就先不谈了,你很可能会出现重大的疏漏。

最常见的,就是没有通知到所有需要通知的人。比如有个程序员没通知到。或者开发团队都通知到了,但把测试团队给漏了。

3. 尽量先改PRD,把变更落实到文档中

除非特别紧急,否则,每次改需求,要尽量先改PRD。产品文档更新后,再连同变更的需求发给相应同事。

要知道,项目的各个模块,往往是互相关联的。改动一个地方,很可能会影响到其他地方。在变更需求的时候,是很容易出现遗漏的。

而当你去更新PRD时,会比较容易进入策划时候的思路,比较容易发现那些被遗漏的地方。

另一方面,如果后续出现争议了,这个修改好的正确的文档,还能保障你的生命安全。

4. 所有的变更,要亲自和每个程序员说明清楚

改需求的时候,因为害怕被怼,不想直接面对程序员,这点不是不能理解。

但是,哪怕你严格按照公司的规范流程、准确全面地表达变更内容,在需求变更的过程中,还是很有可能出问题的。因为需求变更,本身就是一件非常容易造成混乱的事情。

而作为产品经理,这个时候,你是最了解需求的人,同时也是对当前每个程序员的开发情况了解最全面的人。所以,你必须亲自去跟每个程序员当面说明情况,并解答他们的疑惑。

只有这样,才能最大限度地避免出错。

05

最后,我们再回过头来,重新看看“产品经理总是改需求”这件事。

虽然主语是“产品经理”,但这并不是产品经理一个人的事情。

它本质上是一个系统性的问题,是协作机制内在缺陷导致的,是团队中所有人共同作用的结果。并不是我们这些初级产品经理有能力解决的。

我们在进行产品策划时,首先要做的就是明确需求的范围。

同理,我们在工作时,也需要去明确自己的工作职责和工作范围。不是把全部事情一股脑都揽在自己身上,而是应该去寻找自己能控制的局部,去优化可控的部分。

后记

大家好,我是Minami,一个普通小厂的4年产品人。

说来惭愧,我没进过大厂,只能混迹在各种不知名的普通小厂。也正因如此,我发现,前辈们分享的一些优秀产品经验,离开了大厂理想的环境之后,其实非常难应用到自己的日常工作中。

所以我想分享一些来自普通小厂的经验教训,给刚入行的朋友提供一个不一样的视角。

我不是产品大牛,只是作为一个普通产品人,分享一些日常的思考总结。如果能帮到你,非常荣幸。如果哪些说得不对,欢迎你留言赐教。

 

作者:简明产品论;简明产品论(ID:JianMingPM)

本文作者 @简明产品论 。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部