PM的价值，就在于解决产品发展过程中的各种阻碍。而解决这些阻碍，就要找到问题的根源，才能举一反三，有很大成效避免产品开发失败。

  《从0到1系列》已经更新到第17集，系统地回顾了我在过去一个2B的平台型产品从构想到完整落地的全过程，特别是第三部分主要是针对产品研制过程中回顾、总结和反思。包括：产品经理如何规划产品的roadmap产品经理如何把控产品开发的进度今天则着重盘点在整个研发过程中的典型性问题，回顾过去经历的坑，试图找到其规律和破解之道。软件开发过程，作为一个“富有创造性”的工作，其过程相比于其他项目过程都有它的特殊性，研发管理的思想和体系也随着研发实践慢慢地发展起来，从上世纪80年代的“门径管理”，到NPD，以及后面的IPD模式都得到了广泛的应用，大幅度的提升了企业的研发水平和研发能力。但我们依然不断在深坑里面挣扎。

  我们学习了很多的管理方法和理论，也尝试验证了很多的技巧和工具，但这5个问题若无法真正得到重视和妥善的解决，我们的产品研究开发工作依然困难重重。未形成系统的产品理念严格来说，产品研制是一项投资行为，但在现实中它只是一个短期目标，甚至只是一项任务，只重视功能的实现而轻视性能和可靠性。我们常常能够见到产品研究开发过程中简单的功能叠加现象，一是认为功能越多，用户越满意，二是喜欢所谓的“微创新”，东家加西家成为自家，并且以陷入到不到累加的功能池自豪。最终考核的我们并不是创造了多少有价值的产品，而是完成了多少工作。为何会出现考核工程师以“代码行数”为指标，原因就在于我们沉醉于完成“项目的数量”，交付了多少工作量，我们习惯于拉起了很多的项目敢死队，并标榜为突出的业绩。当项目偏离价值目标，又怎么能够诞生出色的产品呢？

  我所见证过的失败项目中，一个突出的现象就是：在产品的立项阶段，单纯是以市场机会作为驱动，产品研制往往处于配合市场、销售的位置，多数情况下仅仅是从“功能”的角度来定义产品研制，而没有从用户的产品整体体验的角度去定位和研发产品。这确实常常陷入一个两难的境地，面对一个订单，不接来吃一口怎么知道是毒药呢？所以，什么客户都敢做，什么订单都想接。但结果就是产品做了一大堆，好用的没几个，仓库倒是堆得满满的，更不要说核心技术的积累，起了一个大早，赶了一个晚集。单纯的销售机会主义文化，最终都会让研发工作本身沦为附属，始终没有办法上升到企业战略的突出位置，并进而把产品的研发工作视为一项成本。整体的研发投入明显不足，不足以支撑日益复杂的业务需求，因此导致整个研发过程四处救火，拆东墙以补西墙。甚至于把产品只是当作研发部门的事情，而不是组织的一个整体活动，谁把事情搞砸了，谁就得背锅。在这种理念下，团队就愈发追求短期内的任务目标，而不是考虑到用户的体验价值。缺乏有效的产品规划产品很多，目标很远，就是规划很少。由于没有能够建立一个系统的产品发展路径，总是被动的响应市场端的要求和竞争的结果，产品研制团队失去了清晰的路线图的指引，临时性的决策机制导致效率低下，陷入一种开发新产品，修复旧问题的循环打怪状态。

  在这种机制下，研发变成了只关注一个又一个产品的开发工作，众多产品互相拼凑重复开发，必然导致整个产品系列缺乏系统化，更没有办法进行平台化。效率降低只是表象，可能通过一些途径还有提升的空间，这种模式带来的最严重的问题就是缺乏核心技术，团队无法学习和引入新技术，更无法从技术层去提供更优的解决方案，最终是逐渐降低了产品竞争力。但真实情况下，很诡异的一个事情就是，我们更乐于解决那些最能看得见的事情。某个订单下来，立马开足马力想要去搞定这个大客户，吞下一个大蛋糕，循环往复直到所有的资源全部投入到火热的项目交付中，哪怕是一个很小的业务方向，也是多项目并行。这种局面，最终的结果就没有人有精力投入到未来的规划中，没有资源有能力沉淀的基础性工作。团队越来越忙，效率越来越低下，产品越做越差。过程缺乏决策评审研发过程缺乏决策评审，产品研发的过程管理薄弱，没有相应的资源投入和配套的流程来确保过程的可控性，加之软件研发工作本身的不确定性和复杂性，加剧了这样的一个问题带来的影响。

  这种情况包括时间估计不准确，总体计划缺乏完整性（甚至没有计划性），所有的环节的衔接极差，进展情况得不到及时汇报，缺乏有效的监控手段和措施，对风险的防范能力很差，一些细小的风险都可能带来整个项目的延期，或者质量事故。屡见不鲜的是延期，返工，或者货不对板。有人说细节决定成败，也有人说沉迷于细节缺乏大局观。也许两种说法都有各自的道理，但作为身处一线的PM而言，思考怎么样建立一种追求卓越体验的项目文化，评审决策的管理机制，既难也紧迫。流程缺乏纪律性产品研制工作变成了“大厨掌勺”，一旦高手缺席，就做不好一道好菜。缺乏纪律性的明显特征是流程粗放，层次不清，没有规范，缺乏具体可操作的过程管理。各个岗位随意按自己的喜欢和理解行事，加之没有决策点的评审，导致所有的环节各自为政。“单点故障”，既有人的因素，也有环境使然。站在某些角度来看，单点故障来凸显其价值，只是更大范围的情况下，会带来很多的伤害。

  这种纪律性带来的伤害最明显的就是上下游的衔接问题，整个开发过程变成了接力赛的串行流程，看上去每个环节都有人负责，都有人把控，但由于理解的不一致，交付成果参差不齐，接口不畅漏洞百出，从而逐步降低产品的竞争力。这种状况还将形成另外一种可怕的局面，那就是问题总是被掩盖，或者被拖延，直到最终暴雷。职能化组织的僵化以“部门职能”为基础的组织，很容易陷入部门墙壁垒中。各个部门由于对产品成功的定义不同，标准不一，就很难在整个产品的全生命周期内形成一致的目标，从而带来协作的困难。如果正好处于某种高速运转的状态下，部门之间必然会把产品工作当作了事务处理，就像一个烫手的山芋，谁都想着尽快踢到下游。最终负责研发的团队背着整个黑锅，卖不出去是因为体验不好，用户投诉更是因为体验不好。

  职能化组织的第二问题是轻易造成PM们没有发言权，有责无权或者有责少权。PM的角色更像是一个行政管理人员和协调人员，而不是一个产品或一个项目的领导者，他们往往没有办法真正通过有效的途径推动项目的落地，从而延期，或者质量不足。当一个PM，缺乏一定的决策权时，通常都意味着项目正处于失控状态。#专栏作家#专注于人工智能方向，擅长产品规划和架构设计。题图来自Unsplash ，基于 CC0 协议。