为什么要有工程思维

工程思维之“why”

“why”部分解决两个问题：

1. 为什么要有工程思维；
2. 什么是工程思维。

1. 为什么要有工程思维？

追求质量和速度的平衡是很难的，甚至在我看来，质量和速度根本不存在平衡，仿佛”慢工出细活“这种工匠精神是对平衡质量和速度的挑战。

虽然不同的产品阶段对产品质量有不同的要求和标准，至少在同一产品阶段，质量的标准几乎是稳定的。因此在满足几乎稳定的质量前提下，追求快速交付产品价值意味着效率。在互联网行业，效率代表未来，代表金钱。

快速交付产品价值必然是需要成本的，例如产品开发成本、测试成本、金钱成本，如何降低迭代中的固定成本、提升产品迭代效率，就是工程思维中体现的了。工程思维解决的是“交付”、“价值”和“效率”的问题。相较起“科学思维”的无限期探索和发现，“工程思维”就是要脚踏实地。

脚踏实地，才能更好地仰望星空呀！

2. 什么是工程思维？

工程思维有两大特点：

1. “把事情做成”，也就是要交付“可靠、可用的成果”；
2. 要有“计划性”，在具体的时间周期内交付成果。

像上述本月对话，就是没有交付可靠可用的成果，原因在于没有明确什么样的成果才是可靠可用的。如何明确，围绕用户做起。

对于初级产品经理来说，前期准备工作是很有必要的，因为我们不像有五年十年工作经历的PM可以把产品原则、用户心智吃的透透的，方案上来就有，因而前期对于用户场景、需求分析、产品目标拆解等工作就尤为关键。

这也是我从入职到现在，一直在每个需求中都会做的事。

但是也不要理想化，想着自己把前期工作准备好了，就能交付可靠可用的成果了，因为工程思维并不是按照每一步过程走完，就能够得到最终想要的结果。毕竟产品经理所处只是”软件工程“的其中一环，工程失败也有多方的原因。

对于第二个特点，或许现在每个产品迭代版本，都可看做是一个”具体的时间周期“，但是这里面问题的关键在于如何做到。那么就是回归到第一个特点”交付可靠可用的成果“。所有成果是以“解决问题”为出发点，如何让成果变得明确，重要前提是“能够正确定义问题，并达成共识”。

图2

“达成共识”针对不同的沟通对象有不同的方法。当沟通对象是业务方时，达成共识就是要明确现实背景和需求背景。现实背景是当前现状是什么，现状带来什么问题；需求背景是哪些问题是需要紧急被解决的，解决的标准（目标）是什么，而不是业务方上来就和产品经理谈方案，这样只会变成“为了做而做”（在和业务方沟通时推荐使用5why分析法）。

因此在了解背景后，双方就问题和目标达成共识，这时产品经理或许能够提供MVP的方案来更好解决业务方的问题。

当沟通对象是研发人员时，达成共识就是不断将他人话转述成自己的理解，当自己理解和他人理解是相同时，才能达成共识。

有个例子是我就一个问题和开发咨询，但是我的这位开发总喜欢和产品讲“技术”，但是自知技术功底不深厚但又需要和开发理解达到一个层面，所以可以将开发的话转为自己的理解——

将自己不懂的技术知识用自己懂的业务知识转化表达，再去询问对方自己理解是否正确，这样就能达成共识，进行接下来的沟通了。

二、工程思维之“how”

“how”部分解决两个问题：

1. 如何创造价值；
2. 如何“共创”与“精炼”。

1. 如何创造价值？

上述提到工程思维的两大特点，目的都是为了在保证质量的前提下，快速交付产品价值。如何培养工程思维的核心点就落到了如何创造价值上。

乔梁先生在《持续交付2.0》书中讲述了如何创造价值，即不断探索发现真正要解决的业务问题，提出科学的目标，设计最小可行解决方案（MVP）。通过快速实现解决方案并收集反馈和数据，以验证业务问题是否得以解决（或是否达成目标）。

产品设计过程会分为“0到1”和“1到N”。对于“0到1”，需要先快速迭代，确认需求有用户；对于“1到N”，需要针对具体需求具体分析。因此如何创造价值，需要同时满足以下3个假设—-

• 假设一：有用户；
• 假设二：用户有需求；
• 假设三：产品经理有最小可行解决方案（MVP）满足用户的需求。

如何同时满足3个假设，作者提出了“价值探索环”的4个可持续循环步骤，分别是提问、锚定、共创和精炼。

图3

由此可见，在前面提及的“前期准备工作”（用户场景、需求分析、产品目标拆解等）是至关重要的。保证产品经理和业务方对现状问题的理解和制定的目标达成共识，才开始进行产品设计、研发测试。

有很多时候，业务方有这样那样的想法，但是现状没有功能支持，但是他们觉得用户就是需要的，因此对于“用户是否真的有这样需求”，是首要明确的，也就是假设一。关于用户需求和需要

最近在做用户增长，这种场景和体会也就更深了：

前两周教研同事提出需要了解用户对什么样的直播课主题感兴趣，希望我能够开发一个列表进行对AB-test，以明确用户喜欢什么主题。在明确背景和目标后，发现可以使用“装饰窗”的方法来收集用户信息，即仅开发一个入口，不实现真的功能，来快速得到业务方想要的效果。

于是结合现有的功能，我给教研提了一种MVP：利用学员ID尾号的不同，投放不同的课程主题banner，用户点击进入后看到是一个“假页面”，但可以通过测算用户在这个“假页面”的滑动占比，满足需求目标。

图4：工作场景实践”装饰窗“方法

最终测试效果得出用户最喜欢课程banner4，并且点击进入查看的滑动占比达75%以上。因此在产研团队不需要花资源和时间就能帮助业务方获得用户的反馈，也是非常值得的。

2. 如何“共创”与“精炼”？

通过提问和锚定，明确问题和量化目标后，产品经理要投入精力去提出不同的解决方案。团队中各位产品碰撞，会得出多个解决方案，它们都是基于一定的假设条件猜想得出的，试图解决的是这个大问题中的某个具体问题。

（1）共创

共创得到的是基于某些数据、反馈等有实质参考内容得出的，满足上述3个假设的方案。“量化式影响地图”和“用户旅行地图”是其中常用的两种方法。

量化式影响地图是从业务问题触发，按“角色—影响—方案—量化”的顺序，去量化指标，从而尽可能挖掘可行性解决方案。用户旅行地图，就是我们熟知的用户与产品或服务之间的互动的流程阶段。