新产品做了一大堆，好用的产品没几个，根本性的困扰到底是什么？
<让产品从0到1系列第 17 辑>
文 | 杜松，公众号 | 产品微言
从去年11月，回顾了过去一个2B的平台型产品从0到1的完整过程，在第三部分主要是针对产品研发过程中回顾、总结和反思。
包括：
今天则着重盘点在整个研发过程中的典型性问题，回顾过去经历的坑，试图找到其规律和破解之道。
软件开发过程，作为一个“富有创造性”的工作，其过程相比于其他项目过程都有它的特殊性，研发管理的思想和体系也随着研发实践逐步发展起来，从上世纪80年代的“门径管理”，到NPD，以及后面的IPD模式都得到了广泛的应用，大大的提高了企业的研发水平和研发能力。
但我们依然不断在深坑里面挣扎。
问题1：未形成系统的产品理念
严格来说，产品研发是一项投资行为，但在现实中它只是一个短期目标，甚至只是一项任务，只重视功能的实现而轻视性能和可靠性。
研发工作本身还没有上升到企业战略的突出位置，整体的研发投入明显不足，不足以支撑日益复杂的业务需求，从而导致整个研发过程四处救火，拆东墙以补西墙。
常常是以市场机会作为驱动，产品研发往往处于配合市场、销售的位置，多数情况下仅仅是从“功能”的角度来定义产品研发，而没有从用户的产品整体体验的角度去定位和研发产品。
结果是产品做了一大堆，好用的没几个，仓库倒是堆得满满的，更不要说核心技术的积累，起了一个大早，赶了一个晚集。
甚至于把产品只是当作研发部门的事情，而不是组织的一个整体活动，谁把事情搞砸了，谁就得背锅。在这种理念下，团队就愈发追求短期内的任务目标，而不是考虑用户的体验价值。
问题2：缺乏有效的产品规划
产品很多，目标很远，就是规划很少。
由于没有能够建立一个系统的产品发展路径，总是被动的响应市场端的要求和竞争的结果，产品研发团队失去了清晰的路线图的指引，临时性的决策机制导致效率低下，陷入一种开发新产品，修复旧问题的循环打怪状态。
在这种机制下，研发变成了只关注一个又一个产品的开发工作，众多产品互相拼凑重复开发，必然导致整个产品系列缺乏系统化，更无法进行平台化。
效率降低只是表象，可能通过一些途径还有提升的空间，这种模式带来的最大问题就是缺乏核心技术，团队无法学习和引入新技术，更无法从技术层去提供更优的解决方案，最终是逐渐降低了产品竞争力。
问题3：过程缺乏决策评审
研发过程缺乏决策评审，产品研发的过程管理薄弱，没有相应的资源投入和配套的流程来确保过程的可控性，加之软件研发工作本身的不确定性和复杂性，加剧了这个问题带来的影响。
这种情况包括时间估计不准确，总体计划缺乏完整性（甚至没有计划性），各个环节的衔接极差，进展情况得不到及时汇报，缺乏有效的监控手段和措施，对风险的防范能力很差，一些细小的风险都可能带来整个项目的延期，或者质量事故。
屡见不鲜的是延期，返工，或者货不对板。
问题4：流程缺乏纪律性
产品研发工作变成了“大厨掌勺”，一旦高手缺席，就做不好一道好菜。
缺乏纪律性的明显特征是流程粗放，层次不清，没有规范，缺乏具体可操作的过程管理。各个岗位随意按自己的喜欢和理解行事，加之没有决策点的评审，导致各个环节各自为政。
这种纪律性带来的伤害最为明显的就是上下游的衔接问题，整个开发过程变成了接力赛的串行流程，看上去每个环节都有人负责，都有人把控，但由于理解的不一致，交付成果参差不齐，接口不畅漏洞百出，从而进一步降低产品的竞争力。
这种状况还将形成另外一种可怕的局面，那就是问题总是被掩盖，或者被拖延，直到最终暴雷。
问题3：职能化组织的僵化
以“部门职能”为基础的组织，很容易陷入部门墙壁垒中。
各个部门由于对产品成功的定义不同，标准不一，就很难在整个产品的全生命周期内形成一致的目标，从而带来协作的困难。如果正好处于某种高速运转的状态下，部门之间必然会把产品工作当作了事务处理，就像一个烫手的山芋，谁都想着尽快踢到下游。
最终负责研发的团队背着整个黑锅，卖不出去是因为体验不好，用户投诉更是因为体验不好。
职能化组织的第二问题是容易导致PM们没有发言权，有责无权或者有责少权。PM的角色更像是一个行政管理人员和协调人员，而不是一个产品或者一个项目的领导者，他们往往没有办法真正通过有效的途径推动项目的落地，从而延期，或者质量不足。
当一个PM，缺乏一定的决策权时，通常都意味着项目正处于失控状态。
<本文完>
———— / END / ————
【 产品复盘 】 从点子到产品，如何打造一款2B的平台型产品
第一部分：如何启动一个新产品
第二部分：如何设计一个新产品
第三部分：如何管理新产品的开发过程
3、盘点产品开发过程中的典型问题
网友评论