产品经理是否懂技术的话题早已遍地都是，我认为产品经理学点技术总没有错！除了技术概念，技术思维更需要我们去注意，作为一个产品经理，在需求评审会上，一定听到研发同事讲这个字段要不要写死，不知道写死概念的产品经理会很懵，和研发的沟通不在一个频道上，就容易吃亏，被开发牵着鼻子走。
这样的技术名词还有很多，比如接口、同步和异步等等，我们今天主要说下写死，参数配置，和前后端校验、同步异步，以及我认为最重要的技术思维。
写死可以理解为研发在写代码的过程中，将逻辑写到代码里，如果业务一旦发生变更，研发就需要改代码，重新发布，影响客户的体验，一般业务里要慎重考虑写死。
业务举例：
HIS（医院信息系统）系统里有患者类型字段，产品经理小洪把这个需求和研发同事评审的时候，说患者类型是固定的，包括门诊、住院、急诊这三种，让研发同事直接写死了。
过了一阵子，医院给小洪提了个需求，患者有转院过来的，需要增加一个患者类型为“外院转诊”，小洪去找研发，研发同事建议小洪这个做成参数配置。
小洪按照参数配置的思路进行了设计：
思路如下：
这样上线后，医院的老师们就可以更加灵活地进行配置。
目前小洪公司的客户只有一家医院，最初设计产品的时候也是按照1家医院来设计的，销售部门又签约了其他医院的订单，每家医院的患者类型要求不一样，这就需要系统改造了。
小洪找到研发：现在咱们的系统要上线多家医院了，患者类型要每家医院要独立的
这样的话，研发就需要在参数值表里增加一个标识医院的字段（hos_code)，按照每家医院区分对应的参数值。
每家医院的老师在系统里就只能看到自己家医院的信息，其他医院的信息是看不到的。
我们在登录APP或者系统时都会输入手机号，如果我们输入的号码不是11位数字，都会看到一个提示：请输入正确的手机号。
那么，大家可以想一下，用户点击登录提示这个的时候，是前端校验的还是后端校验的。
其实这个校验规则没有标准是前端还是后端校验，两者都可以。
实际中，这样的校验放在前端会多一些，因为这个手机号不需要后端去校验是否存在。只有满足了正确的手机号格式才能进行下一步。
那么，什么时候需要进行后端校验呢？
如果上面的手机号是正确的格式，点击登录的时候，就需要后端校验手机号是否存在数据里了，前端是无法判断该手机号是否注册过，如果后端校验不存在数据库里，后端就会给前端返回：该手机号未注册，前端接收后端返回的信息展示给用户。
同步：程序在发送一个请求,必须等待返回， 然后再发送下一个请求。 异步：发送一个请求,不等待返回,随时可以再发送下一个请求。
通俗理解就是用户在网上购物，用户提交订单之后必须付款成功，才能给仓库下达发货的指令，这这就是同步。反之不用等待付款结果，这就是异步。同步和异步取决于实际的业务来定。
产品思维的概念仁者见仁智者见智，有人说用户体验，有人说使用场景，有人说客户痛点等等，我觉得产品思维是最短路径解决问题。产品从一诞生，它的使命就是为了解决问题的，电话这个产品是解决人类便捷通信的，微信是解决人类社交和表达的，音乐平台是解决我们能听音乐的。
但是如果不是最短路径解决问题是好产品吗？我认为不一定。比如我们在视频APP里要看电影，前1分钟都是广告，特别讨厌，这个肯定不是最短路径，那么如果直接去掉广告让我们看视频，就和商业模式冲突了。所以我想表达的是最短路径解决客户问题，是有前提条件的。
那么，什么是技术思维呢，我认为的有这么几点：
1）实现成本最低
功能通过代码进行实现，怎么样选择最合理的方案去实现是很关键的，如果一个功能用3行代码和10行代码都能实现，那会优先选择3行代码，反哺到产品做方案时，我们怎么样用最合理的，低成本的方案去设计也产品经理需要关注的，低成本的实现不仅可以提高人效，同时降低成本。
2）容易扩展
如果一个功能模块研发写的都是一堆死代码，那么系统的扩展性就非常差，一个优秀的标准组件可以给各个业务组使用，比如流程引擎配置工具，凡是用到流程审批的东西，都可以使用流程引擎配置工具，在工具里设置规则，而不是按照业务写一堆死代码，一旦业务有变动，需要全部推倒重来。反哺到产品设计时，要抽象出哪些是可以提炼出标准的东西，无论需求怎么变更，都可以用标准的组件进行解决，尽量减少业务代码的改动。
3）软件质量过关
软件系统对质量要求非常高，质量出现问题，会流失到一批客户，甚至还会得到客户的投诉，大多数产品经理可能不太关注软件质量，都是测试工程师负责的，产品经理其实应该最关注软件质量，如果一个产品的页面特别漂亮，但是用起来有问题，用户也不会买单。
4）要有社交性
软件之间的交互是通过接口，接口就代表了两个系统之间是有社交性的，我们拿人的身体来说，各个器官都是相互协作的，系统也是如此，比如医院的HIS系统，有医院其他系统都有接口交互，反哺到产品设计上，我们设计的系统是不是需要和其他系统有交互，哪些业务有交互，什么方式进行交互，交互的信息有哪些，产品经理也要做到心中有数。
5）不要牵一发动全身
经常听到大家聊天说，现在的系统没人敢动了，一动就出问题，只能进行重构了。这种情况多数是底层架构有问题了，设计产品架构时每个模块是否有存在的必要，每个模块核心的作用是什么，各个模块之间如何协作是非常重要的，相反模块之间职责划分不清晰，各自为战，那么整个系统会变得越来越臃肿，还真没人敢随便动。
6）技术没有什么神秘的
如果是人的脸蛋是前端，五脏六腑就是后端，后端怎么工作肉眼是看不到的，把每个器官的功能定义好即可，剩下就是前端和后端交互的事情了。
在技术里，产品经理定义好要实现的功能逻辑，规则，然后前端和后端进行接口交互，前端调用后端的接口，后端进行响应，比如用手机号注册，用户输入一个正确的手机号，点击注册按钮，前端获取到手机号传递给后端的注册接口里手机号这个字段，后端进行落库，返回给前端注册成功。
7）冰冻三尺非一日之寒
培养技术思维不是短时间的事，需要在日常工作中不断地思考、总结。
好了，下次再见。
本文由 @PM东东枪 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
关注微信
