2023年产品经理学点技术（思维）总没有错

产品经理学点技术（思维）总没有错！class="aligncentersize-fullwp-image-5773166"src="/wp-files/2023/03/6XEr25HMS34TiQAZPoxR.png"alt=""width="900"height="420"/>

产品经理是否懂技术的话题早已遍地都是，我认为产品经理学点技术总没有错！除了技术概念，技术思维更需要我们去留意，作为一个产品经理，在需求评审会上，肯定听到研发同事讲这个字段要不要写死，不知道写死概念的产品经理睬很懵，和研发的沟通不在一个频道上，就简单吃亏，被开发牵着鼻子走。

这样的技术名词还有许多，比如接口、同步和异步等等，我们今日主要说下写死，参数配置，和前后端校验、同步异步，以及我认为最重要的技术思维。

一、什么是写死

写死可以理解为研发在写代码的过程中，将规律写到代码里，假如业务一旦发生变更，研发就需要改代码，重新发布，影响客户的体验，一般业务里要慎重考虑写死。

业务举例：

HIS（医院信息系统）系统里有患者类型字段，产品经理小洪把这个需求和研发同事评审的时候，说患者类型是固定的，包括门诊、住院、急诊这三种，让研发同事直接写死了。

过了一阵子，医院给小洪提了个需求，患者有转院过来的，需要增加一个患者类型为“外院转诊”，小洪去找研发，研发同事建议小洪这个做成参数配置。

小洪根据参数配置的思路进行了设计：

思路如下：

参数类型：患者类型参数值：当前参数类型的值，比如门诊，住院等等默认值，是值用户在操作界面时默认显示的值，默认值只能有1个参数说明：对参数类型进行说明编辑：新增，编辑，删除参数值这样上线后，医院的老师们就可以更加敏捷地进行配置。

目前小洪公司的客户只有一家医院，最初设计产品的时候也是根据1家医院来设计的，销售部门又签约了其他医院的订单，每家医院的患者类型要求不一样，这就需要系统改造了。

小洪找到研发：现在咱们的系统要上线多家医院了，患者类型要每家医院要独立的

这样的话，研发就需要在参数值表里增加一个标识医院的字段（hos_code)，根据每家医院区分对应的参数值。

每家医院的老师在系统里就只能看到自己家医院的信息，其他医院的信息是看不到的。

二、什么是前后端校验

我们在登录APP或者系统时都会输入手机号，假如我们输入的号码不是11位数字，都会看到一个提示：请输入正确的手机号。

那么，大家可以想一下，用户点击登录提示这个的时候，是前端校验的还是后端校验的。

其实这个校验规章没有标准是前端还是后端校验，两者都可以。

实际中，这样的校验放在前端会多一些，由于这个手机号不需要后端去校验是否存在。只有满意了正确的手机号格式才能进行下一步。

那么，什么时候需要进行后端校验呢？

假如上面的手机号是正确的格式，点击登录的时候，就需要后端校验手机号是否存在数据里了，前端是无法推断该手机号是否注册过，假如后端校验不存在数据库里，后端就会给前端返回：该手机号未注册，前端接收后端返回的信息展现给用户。

三、什么是同步和异步

同步：程序在发送一个恳求,必需等待返回，然后再发送下一个恳求。

异步：发送一个恳求,不等待返回,随时可以再发送下一个恳求。

通俗理解就是用户在网上购物，用户提交订单之后必需付款胜利，才能给仓库下达发货的指令，这这就是同步。反之不用等待付款结果，这就是异步。同步和异步取决于实际的业务来定。

四、我理解的产品和技术思维

产品思维的概念仁者见仁智者见智，有人说用户体验，有人说使用场景，有人说客户痛点等等，我觉得产品思维是最短路径解决问题。产品从一诞生，它的使命就是为了解决问题的，电话这个产品是解决人类便捷通信的，微信是解决人类社交和表达的，音乐平台是解决我们能听音乐的。

但是假如不是最短路径解决问题是好产品吗？我认为不肯定。比如我们在视频APP里要看电影，前1分钟都是广告，特殊厌烦，这个确定不是最短路径，那么假如直接去掉广告让我们看视频，就和商业模式冲突了。所以我想表达的是最短路径解决客户问题，是有前提条件的。

那么，什么是技术思维呢，我认为的有这么几点：

1）实现成本最低

功能通过代码进行实现，怎么样选择最合理的方案去实现是很关键的，假如一个功能用3行代码和10行代码都能实现，那会优先选择3行代码，反哺到产品做方案时，我们怎么样用最合理的，低成本的方案去设计也产品经理需要关注的，低成本的实现不仅可以提高人效，同时降低成本。

2）简单扩展

假如一个功能模块研发写的都是一堆死代码，那么系统的扩展性就特别差，一个优秀的标准组件可以给各个业务组使用，比如流程引擎配置工具，凡是用到流程审批的东西，都可以使用流程引擎配置工具，在工具里设置规章，而不是根据业务写一堆死代码，一旦业务有变动，需要全部推倒重来。反哺到产品设计时，要抽象出哪些是可以提炼出标准的东西，无论需求怎么变更，都可以用标准的组件进行解决，尽量削减业务代码的改动。

3）软件质量过关

软件系统对质量要求特别高，质量消失问题，会流失到一批客户，甚至还会得到客户的投诉，大多数产品经理可能不太关注软件质量，都是测试工程师负责的，产品经理其实应当最关注软件质量，假如一个产品的页面特殊美丽，但是用起来有问题，用户也不会买单。

4）要有社交性

软件之间的交互是通过接口，接口就代表了两个系统之间是有社交性的，我们拿人的身体来说，各个器官都是相互协作的，系统也是如此，比如医院的HIS系统，有医院其他系统都有接口交互，反哺到产品设计上，我们设计的系统是不是需要和其他系统有交互，哪些业务有交互，什么方式进行交互，交互的信息有哪些，产品经理也要做到心中有数。

5）不要牵一发动全身

常常听到大家谈天说，现在的系统没人敢动了，一动就出问题，只能进行重构了。这种状况多数是底层架构有问题了，设计产品架构时每个模块是否有存在的必要，每个模块核心的作用是什么，各个模块之间如何协作是特别重要的，相反模块之间职责划分不清楚，各自为战，那么整个系统会变得越来越臃肿，还真没人敢任凭动。

6）技术没有什么神奇的

假如是人的脸蛋是前端，五脏六腑就是后端，后端怎么工作肉眼是看不到的，把每个器官的功能定义好即可，剩下就是前端和后端交互的事情了。

在技术里，产品经理定义好要实现的功能规律，规章，然后前端和后端进行接口交互，前端调用后端的接口，后