为什么开发出来的产品和原型不一样?

参与了一个2B的项目,产品根本不知道上游系统过来什么数据,自己意淫设计某些字段,导致开发过程中产品不断被diss,最后开发自己画的页面,如何规避类似的事情,还有哪些原因?

为什么开发出来的产品和原型不一样?

所有的产品,在设计者眼里都是完美的,充满了理想主义的美妙。

不管是工程师,还是设计师,不管是项目经理,还是产品经理,每个人都自诩为行业的专业,精通最新的理念和技法,试图努力以一己之力的设计概念去拯救深陷业务囚笼的“上帝们”。

在项目的早期阶段,他们自信满满的情绪带动了每一个人,似乎成功指日可待。殊不知,在了解和理解之间,有一道巨大的鸿沟,没有人发现,更没有人对此有兴趣。

为什么开发出来的产品和原型不一样?

客户需求:我家有三个小孩,我需要一个能三个人用的秋千。它是由一绳子吊在我园子里的树上。

商业顾问:您的需求我们以完成,我们通过人体工学,工程力学多方面研究。本着为顾客服务出发,我们的秋千产品在使用时给你如同游乐园里的过山车一样刺激,如同你在地面上坐沙发一样舒适与安全。

项目经理:秋千这东西太简单了,秋千就是一块板子,两边用绳子吊起来,挂在树上的两个枝子上。

产品经理:这个无知的项目经理,两个树枝上挂上秋千那还能荡漾起来吗?除非是把树从中截断再支起来,这样就满足要求了。

开发工程师:两条绳,一块板,一棵大树,接在树的中段;太简单了,工序完成。

测试工程师:我们的产品用户自己都可以完成安装,只要把绳子系在树上就可以了。

01 必然

每个人都知道需求变更的后果和影响,但我们始终没法完全规避,几乎没有不发生变更的项目。

其一,认知是一个过程。

人类认识世界是一个由浅入深的过程。我们以及客户对需求的认识也是是一个逐步深入逐步明晰的过程。随着认识的深入,客户的需求才逐渐变的明确,这时候他们往往会有更多,或者更好的解决方案。

而对工程师或者PM来说,从了解用户的想法和真正理解用户的痛点需求,是两个完全不同的概念,更是一个需要消耗足够精力和时间的过程,特别是2B的产品还牵涉到不同干系人,复杂的管理模式等一系列问题,在这个过程中任何的细节差异都可能隐藏了巨大的需求变更风险。

其二,沟通,是一个信息衰减的过程

我们知道,沟通是一个对信息进行编码、解码的过程,在这个过程中不同的媒介夹杂中各种噪声,会让沟通的双方对同一事物出现完全不同的理解,从而导致需求的偏差,变更再所难以。

越是复杂的项目,随着团队的规模扩大,信息在传递过程中势必会一层层的衰变减弱,甚至传递到最基层的时候,已经完全是不同的概念。这也是项目过程中需要强调规则、强调文档的一个原因。

在管理良好的组织内,文档的载体,格式都有明确的规范,就是为了尽可能的规避信息的衰减变形。

其三,技术,是一种逐步进步的过程

我们相信条条大道通罗马。对用户的需求来说,通常都会有不同的解决方案和实现方式,同一个产品功能,不同的工程师,不同的产品阶段,都有不同的技术选型方案。有些时候我们需要追求进度,会采用保守但缺乏创意的方案,有些时候我们需要突出优势,会考虑更激进但有风险的策略。

这种不同的思路,同样是引发需求变更的源头。

02 规则

需求的变动在实际工作中犹如家常便饭,但实际真正引发各种矛盾的情况,也无非是3大三类:

  • 没有细化清晰的产品需求
  • 没有明确清楚的项目边界
  • 存在设计缺陷的技术架构

这些问题,实际上考验的是团队对需求本身的理解和软件架构的设计能力。我们无法确保所有的问题在开发之前就能够周全,建立一个有效的需求管理流程和风险应对措施,是必然的选择。

为什么开发出来的产品和原型不一样?

需求变更流程

这个流程有两个核心观念,也是你一定要能争取到的权力:

1、所有人都可以提出需求变更的请求,但只有一个需求的入口

这个入口必须是你,如果你争取不到这个权力,那整个项目一定会失控。任何都可以提出需求和变更,但你必须作为唯一的接口人和过滤器。

为此,你应该有足够的心里准备,你需要面对N多方的压力。甚至,为了项目交付的这一终极目标,你需要有不惜得罪人的思想准备。越是大项目,越是牵涉多方的项目,风险和协调都会是指数级的放大。

只有当你具备这个权力的时候,你才能确保项目在预设的轨道上进行,也只有你才可以清晰的回答当前要做什么,能做什么,以及不能做什么。

2、只有评审过的需求才可以被执行

“不要接到需求就直接动手”。这是项目的至理名言。

你需要让整个项目团队,包括上至老板、直到程序员,也包括外部的客户,都认同、理解并遵守一个基本原则,那就是程序员不直接接受任何非PM的需求,不接收任何非经过评审的需求——所有未经过评审的需求,只可讨论,不可执行,减少(避免)张嘴就来的非必要、非紧急、非合理的无效变更。

切记:不是所有的需求都要接受,也不是所有变更都要立刻修改,一定要能敢于拒绝需求。

作为产品经理,在需求变更收集上来之后,根据需求提出方的业务进行分析后,邀请需求方、技术、设计和测试多个环节进行分析,从而判定需求对于项目的影响如何,确定是否接受变更并将变更排列优先级。

但最终一定要你拍板,这是你需要争取到的第二个权力。你不能最终决定一个需求的价值,对你而言,项目已经离失控不远了。

当然,你可以适当根据需求的范围大小,决定评审的范围,甚至可以决定需要告知的对象,这没有标准,需要灵活把握。例如,对纯技术性驱动的变更,比如有更好的实现方案可以带来性能的提升,这个情况,需要根据整体项目状况,结合技术本身的能力判断。

03 变通

既然需求的变更已无可避免,我们要做的是就是努力去去适应这种变化,而不是抗拒变化。

所有的需求管理规则,本质上都只是让需求变更更有序,更能实现,而从来不是抵制变更的发生。

这是一种本质性的区别,遗憾的是,多数团队都停留在停留在指定苛刻的需求管理规则上,而缺乏真正推动需求实现方案更优解的策略、资源和能力。

 “ 唯一不变的,就是变化本身。”——斯宾塞·约翰逊

“变更”是一个非常不讨喜的字眼,在实际工作中,一旦出现延期等现象,首要被追责的就是“变更”了,因为变更意味着设计不合理,评估不合理等诸多事先规划不足的问题,而这些不足,最容易变成甩锅的工具。

而且,多数情况下,一旦把某个功能实现,定义为“需求变更”就已经不再涉及到能力或者态度问题了。因为是上游先变,我不得不变,前面不变我也不变,前面变了我不得不变,反正跟我没有关系,不是我的问题。

这是一种可怕的击鼓传花式的文化。

甚至在某些情况下,PM们或者乙方,似乎更愿意甩锅为“需求变更”,因为它是最容易被定义“甲方”的问题,意味着原先的设计和计划有调整的可能,对项目本身而言还有腾挪的空间,这些空间还可能包括“乙方赖以生存的费用”问题。

所以,站在这个角度,我们似乎完全不应该恐惧变更,除非它要变成“追责”的靶子。而过度追求KPI的文化,则会进一步加剧这种团队内部的恐惧情况。

所有人都更希望上游,或者前面的人先签字画押,我不得不做的局面。

冗长的流程,推诿的氛围就此形成。团队弥漫着消极的情绪,脸皮最厚的产品经理也开始保守,变得犹豫拖沓,没有人再愿意创新,更没有人愿意打破规则。即便发现了问题也不乐意提,枪打出头鸟,没有多数人愿意承担不必要的风险和麻烦。

灵活一些的PM们,则采用“半夜烧烤”的办法来绕过这种流程法则,三瓶啤酒下肚能改也就改改了,甚至PM主动自首也能缓和一些情况。但当涉及面比较大的时候,终究还是需要更多的流程和规则介入。

让团队摆脱“需求变更”的恐惧认知,建立一种积极消化需求变更的机制,这才是核心,才能解决问题。

其一,改变考核机制。

这涉及到一个企业的规模、架构和文化问题,也和相关负责人对产品、项目的认识有关。例如,用代码量来考核工程师的工作能力和工作量,这早已被定义为笑料的事情,却仍屡见不鲜。

其二,挖掘需求背后的需求。

5问法是你必须要掌握的工具。针对一个问题,必须连续以“为什么”来自问和追问,从而追究其根本原因,找到用户背后真正的动机,千万不可直接把需求方提出的要求当作需求列表转交给开发,这会让你的团队背上沉重的负担,也将让你失去工程师的信任。

所有没有经过深入推敲的,始终只是纸上谈兵的想法,而不是真正的产品需求。

其三,需求的变更,本质是对实现方式的变更。

典型的例子就是用户要一匹更快的马,进化出了汽车。实际上对用户来说,他的需求始终都是“更快到达目的地”,究竟是马,还是汽车,变更的只是实现需求的方式。

特别是软件开发过程中,我们没有办法预知究竟那种方案更合适,迭代演进是最优的策略。在这个过程,功能的实现会有很大的变化,有的时候是交互变更,有的时候视觉变更,还有一种是技术变更。

对这种情况,有一个更熟悉的词叫做“重构”,重构就是对实现方案的一种调整,但有些时候也被认为是“变更”,是需求引发的变更。

其四,选择恰当的变更时间。

通常来说,需求变更越往后影响越大,成本也越大。所谓“恰当”的时间,是充分平衡了变更影响和成本代价后做出的一种选择,没有人能够给出一个标准答案什么时候是好时机,而在于团队是否能够承受相应的风险。

甚至是草图阶段,每一次变更修改都可能会影响后续项目工作的开始、结束的时间节点,只是这种风险是否值得承担。

但有一点必须要明确的是,当你意识到需求发发起一次变更后,要尽快在团队内部进行沟通交流,而不是去猜测风险和成本,依赖专业评估才是产品经理的最佳选择,然后尽可能的争取时间和空间。

本文由 新媒体之家 作者: 产品微言 发表,其版权均为原作者所有,文章内容系作者个人观点,不代表 新媒体之家 对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。
1

发表评论