不行，产品经理就要懂点技术！

二会 2023-07-25 10:21:47

我一直觉得产品经理懂点技术是一项必备的技能，因此很多时候一部分产品经理把“我不懂技术”作为甩锅的借口时，我心底都有一丝遗憾——因为这错过了一次变得更强的机会，而在程序员心里或许又多了一个小可sha爱bi。

那么问题又来了，怎么才能算懂点技术呢？

老规矩，我慢慢讲，你慢慢听。

一、学会对象思维

第一次讲对象思维是我在「怎么避免设计漏洞？」中提到过，感兴趣的同学可以翻一翻，这是一篇设计方法论。

对于才入行的且没有技术背景的产品经理，往往看待开发的工作是一片茫然的，完全搞不懂他们是在干什么。

别慌，其实对于程序员的工作呢，本质是对系统里一个又一个的表单进行数据层面的操作——即对表单里的数据进行增加、删除、修改以及查看。

比如你现在看到的这篇文章就是存在某一个表单里的，你对我这篇文章的查看、点赞、在看以及转发记录都会保存在这个文章的表单里，用户的记录组成这个表单里的一条条数据。

那么什么又是对象思维呢？——即把表单看成对象，能清晰认识到整个系统是由一个个对象组成，而系统的运行就是对象之间的信息传递过程。

如作为读者的你正在看我写的这篇文章，那么运用对象思维会变成什么样呢？

“读者”和“我”组成「用户」对象里的2个实体，“我”写的“文章”是「文章」对象里的1个实体；这个时候你就马上能反应过来，这个业务场景至少需要2个对象完成，即2张表单组成（用户表、文章表）。

最后你在看文章的同时，我文章对象里的属性【查看量】又增加了1。

对象思维，它能让你在各种信息系统中无往不利，甚至打开数据库你都能清楚的知道每张表下每个字段的意义和作用是怎样的。

你能指着数据库中的某张表，对着程序员侃侃而谈，他能说你不专业？

三层架构能让你从对象思维的局限里摆脱出来，用更加技术性和立体性的眼光去看待软件系统。

它能让你清楚普遍的系统技术架构是怎样的，帮助你真正的去明白什么是前端语言、后台语言、缓存技术以及分布式架构等让你一脸懵逼的高级词汇。

那什么是三层架构呢？

UI（表现层）：主要是指与用户交互的界面。用于接收用户输入的数据和显示处理后用户需要的数据。

BLL（业务逻辑层）： UI层和DAL层之间的桥梁，实现业务逻辑，业务逻辑具体包含：验证、计算、业务规则等等。

DAL（数据访问层）：与数据库打交道。主要实现对数据的增、删、改、查；将存储在数据库中的数据提交给业务层，同时将业务层处理的数据保存到数据库；而这一层就是对数据库的表单（对象）进行增删查改的操作（这里就体现了对象思维的重要性）。

不行，产品经理就要懂点技术！

图中这些操作都是基于UI层的——用户的需求反映给界面（UI），UI反映给BLL，BLL反映给DAL，DAL进行数据的操作，操作后再一一返回，直到将用户所需数据反馈给用户。

了解完三层架构以后，当一个新技术名词出现时，你可以尝试着把这新技术分类并判断下属于的层级，尝试理解消化，最终能够跟程序员谈笑风生（如数据库Orcale、基本数据访问层框架Mybatis、业务逻辑层框架Spring以及表示层框架vue.js等等）。

当然，我说的技术名词都是九牛一毛，为此我特意准备了一份关于开发技术名词的文档，以后如果遇到不懂的名词可以试着搜搜看。

为什么我会在这个小节去讲开发成本，因为当你会正确的评估开发成本后，你就能够真正的用技术的角度去评估需求；而同时，你也会明白为什么程序员在跟你沟通某些需求的时候反应为何那么大。

这一点是成为一个“懂点技术”的产品经理的必修课。

评估开发成本前，首先你要确定该项需求从技术上是否可行。

这里要从2个小步骤去讲：

如果是简单的对业务对象进行增删改查，那基本能够实现；
如果不是简单的增删改查，我们就从三层架构一层层往下翻，表现层是否要求呈现非常牛皮的效果，这个效果是否有现成的框架去做（这个框架可以自己去找或者去问开发）？业务逻辑层是否有特别奇葩业务逻辑处理不了（如数据类型不对、无数据来源以及新兴技术等等）？数据访问层是否有大维度数据处理不了（数据量太大以及并发太大等等）？

如果出现了第2步的情况，你就要在需求评审之前找程序员心平气和地去聊聊，这个需求有没有实现的方式（因为你懂点技术也不容易被忽悠，所以不能实现的情况也会很少）。

如果可以实现，你就要和开发讨论需要多长时间和多少人力；当预算成本比较高时就要慎重设计，思考其逻辑性以及可扩展性，避免评审会被锤爆，需求变更时被打死。