优化需求到底算不算新需求?

0 评论 10177 浏览 38 收藏 13 分钟

不少公司的产品经理都有考核指标,有的是和产品数据关联,有的是和需求关联,比如新需求数量等等。那么,优化需求算不算新指标?怎么去做?这篇文章,给我们答案。

有位小伙伴提了个问题:

项目已经进入试运行阶段了,但客户方一直在提新的需求。项目经理和产品经理一致说,项目已经上线,现在提的需求应该属于新需求,要重新评估工作量。

但客户却说:这不算是新需求,是因为你们没做到我们之前想要的功能。

所以,这一类没有做到预期的功能优化,到底算不算新需求呢?

我觉得这是一个非常复杂的问题,我将从以下七个层面来分析:

一、产品的盈利模式

《麦肯锡结构化战略思维》中始终强调“明确定义”的重要性。所以在讨论这个问题时,我们同样要明确一个定义。

即产品的合作模式是什么?是订阅制?项目制?还是人月制?

大多数遇到类似问题的情况,都是项目制的合作,即定制化合同。

因为订阅制基本是以产品自有迭代周期为基础,客户的需求需要经过产品团队的过滤筛选,最终形成产品迭代的自有需求,产品研发团队的需求自主权相对较高。

人月制则是打多少卡结算多少费用,只要人在这里,你说怎么改咱就怎么改。

所以,只有在定制化合作的商业模式下,项目金额是固定的,甲方肯定想功能越多、越好用,乙方肯定想工作量尽量少,利润空间尽量大。

于是,虽然看起来目标都是做好项目履约,但在很多细节上,因为出发点不同,导致预期不同。

而需求,是项目的源头,自然经常产生争执。

况且,项目制的合作,还需要考虑持续合作的空间。因为不是一锤子买卖,导致很多问题都要考虑后果。

我说这些,一方面是为了强化“问题定义”的意识,另一方面也是表达这类问题很常见,产品经理遇到之后,大可不必劳心动气,因为这些问题,就是需要我们去解决。

二、售前和交付之间的差异

“实物与宣传不符”,是造成这类问题的重要原因。因为售前阶段对用户预期的培养过高,导致用户看到实际交付物之后存在心理偏差。

当然,从不同的角色角度来看,售前阶段为了拿标,基本都会提高用户预期,但中标之后,一定要和交付团队做好交接,把已经挖的坑亮出来,别藏着。

关于这个话题,可以看一下之前写的售前到交付工作交接的历史文章(8000字干货:从售前到交付,一场以交接为主的修行

因此,有些售前承诺但并未体现在合同里的,或者合同里写的比较模糊,但售前时确实说过的,从隐性契约精神来看,还是要尽量满足。否则可能影响乙方公司的口碑,进而影响到其他项目、其他客户。

当然,同样的需求有不同的解决方案,至于工作量的多与少,可以参见下文第五条。

三、甲乙双方的信任关系

很多问题,说到底是信任度的问题。虽然不同的人,脾气秉性不同,但如果你前期与客户建立了良好的信任关系,这些问题都有很多可操作空间。

所以,当出现问题的时候,已经有点晚了。但也没有很晚,毕竟事情还没有上升到无法挽回的境地。

就像我们生病一样,生病一定是之前自己对某些方面的关注度不足,但生病本身也是在提醒自己多多关注某些方面。

甲乙双方的信任关系和项目进展情况也是相互影响,相互促进的。我经历过依靠产品经理扭转客户态度的实际案例,也经历过把一手好牌打得稀巴烂的情况。

所以,回到今天的主题,关于新增需求和优化需求的界定,本应该有很大的协商空间才对。

如果没有,那一定是之前就已经出了问题,而且这个问题一定不仅仅表现在需求层面,可能后续的验收、收款都会举步维艰。

当你所处的团队与客户方关系出现问题时,采用私下缓和关系的方式,逐个击破或旁敲侧击,通过自己的专业能力,或者你退一大步,他退一小步这样的条件置换,才是更要紧的事情。

切不可过于纠结于细节,除非领导授权。

四、客户需求洞察

今年我经常在不同的渠道需求洞察,因为我真的觉得它特别重要,是一种非常关键的产品思维,是做好产品经理所必备的能力和习惯。

当客户说想要优化某个需求的时候,到底是因为什么?

可能是为了和合同保持一致。尤其是很多体制内的老员工,非常认真,同时也担心担责,不管合同或需求说明书中写的对不对,都要按照这个内容做。

可能是产品的功能确实不好用。有很多甲方比乙方的产品经理在业务专业性上要强很多,所以他们能够发现产品中的问题。这种情况,只能怪自己技不如人。

另一方面来看,这是一个快速提升的机会,要紧紧抓住。

可能是客户在自嗨。提需求的人,无论是谁,都可能陷入盲目自嗨中,提出一些伪需求。这就需要产品经理通过有效的需求洞察辨别这个需求背后的“场景”、“痛点”、“目标”是什么。

之后来分析现在这个需求是否能够实现背后的目标?

就像你的需求是让张飞买剃须刀,如果他真的买了,那我们真是产品界的奇才。但张飞真的有必要买吗?

(当然,这个问题和经典面试题:如何把剃须刀卖给张飞,并不冲突,只是两者的出发点不同)

也有可能你没有get到客户所提需求真正的原因。就像去年的文章中提到,客户让你去买水,并不一定是口渴了,可能还有其他原因,最终的表现形式是:买一瓶水(从收到需求到明确需求——需求洞察)。

因此,需求洞察是在与客户“争执”是否为新增需求的前提。只有搞明白对方到底想要什么,才知道哪个方式更有效。

五、产品经理解决方案能力

如果客户始终坚持这是优化需求,我们也可以通过自身的专业能力,让优化需求改动量要么更小、要么更合理。

这一步有几个前提:

  1. 产品经理对现有业务和系统现状很熟悉,知道改动过程中可能存在什么风险,或者能够通过底层设计逻辑寻找更简单的改造方式;
  2. 产品经理在团队内部有话语权,否则优化过程中一定会四处碰壁,相互推诿;
  3. 有一定的技术思维,能够初步评估不同解决方案所需的改造工作量。

这三点其实可以汇集为一点:这个产品经理经验丰富,能力强。

当然,实际工作中,类似的问题很多人都会直接上升到领导层或商务层,通过公司的力量来解决。这种方式本身没有问题,只是对于我们产品经理个人而言,缺少了一些可以尝试、可以锻炼的机会。

通过困难收获的成长,速率还是很快的。

六、优化的边界在哪?

即便是功能优化,同样的坑也不要掉两次。原需求范围没有框定清楚,优化需求的范围一定要协商一致。

另外,这些优化功能同样需要进行工作量评估,即便客户现在没有结算,我们视其为沉默成本,后续迭代新合同时,如果客户信任感又重新建立起来了,再把工作量补回来也未尝可知。

七、关键问题是什么?

我觉得出现这个问题的本质是团队内的需求管理流程出了问题。

需求分析阶段无论客户是否参与,需求评审时双方一定没有达成一致(5千字拆解【需求评审】,让评审效果最大化)。

或者后续需求变更的流程不规范,无迹可寻,无证可依。

也可能因为双方人员变动、工作交接没做好,导致大家认知不一致(工作交接中的“交”与“接”)。

等等这些问题,其实都是产品经理的问题。

八、写在最后

很多朋友会提到“契约精神”这个词,我觉得要从两个方面来看:

  1. 产品经理不要主动、多次和客户方提合同范围,提合同边界。因为如果真要较真起来,那一纸合同中没有约定的功能可太多了,客户随便提一些问题,就够产品经理和项目团队喝一壶的。
  2. 大部分客户也是讲究契约精神的,即便偶尔会较真,会为难,但他也需要为自己的企业负责,也需要为自己的项目结果负责。毕竟,大家都是为公司做事。

所以,优化需求到底算不算新需求,这个问题我说了不算,你说了也不算,但我们可以通过很多行为,让说了算的人,按我们的设想计算。

我最终的观点可以概括为一句话:

先退一步表态,再通过专业性缓和关系,以需求洞察为基准,寻找双方都满意的方案,最终促使客户退一小步。

不过要记得,下一个周期,从售前便开始抓起,共建信任关系。

专栏作家

不想延期,公众号:不想延期,人人都是产品经理专栏作家。半路转行的B端泛金融产品,坚持“以实践验证理论,以输出倒逼成长”的目标。点滴珍贵,重在积累

本文原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 目前还没评论,等你发挥!