产品经理学点技术(思维)总没有错!

3 评论 7957 浏览 41 收藏 11 分钟

对于产品经理来说,除了技术概念,技术思维更需要注意。本文作者对诸如写死、前后端校验、同步异步的技术概念进行了分析,并分享了他对技术思维的看法,一起来看一下吧。

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

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

一、什么是写死

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

业务举例:

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

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

小洪按照参数配置的思路进行了设计:

思路如下:

  1. 参数类型:患者类型
  2. 参数值:当前参数类型的值,比如门诊,住院等等
  3. 默认值,是值用户在操作界面时默认显示的值,默认值只能有1个
  4. 参数说明:对参数类型进行说明
  5. 编辑:新增,编辑,删除参数值

这样上线后,医院的老师们就可以更加灵活地进行配置。

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

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

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

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

二、什么是前后端校验

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

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

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

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

那么,什么时候需要进行后端校验呢?

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

三、什么是同步和异步

同步:程序在发送一个请求,必须等待返回, 然后再发送下一个请求。
异步:发送一个请求,不等待返回,随时可以再发送下一个请求。

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

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

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

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

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

1)实现成本最低

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

2)容易扩展

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

3)软件质量过关

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

4)要有社交性

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

5)不要牵一发动全身

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

6)技术没有什么神秘的

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

在技术里,产品经理定义好要实现的功能逻辑,规则,然后前端和后端进行接口交互,前端调用后端的接口,后端进行响应,比如用手机号注册,用户输入一个正确的手机号,点击注册按钮,前端获取到手机号传递给后端的注册接口里手机号这个字段,后端进行落库,返回给前端注册成功。

7)冰冻三尺非一日之寒

培养技术思维不是短时间的事,需要在日常工作中不断地思考、总结。

好了,下次再见。

专栏作家

PM东东枪,公众号:PM东东枪,人人都是产品经理专栏作家。关注B端产品设计,目前从事医疗健康领域,擅长需求分析,爱好读书,电影。

本文原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 从需求评审那篇文章过来的,作者写的东西都很干,关注了哈哈哈

    来自湖南 回复
  2. 想请问第5点(不要牵一发动全身),各个模块之间如何协作是非常重要的,相反模块之间职责划分不清晰,各自为战,那么整个系统会变得越来越臃肿,还真没人敢随便动。
    设计系统功能时,难道每个功能都不是各自为战嘛。

    来自新疆 回复
    1. 这个应该不是绝对的吧哈哈

      来自湖南 回复