产品经理:需求变更是“原罪”?

产品经理在项目进行过程中,常常会X一个重大考验:改需qiú!这也是产品经理经常被攻击的地方。为什么要改?不同阶段的问题是什么?这些都是摆在产品经理面前的一道道难题,本文作者就这些难题分享了自己的看fǎ,供大家参考。

产品从需qiú出发,经过了原型设计、开发排期到测试验收、灰度后上线的过程,可以说经过了较长的一段时间。根据需qiú的复杂程度,产品开发时间可能需要1天、1周甚至1个月的情况。在游戏行业,产品开发周期则更长,多达几个月。

我们可以把产品经理完成的PRD原型,作为需qiú的X。UI设计、开发、测试等部门的同事会根据原型所呈现的效果进行落实。

可以说,产品经理把原型做出来并在评审X后,就成为了一份“纲领性”文件。每个人都会围绕它为中心进行工作。

一旦涉及到需qiú原型的变更,往往是牵一发而动全身。例如:在原型评审后,增加了一个列表排序的工作。这部分的需qiú变更(增加)会造成怎样的后果呢?

  • 首先:UI要根据功能进行重新设计UI图;
  • 技术经理要评估该功能所要开发的时间、难度、成本、可行情况;
  • 测试要根据原型进行测试用例的写作和测试的准备工作;
  • 如果功能联动到其他X情况,牵扯出来的情况就更多了。

毫不夸张的是,需qiú变更更像是一种“原zuì”。

每次产品经理在进行需qiú变更后,往往开发同事是一脸懵bī的,表现出“一开始,我是拒绝的”的态度,除非你能说服利益相关方。

原型的变更往往不都是产品经理背的锅。虽然需qiú变更可能导致开发效率的落后、产品的延期、工作气氛的X影响、团队和谐程度下降等等,这不意味着需qiú变更就是错误的。

有某些情况下,需qiú变更意味着产品X接受市场环境变化的不确定性,所采取的有效措施,让产品跟得上市场的变化,这是一种“利”,而不是“害”。

一、需qiú变更的原因

明确了这点,我们再来讨论:需qiú变更是什么原因导致的?

需qiú变更的原因,主要有几个方面:

  1. 产品经理原因
  2. 开发或其他部门的原因
  3. X的原因
  4. 市场/用户的原因
  5. 客观原因(或者不可抗拒原因)

下面逐一解释:

1. 产品经理原因

这部分的原因往往是因为产品经理本身想不清楚需qiú、定义不清楚需qiú,导致了需qiú在开发过程X现许多问题。

例如:比如,笔者所做过的一个项目中,涉及到zhēn对某些渠道的扫码关注情况的统计,需使用一个概念把所有相关渠道进行概括。当时我会把所有的相关的渠道都一一列出来。

如果我在产品原型里,对需qiú的定义模糊其词,仅定义为“把涉及到这部分的相关扫码渠道都进行统计”,但并不列举是哪些渠道。开发自然会懵bī。如果开发工程师把你的表述理解为了其中一个渠道,那么造成的后果是统计有缺漏,反应的数据情况自然是不准确的。

再举个反面例子:

例如:当用户X了某电商产品并支付完成后跳转页面,弹出了二维码。用户扫码进入该电商平台X号-X关注,产品经理在用户关注后并不做任何的X号弹出的提示cāo作。这就是定义不清晰、想不全面。

最后的结果就是:用户关注了你的X号,但实际上最后一步的漏斗转化就缺失了,白白liú失了这部分用户的进一步转化。

2. 开发或其他部门的原因

这里更偏向于开发部门,其他部门则指客服、运营、X、财务等部门。开发部门导致的需qiú变更一般会比其他部门的多,但这块也要根据XX重点情况,不能一概而论。

产品制定了原型并进行了评审后,进入了开发阶段。有些情况下,需qiú的变更不是在评审时发现的问题,而是在开发时。

例如:不断数据表之间的多层嵌套、异步特征导致数据加载延迟等情况,这些在产品体验层面是致命伤。当然也不可能进行开发落实。

例如:某个数据页面加载的时间,按照原型的不同数据方案(同步或异步读取混合),导致用户能在页面上看到的时间为15s,虽然可以进行前端的提示,实际上会吓跑用户。我们在使用各种不同app,在等待页面过程中大概10s左右就会不会有不耐烦的表现呢?15s?20s呢?

因此,开发上能实现但造成产品体验的问题,也会导致需qiú的变更。上述案例中,变更后的需qiú,对异步的数据分开统计,并加强产品提示,弱化数据入口等方式,从而减少用户等待的期待。这样的变更就是可以接受的。

除了开发部门之外,诸如运营部在准备活动、临时通知、运营功能临时增加等情况下,就会造成需qiú变更。

测试部的变更情况,在笔者的实践看来,更多的是从测试难易程度的角度给出的产品优化建议。注意:测试本身是懂技术的,这部分的变更实际上如果测试能X较好的方案,产品的需qiú变更也在考虑的范围了。

3. 财务部门的原因

这个笔者也跟财务打过交道,财务部门所提出的优化建议往往涉及到有效的对资金进行处理的效率,这部分也需要进行特别的考虑和评估。有时候你所做的优化往往是财务比价迫切的,对需qiú进行变更,其实带来的是财务、财务对客户等方面更高的效率。

由于财务并非X于产品的设计,在开发成本和需qiú之间,产品经理仍然要做好需qiú的把控。

当然,还有其他情况,例如客服部门、新媒体部门等,这些都有可能会给产品提出一些优化建议,导致需qiú变更的情况。

4. X的原因

这可能是X策略的改变,所以需要对产品进行修正、甚至重构的过程,也可能是上级X根据其意愿所安排的需qiú变更。

总而言之,这往往意味着命令的特性。我们需要对此进行充分的了解和沟通。

5. 市场/用户的原因

例如:产品经理要zhēn对某个社区功能进行排行榜的设计,用户要增加积分功能、要发放X、要每曰的打卡行为特征…要知道,排行榜所能承载的功能非常多,不可能把所有的功能都进行设计。

而用户的建议则是根据其本身需qiú进行的判断,更有X性。人是需qiú的X体,而我们所做的产品是为了满足用户的需要一旦用户提出了这个需qiú,我们恨不得马上帮他们解决,满足了这部分用户的需qiú,就能满足了用户,提升满意度。这里也是产生需qiú变更的地方。

其他的:竞品、市场动态、X趋势等方面,都有可能造成需qiú变更

6. 客观原因(或者不可抗拒原因)

这里往往是因为底层技术的X、X器、开发成本、资源X等方面的原因导致需qiú变更(比如砍需qiú、对需qiú进行成本分析,找成本少的先实现)

以上列举的6个方面产品需qiú变更的原因,但是秉持这“ 先内因后外因”的处理角度,笔者建议在需qiú变更的原因产生时,要经常从内因、从自我本身的角度,对产生需qiú变更进行反思和分析。

二、产生需qiú变更的时间阶段

我们进行对需qiú变更的原因的分析,其实还可以从需qiú的不同时间阶段角度进行分析。

我把产生需qiú变更的时间阶段分为以下几个:

  1. 产品规划阶段
  2. 原型阶段
  3. 评审阶段
  4. 开发前阶段
  5. 开发阶段(初期)
  6. 开发阶段(中期)
  7. 开发阶段(后期)
  8. 测试阶段
  9. 灰度阶段
  10. 上线后

前2个时间阶段是由产品经理定夺,算不上需qiú的变更,但涉及到其他角sè的参与,也算在内。

根据不同阶段所产生的需qiú变更,其应对的行动自然也会不同。产品经理要推动需qiú变更后的落实,往往由于开发、测试、UI或者利益相关方的X而失败。

也就是说,如果需qiú变更是科学的、合理的,产品经理以解决问题为己任,因此,推动变更成为了产品经理所必须背负的一个“锅”。

如果需qiú变更后,产品经理如何进行推动和落实呢?这里有一份笔者总结的“需qiú变更落实难度”的模型,仅供参考。

需qiú变更落实难度模型

从图中可以看出,星级越少,则变更后的需qiú的落实难度越小,而星级越少的大部分是在产品还没有开始开发之前。

因此,产品经理如何把需qiú变更的可控范围缩小到开发前,自然会减少了需qiú的落实压力。

三、建议

事情往往不是我们所想象的那么顺畅。无论是在哪里阶段进行的需qiú变更,笔者有以下的一些建议:

  1. 提升产品能力。要把产品想清楚,逻辑、产品设计、需qiú定义等能力;
  2. 提升项目把控能力。把产品当做项目,那么,就需要你对项目进行有效的把控;
  3. 提高眼界。充分xī收外界优秀的需qiú管理思想,提升对需qiú的处理能力、提高自己对产品的构造力,站得高才能看得远。在良好的产品架构下,会减少很多的无用功。

注意,我们要做的不是避免变更,而是科学的变更;把“原zuì”减低到最小,充分理解并践行需qiú变更后的优势,提高需qiú变更后的落地能力。

需qiú变更是无止境的,但只有充分保存自我的”定力“,才能在工作中游刃有余,立于不败之地。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 产品经理:需求变更是“原罪”? https://www.xiongfawang.com/3787.html

常见问题

相关文章

产品经理:需求变更是“原罪”?-海报

分享本文封面