产品经理必备思维方式——工程思维.docVIP

产品经理必备思维方式——工程思维 / 本月有一个印象深刻的对话，刚好也学习到了一种“新思维”是用于工作中避免该对话中出现的问题；因此记录并复盘，刻意练习。 对话： 我：这个功能在后台能查看到吗？ 同事：可以的，是在后台管理的xxx里面。 我：但是我看到这些反馈的问题没有人处理呀？或者说现在是谁负责这块呢？ 同事：我也不是很清楚这个功能现在是谁用，还有没有人用。 基于这段对话，问题的关键在于我们团队付出了时间和经理设计一款功能，并没有产生价值。似乎有一种“为了做而做”的感觉。要解决这个问题，产品经理该有点“工程思维”。 本月记录对“工程思维”的认识(why/how)和运用(what)（遵循“黄金圈法则”），但是由于还在不断学习中，因此还未完全吃透。在此推荐乔梁先生书籍《持续交付2.0》，比起产出需求，更重要是明白需求对业务的价值是什么。 图1：《持续交付2.0 业务引领的DevOps精要》 乔梁/著 一、工程思维之“why” “why”部分解决两个问题： 为什么要有工程思维； 什么是工程思维。 1. 为什么要有工程思维？ 互联网产品，追求质量和速度的平衡是很难的，甚至在我看来，质量和速度根本不存在平衡，仿佛”慢工出细活“这种工匠精神是对平衡质量和速度的挑战。 虽然不同的产品阶段对产品质量有不同的要求和标准，至少在同一产品阶段，质量的标准几乎是稳定的。因此在满足几乎稳定的质量前提下，追求快速交付产品价值意味着效率。在互联网行业，效率代表未来，代表金钱。 快速交付产品价值必然是需要成本的，例如产品开发成本、测试成本、金钱成本，如何降低迭代中的固定成本、提升产品迭代效率，就是工程思维中体现的了。工程思维解决的是“交付”、“价值”和“效率”的问题。相较起“科学思维”的无限期探索和发现，“工程思维”就是要脚踏实地。 脚踏实地，才能更好地仰望星空呀！ 2. 什么是工程思维？ 工程思维有两大特点： “把事情做成”，也就是要交付“可靠、可用的成果”； 要有“计划性”，在具体的时间周期内交付成果。 像上述本月对话，就是没有交付可靠可用的成果，原因在于没有明确什么样的成果才是可靠可用的。如何明确，围绕用户做起。 对于初级产品经理来说，前期准备工作是很有必要的，因为我们不像有五年十年工作经历的PM可以把产品原则、用户心智吃的透透的，方案上来就有，因而前期对于用户场景、需求分析、产品目标拆解等工作就尤为关键。 这也是我从入职到现在，一直在每个需求中都会做的事。 但是也不要理想化，想着自己把前期工作准备好了，就能交付可靠可用的成果了，因为工程思维并不是按照每一步过程走完，就能够得到最终想要的结果。毕竟产品经理所处只是”软件工程“的其中一环，工程失败也有多方的原因。 对于第二个特点，或许现在每个产品迭代版本，都可看做是一个”具体的时间周期“，但是这里面问题的关键在于如何做到。那么就是回归到第一个特点”交付可靠可用的成果“。所有成果是以“解决问题”为出发点，如何让成果变得明确，重要前提是“能够正确定义问题，并达成共识”。 图2 “达成共识”针对不同的沟通对象有不同的方法。当沟通对象是业务方时，达成共识就是要明确现实背景和需求背景。现实背景是当前现状是什么，现状带来什么问题；需求背景是哪些问题是需要紧急被解决的，解决的标准（目标）是什么，而不是业务方上来就和产品经理谈方案，这样只会变成“为了做而做”（在和业务方沟通时推荐使用5why分析法）。 因此在了解背景后，双方就问题和目标达成共识，这时产品经理或许能够提供MVP的方案来更好解决业务方的问题。 当沟通对象是研发人员时，达成共识就是不断将他人话转述成自己的理解，当自己理解和他人理解是相同时，才能达成共识。 有个例子是我就一个问题和开发咨询，但是我的这位开发总喜欢和产品讲“技术”，但是自知技术功底不深厚但又需要和开发理解达到一个层面，所以可以将开发的话转为自己的理解—— “开发大佬，你看我这样理解对不对啊，你说的这个问题是xxxx，影响到了xxxx业务，所以我觉得可以这样解决blablabla” 将自己不懂的技术知识用自己懂的业务知识转化表达，再去询问对方自己理解是否正确，这样就能达成共识，进行接下来的沟通了。 二、工程思维之“how” “how”部分解决两个问题： 如何创造价值； 如何“共创”与“精炼”。 1. 如何创造价值？ 上述提到工程思维的两大特点，目的都是为了在保证质量的前提下，快速交付产品价值。如何培养工程思维的核心点就落到了如何创造价值上。 乔梁先生在《持续交付2.0》书中讲述了如何创造价值，即不断探索发现真正要解决的业务问题，提出科学的目标，设计最小可行解决方案（MVP）。通过快速实现解决方案并收集反馈和数据，以验证业务问题是否得以解决（或是否达成目标）。 产品设计过程会分为“0到1”和“1到N