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

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

通过以上两篇文章的介绍,我们知道了瀑布过于强调阶段和流程,敏捷过于强调个人,从管理的角度看,就是前者太偏重组织驱动,后者太偏重个人驱动,从人性的角度看,就是前者在压制人性,后者则释放人性。

这个问题其实不仅仅存在于研发管理上,现代管理思想发展了100多年,其实本质上都是在不断研究组织和个人的关系。

理想中的管理实践是最好能兼顾组织和个人的,但现实中,却很难有这样完美的管理体系,因为人性是追求自由的,而组织本质是限制自由的,因此,所有的管理思想都只能在这两者之间尽量折中。

因此,在本文中,我们就来聊一个折中了瀑布和敏捷的开发框架:Rational Unified Process,也就是RUP,统一软件开发过程,对产品经理的影响都有哪些。

尽管有些人认为RUP是一种敏捷的流程,但也有人认为很难把它归为是轻量级的过程,因为RUP本质上是一种迭代方法,其中每个迭代都是一种小型瀑布的形式。也就是说,RUP确实改进了传统的瀑布过程,对于一些产品组织来说,这是一个合理的折衷解决方案。

为什么这么说呢,我们先简单了解一下RUP的四个阶段和六个原则。


RUP的四个阶段和六个原则


RUP分为四个阶段:

1)开始阶段:为系统构建商业案例和项目范围;

2)细化阶段:开发对问题域的理解,细化需求并设计体系结构;

3)实施阶段:系统设计,编程,测试,构建达到beta发布点的体系;

4)过渡阶段:在运行系统中部署产品,并达到普通产品发布。

RUP的六个通用原则:

1)迭代式的开发

2)管理需求

3)使用基于组件的体系结构

4)可视化建模

5)不断验证软件质量

6)控制变更

从RUP的四个阶段可以看出,它是有明显的阶段概念的,这个和瀑布贴近,而同时呢,它又在原则中强调迭代式的开发,而这又贴近敏捷的原则,简单来说,我们可以这样理解,RUP在具体的实践中,在它的四个阶段中,以敏捷的原则包含了一部分瀑布的流程,而这些瀑布被称为是小瀑布。

关于RUP就简单介绍这么多,如果对RUP感兴趣,可以自查自学。


RUP给产品经理带来的影响


整体来看,RUP是非常适合产品经理的,相对于传统的瀑布而言,它无需在开发末期才能对产品的真正可用性进行验证,产品经理只需要在RUP的开始和细化阶段承担起商业和需求的职责就可以了,同时呢,又可以通过类似敏捷的不断迭代来持续验证可用性并进行纠正。

但是,RUP依然会给产品经理带来一些不得不去考虑的影响。

影响1:过渡强调可视化建模

可视化建模有用没,绝对有用,它对于团队形象理解和沟通一些重要的概念,尤其是体系结构比较大的产品而言,相当有用。

但是,就和产品经理都知道的一句话-概念林志玲,成品罗玉凤-一样,可视化建模会让客户产生好感并心生喜欢,但是一旦真正的产品做出来,客户可就不是那个态度了,尤其对于产品经理而言,在这个系列里,我一直在说,无论是瀑布,还是敏捷,产品经理最为核心的一个任务就是如何确保你的产品的可行用能够被验证。

可视化建模是肯定不行的,就好比现在汽车业,尽管有了各种各样的CAD工具,但是油泥模型该做还得做,目的也是如此,图纸毕竟不如让目标客户看到个实体的东西来的直接,因此,产品经理做原型,还是那句话,不是简单的把PRD数据形象化,而是为了用来验证可用性的。

也就是说,原型做完后,是要有个测试过程的,我不知道有多少企业的产品经理在做这个。

影响2:在验证之前开始架构设计带来的的风险

我们知道,一个好的产品技术架构是具有一些特点的,比方说扩展性,兼容性,对于开发团队而言,尽管理论上可以在后续的阶段中对确属必要修改的架构进行修改,但我想没有一个开发的伙计愿意干这事,尤其是涉及这种技术架构级别的。

因此,这就给产品经理带来了一个影响,如果架构缺乏前瞻性,那么,我们的产品很快就会受到限制,反过来说,也就是如果我们无法提供产品一个较长期的,可验证的成果,那么,技术架构自然也就是短视的,当然,责任不在开发,而在产品经理。

这种产品的前瞻性和技术架构的矛盾,不仅仅存在于软件行业中,很多行业都有,比方说车企,现在的平台只是支持两驱车,但是未来如果要出四驱车的话,那么,现有的平台就没法搞,因此,对于产品经理而言,就得有个清晰的产品战略,明确未来产品的发展规划是什么。

之所以现在很多车企不惜花上百亿,数年的时间打造尽量涵盖更多级别,更多类型,更多形态的技术平台,其中一个重要的原因就是这个。

影响3:强调正确的构建产品和正确的产品

产品经理负责的是有一个正确的产品,而无论是瀑布,敏捷,还是RUP,则是负责正确的构建产品。

也就说,开发体系确保的是产品的可实现性,但是,对于产品经理来说,这个正确的产品不仅仅包括产品介质的可实现性,还包括可用性和商业价值的正确,因此,在RUP中,无论是可视化建模,迭代,或是对产品需求的管理,最终都离不开产品经理的正确输入,而这就要求企业和个人,不能因为过度关注开发的过程而忽视开发的根本方向和目的。


个人感想


RUP是个兼顾了组织目标和个体目标的一种开发框架,在此框架的基础上,企业可以结合自身情况发展出适合自己的开发流程,对于组织而言,阶段化的管理可以更好的体现体系之间的协作,而对于个体或具体的开发团队而言,则可以使开发过程更加灵活,更加轻便。

而产品经理作为PMS的核心人员,则可以一方面基于阶段的管理努力输入正确的成果给RDMS体系,同时,在开发的过程中,则可以更加强调开发人员个体的主观能动性确保输出的成果是具有商业价值的,这,才是PMS和RDMS正确的协作方式和目的。


整体感想


最后呢,我再多说一点自己的想法。

之所以写这个系列,其实我的根本目的并不是在讲什么开发管理思想,开发流程,我说了,我对这些连个毛都不懂,那么,写这些的目的是什么呢?

1)管理思想都是互通的,无论哪个行业,都需要多多交流,而不是自我封闭

一开始我就说过,瀑布来源于传统制造业,敏捷来源于精益化管理,其实何止如此,在管理思想上,国内各行业间似乎有着一面面无形的墙阻隔了这种交流,但是在国外,行业间的管理思想交流是很频繁的,因为管理,说到底就是解决人和人,人和组织,组织和组织的关系,很多核心理论是具有普适性的。

比方说MVP,好像是IT领域提出的,但GE同样在借鉴了MVP的思想后,开发出了FastWorks,后来GE家电被海尔收购后,又延伸出了人单合一,还有,六西格玛是一种企业质量流程管理的技术,但是它在吸收了LEAN的思想后,出现了LEAN SIX Sigma,其中在讲到原因的时候,就有一点明确指出,“难道六西格玛只适合制造企业吗?”还有同样吸取了LEAN思想,而在飞机总装上诞生的脉动式生产。

这都是研发,生产的案例,同样,产品管理事实上也是吸取了很多管理领域的思想才不断完善和发展起来的,别的不说,单就营销这块就贡献了产品管理中至少50%的理论支持和方法工具。

因此,行业间的自我封闭是无助于好的管理思想在国内的本土化的建设和发展的,现在很多传统制造业其实都面临一个问题,就是如何处理好规模化和个性化产品的开发生产问题,这在国外是一个很清晰的课题,就是“大规模定制下的敏捷开发”,像现在提出的“小批量,多品种”的柔性开发,似乎只能解决一小部分产品的开发问题,如何让这种思想有更广阔的行业应用,这难道不值得思考吗?

2)不要盲目追求新的管理思想,管理的本质是实践

管理界有这样一句话:所有你从别人那里学到的东西,本质上都是没用的。

言外之意就是要想真正构建起符合自己情况的管理架构,无论是企业的,业务的,人力的,不从自己的实际情况出发思考,不去努力实践,只想着照搬一个成型的东西为我所用,最终的结果自然就是四不像。

真正有价值的,负责的第三方咨询企业永远不会告诉你具体该怎么做,他们只会提供给你一个思想,一个框架,一套知识体系去让你学习,实践,哪些告诉你“按照我这个步骤就能打造出一个爆品出来”的话题,确实很吸引人,但是,你放心,你绝对打造不出爆品出来。

这个世界上所有做出了伟大产品的企业,在开始的时候,都不是抱着打造一个伟大产品的动机出发的,他们永远都是想着如何能够让消费者更加满意,生活更加美好而开始一步一步的艰苦努力的,我还是那句话:做产品,该走的路一步都不能少,该吃的苦一点都不能少,该受的罪一个都不会少。

企业只有守住本心,产品经理只有耐住寂寞,知道为谁而做产品,为何而做产品,才能在这条路上走得更远。

3)任何一个体系都不是救命稻草,该选择什么,自己心里要有谱

因为INTEL、谷歌、facebook一众大佬用了OKR,因此,KPI就该被扔掉了,因为阿里提出了中台的概念,因此,如果没个中台,都不好意思说自己会做业务,但是,当一大票企业在搞中台的时候,阿里又开始要拆中台了,傻眼了吧。

任何一个体系都有其明确的应用场景,有优势就一定有劣势,如果有人和你说这个,那个体系能解决你的一切问题,你只需要呵呵一笑,把他当成是电视上卖包治百病的药的骗子就行了。

产品管理同样如此,它有其明确的应用场景,如果你的企业偏向于太多的定制化业务,那么,你其实并不要产品经理,而是需要好的项目经理,比方说现在一大批原本做AI算法的企业,在资本和IPO的压力下,才意识到“上游企业控制了数据,下游企业控制了场景”,而自己则根本没有办法做出通用型的产品,更多的是一客一单的定制项目,说真的,有好的项目经理和商务经理,比有产品经理要更现实一些,如果你的企业以研究技术为主,短期内并没有盈利的任务,那么,你需要的是好的研发管理体系和科学家,工程师,同样也不需要产品经理,比方说玩机器人玩的不错的波士顿动力,最新消息是已经被现代汽车收购。

4)对产品经理的一点建议

如果大家仔细看了这个系列,就会发现,我所列举的三种开发思想,其实都在向产品经理提出一个极大的挑战,就是:

如何确保你输出给研发的各种形式的成果是经过了目标客户验证的。

这个我也强调了几次,这说明什么问题呢?

说明作为一个产品经理,无论你现在用什么形式来向研发呈现你对产品的构想,如果没有办法尽量验证它的正确性,那么,说真的,一旦上市出现了极大的问题,那么,两个字送给你:活该!

不管是原型,或是文档,或是其它的什么形式,我还是在文档课里讲到的,那只是你在完成所有工作后的一种结果呈现载体,如果没有真正深入到市场,深入到客户中去看,去想,真的,我不相信一个每天坐在工位上的,只会捣鼓原型的产品经理能做出什么有价值的产品出来。

最后呢,再回到本文的主题,既然简单聊到了开发流程,那么,送佛送到西,对于企业来说,该怎么选择合适的开发流程呢?提供一张图,各位做参考就可以了。

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

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址