不涉足RDMS太多,不代表不需要关注RDMS—浅谈各种开发流程模式对产品经理的影响(I)

在《【模板】产品管理的文档,看板,选哪一个?成熟的产品经理才不会做选择题!》这篇文章发布后,有朋友在群里说,汤圆,你敏捷应该玩的很六吧,我只能实话实说,敏捷产品管理还凑合能应付,敏捷开发就只懂点毛了,皮都碰不到,毕竟作为产品经理,更多的工作还是放在PMS和RDMS接口的协作管理工作上,并不会涉足太多、太深研发体系具体的操作层面的事情。

当然,和RDMS的伙计们接触的多了,有些东西也多少了解一些,比方说最影响产品介质产出的研发流程,在本文中呢,我就站在一个产品经理的角度和朋友们分享一下,就目前常见的研发流程的优缺点,以及给PMS中的我们都会带来哪些影响和我们的应对方案。


产品经理为什么要了解RDMS流程


先来回答这个问题。

按照通常的协作要求,产品经理只需要把定义好的产品介质规格(呈现形式可能是多样的,文档,原型、图纸等)交付RDMS就可以了,然后RDMS就会基于他们自己的一套流程开展研发,生产等方面的工作,我们只需要做好接收可商品化产品介质的准备就可以了。

但是,我们提供给RDMS的只是一个针对产品介质的解决方案,技术解决方案的设计以及最终可商品化产品介质的产出完全就要依赖RDMS自身的流程来推动和实现。

也就是说,如果没有一个靠谱的RDMS流程来支撑产品解决方案的实现,那么,我们针对产品介质的一切构想就很有可能永远是纸面数据了。

因此,产品经理有需要,也有必要对企业内实行的RDMS流程有一个全面的了解,知道它们是否能够更有效的对产品解决方案的实现提供足够和必要的支撑。

整体来看,产品经理了解RDMS的流程,有以下三个关键作用:

1)确保产品介质的产出效率

对于PMS而言,体系中产品的管理效率来自各个业务体系的效率之和。

从整个产品管理周期来看,RDMS流程的效率绝非只是影响产品介质的产出,它的效率高低会直接影响到后续体系(比方说MMS)开展工作的效率和质量,因此,作为产品经理,就必须要了解RDMS的流程对产品介质的产出效率是什么样的影响,从而确保我们整个产品管理周期的效率能处于一个良好的环境中。

2)确保产品介质的产出质量

通常我们会认为流程只对效率有影响,事实上流程同样会对产品的质量产生影响。

比方说,我们都知道的一点,RDMS要对产品介质进行技术解决方案的设计,而这个设计的前提是要解决消费者的问题,如果缺乏合适的流程支持,那么,我们是没有办法确保RDMS设计出来的技术解决方案是能够更好的解决消费者问题的,这也必然会影响产品介质最终生产出来的质量的。

3)确保成本和风险处于合理水平

RDMS是一个典型的成本导向的业务体系,而这种成本最终必然会在产品的定价中所呈现,而对于很多产品的产品经理来说,价格是否有竞争力,很多时候就意味着产品是否有竞争力,同样,RDMS工作中的风险其实并不会完全在体系内部消化,风险依然会进行转移,因此,如果我们不了解RDMS的流程,那么,一旦出现高企的成本和严重的风险,我们将无法判断它们的出口应该在哪里。


常见的RDMS流程—瀑布开发流程对产品经理的影响


简单了解瀑布开发流程

一说起瀑布开发流程,很多IT行业的朋友认为这是他们的专有流程,但事实上并非如此,它事实上是一种适合于几乎所有产品的,典型的开发流程。

为什么这么说呢?先来简单了解一下在IT行业中,它所涉及到的五个阶段:

1、需求分析和定义阶段:针对用户需要形成产品规格;

2、系统和软件设计阶段:分解为可以单独开发的模块,形成每个模块的规格说明;

3、开发和单元测试阶段:针对每个模块进行编程并进行独立测试;

4、集成和系统测试阶段:对模块进行组装,并对系统进行测试;

5、操作和维护阶段:对出现的错误和偶尔的变化进行改进。

看起来基本上都是IT产品,尤其是软件产品的技术术语,但是,如果我们对此流程的关键步骤浓缩的话,这五个阶段用十个字就概括了:定义;设计;开发;测试;维护。

从这十个字来看,瀑布流程还是IT产品的专有流程吗?

几乎所有的产品都可以,或者就是按照这个流程在做,如果用一段通俗的话来呈现的话,无非就是:

在定义好的五个阶段下,产品从需求的书面描述开始,先设计,然后是开发,然后是测试,最后是上市或发布后的维护。

在每个阶段的末尾,都有对该阶段的可交付成果的审查,然后是签字和对下一个阶段的明确过渡。

想一下,汽车是不是这个开发流程,家电是不是这个开发流程,就是一片面包都是这样的开发流程。

因此,与其说瀑布是一种开发流程,不如说瀑布是一种开发原则或思想,它可以在不违反核心原则的前提下有各种延伸和变形,并适合的应用到各个行业。

比方说SR(Successive Refinement,连续细化)、SDLC(Software Development Life Cycle,软件开发生命周期)、门径管理(Stage-Gate)、阶段评审(Phase Review)、阶段合约(Staged Contracts)、BLIP和基于里程碑的(Milestone-based)。

瀑布开发流程的优势我们不用多说,无非就是管理层可以对整个可感知的过程有预判,在每个阶段都有可交付的成果等等。

关键是瀑布开发流程的问题会给产品经理的工作带来哪些影响。

瀑布开发流程带给产品经理的影响

影响1:产品的验证在开发流程的尾声才会有结果

按照瀑布的开发流程,至少得到了第四个阶段结束,才真正会出现一个可以正常运行的产品,从企业成本的角度看,这就是在投入了大部分成本后,却很难在短期内看到一个实际的产品效果。

而对于产品经理而言,就必须确保在瀑布开始之前,产品能够有一个可以被目标消费者测试的准确原型,并进行规格化,从而使最终提供给RDMS的产品规格是经过了目标消费者验证的。

简单说,就是在流程开始之前,你作为产品经理,必须确保你的产品规格是准确,且被目标消费者认可的,这事实上是一种理想的状态,现实效果我们都很清楚。

顺便说一下,也正是因为这个问题,才有了后来的MVP,关于MVP的介绍,大家可以看这几篇文章:

【系列专题】这就是MVP的感觉-产品管理如何应用MVP的逻辑:(1)、(2)、(3

【推荐】MVP已死,有事烧纸?

【推荐】MVP,让我欢喜让我忧!

影响2:所有的阶段性的改变都是高成本的

如果严格遵守瀑布的流程,那么,一旦上一个阶段的成果被下一个阶段接收,那么,也就意味着上一个阶段的结束和对下一个阶段的封闭,因此,如果要对前一阶段成果的任何改变都会破坏流程的稳定性,并造成相当大的痛苦和成本,因为我们不得不需要审查和重新工作。

比方说,在编码和测试过程中,经常会发现需求和体系结构中的问题,这些问题可能会在整个过程中造成重大的延迟和痛苦。

而现实的情况是,产品经理是市场和客户的代表,有时候不得不对需求进行修改,而这种修改的成本肯定不仅仅会覆盖到需求修改(通常为需求变更)上,还要包括因为修改而造成的延迟成本,以及更正后续产品的成本。

当然,很多朋友会说,把修改放到下一个产品中,这似乎是合理的,但是我们必须思考,到底哪一种方法会让修改成本更低。

影响3:上市时间的延迟

我相信,99%的产品经理几乎没做过一个不延迟上市的产品。

即使在做进度安排的时候,我们会打出预估时间量的15%作为冗余,但多出预估时间量的一倍,甚至两倍都不鲜见。

根本原因还是在于阶段性的修改造成整个流程的延迟,成本增加只是一方面,很多时候可以内部消化,但是上市计划(也就是从RDMS交付合规的产品介质给产品经理,产品经理对其进行商品化,让产品具备可销售价值的这个过程,大致需要2-3周的时间)的延迟则几乎会影响到全套体系的计划,对于大部分的企业而言,这应该是很难接受的。

而要避免这个问题的出现,压力自然就又落到了产品经理身上,就是第一个影响中提到的,我们必须确保交付给RDMS的产品规格是经过目标客户验证,且不会有大的变化的。

老天就是这么爱捉弄产品经理,有意思吧。

个人感想

我们似乎可以这样来看待瀑布开发流程,它是一种典型的具有理想主义色彩的开发流程,对于产品经理而言,它要求我们能够预测消费者的关键问题并完全理解他们的需求。

不幸的是,几乎所有的产品很少出现这种情况。实际的情况是,由于对需求的修改,产品的上市、发布总是不能如约而至,更为严重的,一旦真正的用户有机会看到并使用实际的产品,我们就不得不需要花费大量的时间和成本来进行后续发布,以纠正问题。

而要彻底解决这个问题,就要求产品经理,必须确保产品规格在进入到流程开始之前得到足够验证,从而为RDMS团队节省大量的时间和成本。

而具体到实际工作上,就是要求我们的PRD能否写的正确,准确,明确。

当然,我们不能说瀑布开发流程就要成为历史名词了,对于一些特定的产品,这个流程还是相当适合的,比方说大型系统工程,或者产品很小,需求清晰的这样的产品项目。

不过想想也是,瀑布开发流程最早就是在《管理大型软件系统开发》(Managing the Development of Larger Software Systems)中提出的。

既然瀑布开发流程有这样的问题,那是不是现在大行其道的Align就可以一劳永逸的解决瀑布的问题呢?

在下一篇中,我就聊聊Align带给产品经理的影响都有哪些。

分享到QQ 分享到微信 分享到微博

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址