解析产品开发失败的5个根本原因
PM的价值,就在于解决产品发展过程中的各种阻碍。而解决这些阻碍,就要找到问题的根源,才能举一反三,有效避免产品开发失败。
《从0到1系列》已经更新到第17集,系统地回顾了我在过去一个2B的平台型产品从构想到完整落地的全过程,特别是第三部分主要是针对产品研发过程中回顾、总结和反思。
包括:
- 产品经理如何规划产品的roadmap
- 产品经理如何把控产品开发的进度
今天则着重盘点在整个研发过程中的典型性问题,回顾过去经历的坑,试图找到其规律和破解之道。
软件开发过程,作为一个“富有创造性”的工作,其过程相比于其他项目过程都有它的特殊性,研发管理的思想和体系也随着研发实践逐步发展起来,从上世纪80年代的“门径管理”,到NPD,以及后面的IPD模式都得到了广泛的应用,大大提高了企业的研发水平和研发能力。
但我们依然不断在深坑里面挣扎。
我们学习了很多的管理方法和理论,也尝试验证了很多的技巧和工具,但这5个问题如果不能真正得到重视和妥善的解决,我们的产品开发工作依然困难重重。
未形成系统的产品理念
严格来说,产品研发是一项投资行为,但在现实中它只是一个短期目标,甚至只是一项任务,只重视功能的实现而轻视性能和可靠性。
我们常常能够见到产品开发过程中简单的功能叠加现象,一是认为功能越多,用户越满意,二是喜欢所谓的“微创新”,东家加西家成为自家,并且以陷入到不到累加的功能池自豪。
最终考核的我们并不是创造了多少有价值的产品,而是完成了多少工作。之所以会出现考核工程师以“代码行数”为指标,原因就在于我们沉醉于完成“项目的数量”,交付了多少工作量,我们习惯于拉起了很多的项目敢死队,并标榜为突出的业绩。
当项目偏离价值目标,又怎么能够诞生出色的产品呢?
我所见证过的失败项目中,一个突出的现象就是:在产品的立项阶段,单纯是以市场机会作为驱动,产品研发往往处于配合市场、销售的位置,多数情况下仅仅是从“功能”的角度来定义产品研发,而没有从用户的产品整体体验的角度去定位和研发产品。
这确实常常陷入一个两难的境地,面对一个订单,不接来吃一口怎么知道是毒药呢?所以,什么客户都敢做,什么订单都想接。
但结果就是产品做了一大堆,好用的没几个,仓库倒是堆得满满的,更不要说核心技术的积累,起了一个大早,赶了一个晚集。
单纯的销售机会主义文化,最终都会让研发工作本身沦为附属,始终无法上升到企业战略的突出位置,并进而把产品的研发工作视为一项成本。整体的研发投入明显不足,不足以支撑日益复杂的业务需求,从而导致整个研发过程四处救火,拆东墙以补西墙。
甚至于把产品只是当作研发部门的事情,而不是组织的一个整体活动,谁把事情搞砸了,谁就得背锅。在这种理念下,团队就愈发追求短期内的任务目标,而不是考虑用户的体验价值。
缺乏有效的产品规划
产品很多,目标很远,就是规划很少。
由于没有能够建立一个系统的产品发展路径,总是被动的响应市场端的要求和竞争的结果,产品研发团队失去了清晰的路线图的指引,临时性的决策机制导致效率低下,陷入一种开发新产品,修复旧问题的循环打怪状态。
在这种机制下,研发变成了只关注一个又一个产品的开发工作,众多产品互相拼凑重复开发,必然导致整个产品系列缺乏系统化,更无法进行平台化。
效率降低只是表象,可能通过一些途径还有提升的空间,这种模式带来的最大问题就是缺乏核心技术,团队无法学习和引入新技术,更无法从技术层去提供更优的解决方案,最终是逐渐降低了产品竞争力。
但真实情况下,很诡异的一个事情就是,我们更乐于解决那些最能看得见的事情。
某个订单下来,立马开足马力想要去搞定这个大客户,吞下一个大蛋糕,循环往复直到所有的资源全部投入到火热的项目交付中,哪怕是一个很小的业务方向,也是多项目并行。
这种局面,最终的结果就是没有人有精力投入到未来的规划中,没有资源有能力沉淀的基础性工作。团队越来越忙,效率越来越低下,产品越做越差。
过程缺乏决策评审
研发过程缺乏决策评审,产品研发的过程管理薄弱,没有相应的资源投入和配套的流程来确保过程的可控性,加之软件研发工作本身的不确定性和复杂性,加剧了这个问题带来的影响。
这种情况包括时间估计不准确,总体计划缺乏完整性(甚至没有计划性),各个环节的衔接极差,进展情况得不到及时汇报,缺乏有效的监控手段和措施,对风险的防范能力很差,一些细小的风险都可能带来整个项目的延期,或者质量事故。
屡见不鲜的是延期,返工,或者货不对板。
有人说细节决定成败,也有人说沉迷于细节缺乏大局观。也许两种说法都有各自的道理,但作为身处一线的PM而言,思考如何建立一种追求卓越体验的项目文化,评审决策的管理机制,既难也紧迫。
流程缺乏纪律性
产品研发工作变成了“大厨掌勺”,一旦高手缺席,就做不好一道好菜。
缺乏纪律性的明显特征是流程粗放,层次不清,没有规范,缺乏具体可操作的过程管理。各个岗位随意按自己的喜欢和理解行事,加之没有决策点的评审,导致各个环节各自为政。
“单点故障”,既有人为因素,也有环境使然。站在某些角度来看,单点故障来凸显其价值,只是更大范围的情况下,会带来很多的伤害。
这种纪律性带来的伤害最为明显的就是上下游的衔接问题,整个开发过程变成了接力赛的串行流程,看上去每个环节都有人负责,都有人把控,但由于理解的不一致,交付成果参差不齐,接口不畅漏洞百出,从而进一步降低产品的竞争力。
这种状况还将形成另外一种可怕的局面,那就是问题总是被掩盖,或者被拖延,直到最终暴雷。
职能化组织的僵化
以“部门职能”为基础的组织,很容易陷入部门墙壁垒中。
各个部门由于对产品成功的定义不同,标准不一,就很难在整个产品的全生命周期内形成一致的目标,从而带来协作的困难。如果正好处于某种高速运转的状态下,部门之间必然会把产品工作当作了事务处理,就像一个烫手的山芋,谁都想着尽快踢到下游。
最终负责研发的团队背着整个黑锅,卖不出去是因为体验不好,用户投诉更是因为体验不好。
职能化组织的第二问题是容易导致PM们没有发言权,有责无权或者有责少权。PM的角色更像是一个行政管理人员和协调人员,而不是一个产品或者一个项目的领导者,他们往往没有办法真正通过有效的途径推动项目的落地,从而延期,或者质量不足。
当一个PM,缺乏一定的决策权时,通常都意味着项目正处于失控状态。
#专栏作家#
杜松,公众号:产品微言,人人都是产品经理专栏作家。专注于人工智能方向,擅长产品规划和架构设计。
本文原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自Unsplash ,基于 CC0 协议。
![新零售线上配送前置仓建设浅析](https://image.woshipm.com/2023/04/13/79f0b37e-d9ea-11ed-889f-00163e0b5ff3.jpg!/both/120x80)
![多邻国,5亿用户上瘾的背后](https://image.woshipm.com/2023/04/13/04fcfd92-d9eb-11ed-a8b0-00163e0b5ff3.jpg!/both/120x80)
![在小红书能学习到深度内容吗?豆瓣、小红书、B站3大媒体对比](https://image.woshipm.com/2023/04/14/f995d110-da8d-11ed-aeb8-00163e0b5ff3.jpg!/both/120x80)
![微博丢掉大V马甲](https://image.woshipm.com/2023/04/13/c02fc32a-d9ea-11ed-bd74-00163e0b5ff3.jpg!/both/120x80)
![产品经理需要掌握的能力:产品的原型设计](https://image.woshipm.com/2023/04/17/38117a34-dcf5-11ed-9781-00163e0b5ff3.png!/both/120x80)
这样的问题没有什么很好的解决方法吗
说到心里去了,不懂产品的人喜欢管产品,最后即使做出来了,也是一塌糊涂,如果不给产品经理决策权,不如不要招!
说的太对了,很多公司都是领导一言堂,没有目标,PM就是一个执行者,最终烂尾