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