工程师对产品的理解

对于绝大多数工程师，尤其是产品方向的工程师，对产品的理解越好，越能有助于职业发展。

 

一、为什么工程师需要对产品有理解？

 

        工程师的天职是落地。落地不是说产品做出来就结束，而是要真实的被用户使用，满足用户的需求。如果一个产品做出来不好用，没人用，那不算落地。
        从平时工作的投产比和影响力来说，工程师也应该了解产品。对产品的理解，大的方向是确定产品做不做，小的方向是确定做成什么样，这两个方面都直接关系到工程师的工作量。换个角度想，说某人技术很厉害的时候，往往也是附属在一个产品上。比如Linus很厉害，我们通常是从Linux和Git这两个产品上去感受。
        理解产品同样有益于技术提升。比如同样的一个查找需求，从天猫的某个店铺里找一个商品，和从天猫全站去搜索一个商品，背后的技术可能完全不一样。随着业务发展，很多业务问题会逼迫技术升级，而只有理解产品，才能帮助更好的技术实现。
        理解产品能激发主动思考，避免成为代码实现机器，使以后的职业发展道路越走越宽。哪怕以后换了业务，主动思考的能力和分析方法也具有迁移性，能帮助工程师快速适应新环境。

 

二、怎么去理解产品？

 

        任何产品，都需要满足用户需求，并带来持续的商业收益。不能满足用户需求的产品没有人使用，不能带来商业收益的产品，公司也不会做亏本买卖。但还需要是持续的商业收益，因为一锤子买卖太容易变成“欺骗”。商业收益不单指金钱收入，还包括用户忠诚度，品牌认知，口碑等。
        把产品拆成这两个点之后，就可以简单判断做不做的问题。一个产品不能同时具有这两点的产出，那么可以不做；一个功能至少在不损害一点的前提下，提升另一点，才考虑去做，不拿这两点互换做交易。曾经听过一个极端案例，年底考核，为了冲用户点击的指标，在页面上强行增加很多广告，让用户去点击广告的关闭按钮。
        要解决做成什么样的问题，需要理解用户需求以及使用场景，脱离场景的需求很可能失真。以送药服务举例，通常用户是个病人，身体不适出门不便。这个时候就不能复用一般快递送货的处理方式，放到寄存柜里，必须送到家门口。所以工程师在做之前要详细了解这类信息。理解清楚需求和场景，把自己放到那个场景中去使用，做到“己所不欲勿施于人”。
        另一个方式是把自己变成“客服”，接触真实的用户。虽然这个部分的工作一般会是产品经理去做，但是信息传递难免会有衰减。通过接触用户，也能真切体会用户的感受，培养同理心。

 

三、要理解的什么范围和程度？

 

        越靠近开发，越需要对产品细节理解；越靠近决策，越需要把产品放到大环境中理解。与之对应，在细节处，需要清楚用户使用场景；在决策处，需要清楚大环境中哪些是影响产品的第一第二因素，更进一步，这些因素变化之后会对产品带来什么影响。
        细节处举个文字识别产品的例子。以前一个文字识别产品默认会返回每一个字的外接矩形框。原本的想法是返回尽量多的数据，用户能够有更大的后处理能力。可是后来在客服群里老是被用户抱怨，说一方面返回结构过于复杂，解析不便；另一方面他们大多没有能力基于这些信息做后处理；再者他们也是云服务，要按照流量收费，返回的过多冗余信息增加成本。如果没有客服经历，恐怕很难想到这点。

 

四、如何提高对产品的理解？

 

        最浅层最直接的，就是当一会儿客服，直接接触用户。其次是关注和交互设计师的沟通评审。交互设计师会针对功能和场景进行设计，所以合格的交互设计师必定了解用户和场景。再者是和产品经理多沟通。产品经理相对交互设计师而言，更靠近决策，从他们身上能够学到更多迭代演进的思考。还有就是多读书，比如是经济学的书和心理学的书。经济学的书能帮助判断人在理性情况的决策，心理学能帮助判断人在非理性情况下的决策。当然具体业务还需要阅读行业背景相关的资料。

 

五、这些和产品经理的区别&联系？

 

        有交叉又有不同。首先，负责同一个产品的团队成员，越多人理解产品越好，大家越容易达成共识。所以工程师不应该抱着“产品经理想明白就好”的想法。然后工程师理解的目的是更好的工程落地，而产品经理的目的最大化满足用户需求和持续商业收益，后者比前者范围更大。这也注定产品经理还会包括很多别的工作，比如协同推进、商业运营等。最后对于工程师而言，更多的从定性的角度去理解，而产品经理还需要深入到定量分析。